Improvement on Context permissions management

[tdipisa]

Description

Since there is a relationship between an application context and maps created within it, there must be specific rules to prevent inconsistent states like:

• The final user has permissions to access a map resource but not the related application context resource
• The application context is deleted so a map within that context is no longer accessible

Below are the constraints and actions that need to be developed to enhance the Application Context tool:

1. When you create a map in a context, the map must have the same permissions of the context, these permissions cannot be changed by the final user

2. If the administrator try to change context's permissions, a confirmation dialog must appear to confirm the following action:

• Upadate the security permissions on all context maps accordingly: if confirmed, a batch update request to the MS backend will aling the permission rules of all the involved maps in the context (this requires Provide Entry point for batch attribute update geostore#205)

3. If a context is deleted, a confirmation dialog must appear to the administrator to confirm the following action:

• Use the MS's default context for maps within the deleted context: if confirmed, a batch update request to the MS backend will remove all map attributes containing the ID of the context to automatically use the default one (in that case map permissions can be maintained as they are, the default context is public). Also this point requires Provide Entry point for batch attribute update geostore#205.

Other useful information

[tdipisa]

From @offtherailz

Increased a little the estimation because "assigning the same permission of the context" in case of user maps may need a little adjustment (permissions of the context, as other resources, are not accessible for users that has read only access).
One solution is to limit the creation of maps in context by read-only users to only private maps. @tdipisa