Share plugin - Permalink - Add a permalink functionality

[dsuren1]

Description

Add new permalink functionality to the Share plugin

Acceptance criteria

• Permalink shares current user session (custom layers in the TOC, custom background layers, all user customization) and not only the initial map of the Context. This means that the current overall map/viewer state will be saved (as it usually happens when you save a map, for example). The saved resource should be public by default
• Create new category named PERMALINK to save all permalink under it -->
  • Add to XML of initial categories
  • Add the proper migration scripts to mapstore guidelines
• The permalink saved has its own ID to be used as a query param in the URL to load the same. The same logic will be applied to contexts and maps created from a context.
• Protected layers as part of the permalink that are not visible to a certain user are marked in TOC (which follows existing behaviour of TOC. Hence no change is required in the implementation)
• Permalink should be a separated plugin injected in the share plugin.
• Permalink tab is placed inside the Share panel. The permalink tab is visible only to authenticated users and user with allowed permissions (This could be expanded in the future using some configuration like allowed roles/groups) and can be disabled via configuration.
• On permalink tab open the user will have a form with
  • "Title" (mandatory)
  • "Description"
  • "Public" a checkbox, checked by default. If checked, it adds the group everyone can view. Otherwise it is private for the user (that is the default if you do not specify any permission for the links).
• After the sumbit of the form the user will see the following screen
  
• Add a checkbox to permalink panel to make it public
• Not mandatory (nice to have): It should be possible to include permalinks also for geostories and dashboards with no particular additional effort. To be checked during the implementation
• Take in consideration also the Other useful information about the suggested implementation and the things about the title.

Other useful information

georchestra/mapstore2-georchestra#583

Suggested implementation

The permalink is a map (but can be a context, geostory ...) resource in PERMALINK category that has to be saved on MS DB, with

• name: (name of the resource) an hash generated on the fly

attributes:

• title: the title of the item (mandatory for permalinks, inserted by user)
• description : the description (not mandatory, inserted by user )
• type: possible values - map, context (possible also dashboard and geostory) - mandatory, saved by the share tool
• pathTemplate: the path tempalte to use. E.g. #/viewer/${id} or #/context/${name}?category=PERMALINK ... - mandatory - saved by the share tool. For context, the param category helps to fetch correct resource by category upon page reload

The daŧa of the resource is the data we whould save if we save the map at the current status ( so extracting the current status as well as save as tool does, but saving it in a different category).

Using pathTemplate helps the permalink to be generic and not hard-coding the specific redirects to the pages.

So loading the resource is simple as loading the original ones (by redrecting to the path created with the path template), using the trick of storing them in a different category to not list them in the extisting items.

• Because title is an attribute, it should be visible in the layer tree, where present, in place of the name of the resource, when present.
• It could be a nice to have to have the title editor in save form too. IT should be shown for the moment only if it is present as attribute (also an empty string is ok for showing the editor, but if it is an empty string in the layer tree or where it is shown as a string,you should show the name isntead.
• For the full support of title as a replacement of name in the UI we may need a separate issue. (E.g. to use it in cards etc... )
  An entry point #permalink/{name} should be implemented, with proper login checks accordingly with the standard workflow when accessing the resource is somehow erroring.
  For instance it should prompt a login if the resource is not public and the user is not logged in, or show the proper error messages (error 404).

As soon as the permalink is loaded in the browser, the type is parsed to redirect to :

• /#/viewer<resourceId> in case of map
• #/context/<hash> in case of context
• ...

Notes about everyone group

Actually the save tool asks for GeoStore API to different entry points depending on the user role to retrieve the usergroups the user can select in permission form :

• User datails if you are a normal user
• usergroups entry point if you are an admin
  This can be a good wayt to retrive the everyone group id when saving the resource to make it public.

about save tool in resource

Because we are using the existing entry points to see the resources (e.g. viewer/123) we may have the save tool present. We need to check if this introduces a feature (e.g . to change the permission in a more fine grained way) of if it may introduce some bugs (e.g. overriding existing attributes and making the permalink unuseble).

Let's check after first implementation what is the final result, so we can take a decision about how to handle this case (e.g. to hide somehow the save tool or whatelse).
Also management and delete of existing permalink can be decided in a second time.

after discussion we noticed it could be better to include the permalink as a separated plugin, child of share plugin.

[dsuren1]

@offtherailz

• Should we allow permalink tab to be visible when the resource is not loaded i.e from card (applicable to all resource types) ?
• If user can create multiple permalink for the same resource? Should we add a back/recreate like button on the permalink tab?

[offtherailz]

@offtherailz

• Should we allow permalink tab to be visible when the resource is not loaded i.e from card (applicable to all resource types) ?

Permalink creates in fact a snapshot of the current state of the resource. Creating it from outside do not make so much sense (in fact it may be only a copy with limited functionalities, not so much useful in this case). So I think we should avoid it.

• If user can create multiple permalink for the same resource? Should we add a back/recreate like button on the permalink tab?

The user can create how many permalinks he wants. Considere that the permalink do not depend on the current resource. In fact, it is a freeze of the current state of the resource, reachable by a link.
Once the permalink is created, The user can copy the URL. A button create a new one can be added to get back to the creation form.
Close button should do the same, so when you re-open the tool, the form is prompted again.

[offtherailz]

Meeting minute

We make Permalink a separate plugin. This way we have :

• a better management and a better isolation of the functionality.
• it will not be included by default in old configurations using share plugin
• Handling the access to this is easier using disablePluginIf

[dsuren1]

With respect to this. I will create a separate PR to handle it