Review of endpoint to return all resources

[axl8713]

Changes as per #379:

• Added order/sort parameter with ascending/descending option for all available resource attributes
• Added missing support for filtering resources by:
  • creator (the owner of the resource)
  • editor (the last user who modified the resource that is used for indicating the modified by on the front-end)
• Added missing support for filtering resources by group
• Added permissions information (canCopy, canDelete, canEdit) to the response
• Fixed date parsing in filtering to accept dates without milliseconds part

Other changes:

• Centralized and Refactored the user permissions checks on resources
• Moved endpoint /extjs/search/{nameLike} to /extjs/search/resource/{nameLike}, avoiding the clash with GET requests on /extjs/search/list

Closes #379 .

[afabiani]

General Observations

1. Repeated Permission Logic

• You have permission checks scattered in ResourceServiceImpl, RESTExtJsServiceImpl, ResourceEnvelop, and the ShortResource creation. This can lead to maintenance headaches.
• Recommendation: Centralize read/write/copy permission checks in a single place (e.g., PermissionService or a “Policy” class). Then, everything that needs permission info calls that service.

2. Potential Performance / DB Queries

• Repeated calls to resourceService.getSecurityRules(...) inside loops or streams can become expensive if you have many resources.
• Recommendation: Where feasible, fetch all relevant SecurityRules for the user in bulk. Or do a single join in the DAO so each Resource already has the needed rules loaded.

3. DTO vs. Entity

• The @transient fields (canEdit, canDelete, canCopy) indicate you’re mixing view-layer logic with domain objects. If that’s a conscious design choice, it’s valid, but watch out for “entity bloat.”
• Recommendation: A simpler approach might be returning a dedicated ResourceDTO from the service layer, which includes these transient fields and no JPA annotations.

4. Logging / Exception Handling

• Some methods (like search(Search searchCriteria)) catch IllegalArgumentException and rethrow a BadRequestServiceEx with “Resource search failed.” That’s fine, but ensure you log the root cause somewhere for debugging.
• Recommendation: Add a logger statement with the exception’s message or full stack trace if it helps with debugging.

5. Documentation

• Before consider this PR done, let's make sure we updated the WIKI API sections with the relevant parameters.
• There shouldn't be any model update here, so no need to update the doc/sql/ scripts

[axl8713]

4. Logging / Exception Handling

• Some methods (like search(Search searchCriteria)) catch IllegalArgumentException and rethrow a BadRequestServiceEx with “Resource search failed.” That’s fine, but ensure you log the root cause somewhere for debugging.
• Recommendation: Add a logger statement with the exception’s message or full stack trace if it helps with debugging.

As it is, that exception already gets logged at the warning level from the REST service, along with its root cause.