imt-things / IMT-GIS-Tools

GIS tools for all-hazard incident management teams
https://imt-things.github.io/IMT-GIS-Tools
MIT License
0 stars 1 forks source link

Feature edit/approval by role #37

Open BWS90 opened 2 years ago

BWS90 commented 2 years ago

Only certain roles in the organization should be able to edit/update features in our web mapping application. Specifically, units assigned to data collection in the field should be able to add new features but not edit or delete other features. The GISS and SITL roles should have unrestricted CRUD capabilities. Per the NWCG workflow, GISSs should guide the SITL's decision making for feature approval/retention.

To accomplish this, I propose the following.

(1) Restrict users with role = org_user in our organization to a feature creation workflow. We could do this by taking advantage of the Editor class's allowedWorkflows property. Implementation would look similar to this:

if (portal.user.role == "org_admin"){ const editor = new Editor({ view: view, allowedWorkflows: ["create-features"] }); editorExpand = new Expand({ view: view, content: editor }) view.ui.add(editorExpand, "top-right"); } else { .... }

Note 1: "create" was deprecated in the most recent version of the arcgis api for javascript. Note 2: Load after connecting to the organization's portal. Otherwise, expect portal.user.role = null.

(2) This would functionally solve the aforementioned privilege problem but it should be expected that the "edit feature" tab would still exist in the Editor (though it would be 'locked'). A follow-up issue would be to remove this tab entirely.

(3) To assist the GISS and SITL, keep track of new feature additions from field data collectors by using reactiveUtils. Display these changes to org_admin roles or to certain named users.

BWS90 commented 2 years ago

(1) works as implemented, but will need to follow up to deal with (2) the locked but extant Edit features button.

Screenshot 2022-05-30 6 21 59 PM .

BWS90 commented 2 years ago

(4) In addition to the feature tracking functionality, new features from org_users should have a pending or similar attribute.

BWS90 commented 2 years ago

Closing this because the logic has been implemented and tested (1)+(2) and no one has yet asked for the ReactiveUtils change log (3), going to put that on the backburner.

pounde commented 2 years ago

I'm going to re-open this. No action required right now but I think this is worth fleshing out further (the workflows and associated documentation come to mind).