Performance / Pagination: Implement Permission Check at Database Level

[mcjaeger]

One problem why we cannot do paging (using it from the Ektorp Interface) is that we do the permission checks in a right complicated way in our logic layer.

The permission checks already require the list from the database and since we do not know before permission check which projects will be omitted, using the paging API of the Ektorp would not help.

A solution would be to implement the permission check on database layer. the permission check looks for the access setting of the project and then checks for role of the requesting user in the user object (eg. CLEARING_ADMIN), role of the requesting user in the project (e.g moderator) and the group setting (combination of access level and group membership of the requesting user compared with the group assignment of the project.

useful reference: https://helun.github.io/Ektorp/reference_documentation.html#d100e997

[mcjaeger]

(from discussion) adding to that the sorting by clicking on the table headers in the UI will be a problem with paging. Discussed was to implement views for every kind of sorting that could be queried accordingly.

[mcjaeger]

(also from discussion): apparently some sorting takes also place when ingesting the data into the query data table for the first time. Maybe this could be investigated (and switched off)

[mcjaeger]

(discussion) also discussed the idea to use index for having projects in a specific order because considering the b-tree structure of couchdb the traversing of records seems to be an obstacle for the

[mcjaeger]

(so from the discussion finally)

two solutions:

1. we go ahead with components and ECC list view and using views in Couchdb do the result filtering on the database and then we can use paging from the Ektorp API.

2. well, ... and for project we do paging in Java.

3. On the thrift level, the same API is offered but the back end is implemented differently.

[mcjaeger]

(new discussion) first minimal implementation how it behaves for components: implement the sw360portlet to server-side-portlet-level paging to reduce the javascript computaton.

Looking today at the profiling seems like 75% of the user wait time is due to rendering the page in JavsScript when pulling all components (actually in 25% of the wait time, a page with 70k lines is delivered).