* owner derived from cm:creator was not added to writer list
* fully authenticated user in base test was being set incorrectly
* transaction executed outside authentication in BDT classes
Feature/rm 3512 query for authorities
RM-3512 - Add sorting/filtering capabilities for more than one field
Added canned query to retrieve the authorities so we can sort/filter by multiple fields. We support filtering by name pattern, authority type and clearance(new) and sorting by authority name, display name (new), authority type (new) and clearance (new).
Explaining the query:
- all the authorities (users and groups) are under a common zone (APP_DEFAULT) whose node id I pass as parameters trough #{authorityContainerNodeId}
- the authority name is either username (#{qnameUserName}) or group id (#{qnameAuthorityName}).
- I build the display name by concatenating firstName lastName and groupName. Any user has firstName but not all groups have group names (the default groups only have group id). So if after concatenating the 3 properties the display name is null then we are dealing with a default group. In this case the display name will be the group id without the "GROUP_" prefix = substring(authorityName.string_value, 7)
- there is no need for qname id null checks as I never pass null to the query. If I can't find a qname id in the database I simply pass INT_MIN so the qname won't match any row. This way the results are not altered and the query is easy to read.
- the clearance and authority type are not ordered by natural order (ordering alphabetically would look random to the final user) but by a predefined order.
See merge request !410
* create deprecated service interface to tidy things up
* create set method and deprecate exisiting
* crate remove method and deprecate exisiting
* remove deprecation warnings in code
* added getReadersAndWriters method to extended permission service
* refactored calling services, consolidating code into one location
* extended unit test
Note: getFullAuthenticatedUser has been removed from writers list as it
makes no logical sense since you must be a writer in order to perform
these operations in the first place.
* inplace move no longer needs to store and reset extended security
* no need to clear extended security when assoc is removed
* a couple of extra checks to inplace move integration test
