Closed dsuren1 closed 1 year ago
@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.
We make Permalink a separate plugin. This way we have :
disablePluginIf
Description
Add new permalink functionality to the Share plugin
Acceptance criteria
Other useful information
https://github.com/georchestra/mapstore2-georchestra/issues/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
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 toolpathTemplate
: 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 reloadThe
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.
#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 contextNotes 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 :
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.