Granular permission system

[Safiyya]

To scope :

• what are the permissions level for data editing ?
• what are the permissions level for team management ?
• how are they displayed ? how are they chosen?

[Safiyya]

from tom@zappistore (suggested by @tomnixon )

• map editing : readonly vs full edit
• team management : not discussed

[Safiyya]

I have a couple of free days this week and could start working on this. What are your thoughts ? Any suggestions from current customers?

[tomnixon]

Here's a first attempt at defining a fairly comprehensive permissions system which I think should be able to handle just about any use case we can think of. Perhaps it's worth @Safiyya starting by evaluating how complex this would be to implement and if necessary we can look to simplify it into more of an MVP if that makes more sense for now.

The system would have a few security levels baked in: Super-user, Manager, User.

Super-users can also create further security levels.

Team members have a setting to assign them a particular security level. I suggest keeping this simple and having just one security level per team member.

Next there would be a permission configuration page as a big grid. Down the Y axis is a list of all actions in Maptio. For example: Create initiatives, Delete initiatives, Manage team members; Manage helpers etc.

The X axis lists the security levels.

In the grid cells there are checkboxes to set whether a particular security level can carry out that function.

Some cells have drop-down boxes which specify the scope of when a particular security level can use a particular action. For xxample: Action: Delete initiative Scope: Not allowed / Anywhere / When Authority / When Helper

This drop-down might contain different items depending on what the action is. We could start by listing the main actions a user might perform and then building out the list from there.

To give Zappistore Tom his read-only mode you could create a new security level called Read-only and set any actions that allow a user to change anything on the map to 'Not allowed.'

[tomnixon]

Thinking about an MVP, probably the main areas where permissions are particularly needed are the ability to delete initiatives and also certain actions around managing team members like importing, deleting or inviting users. Perhaps we could build the more comprehensive system as specified above but just include a limited number of actions. Then we could have a prompt on the page to say "Do you have other needs around permissions? Email support@maptio.com" so we can then get more customer feedback from that.

[Safiyya]

I think this is waay too complicated and also not needed. As far as I know the only customers that I have asked for are Zappi (PatientPop dropped out) and they were only asking for 2 levels , read-only and editing (is that right?). What you are proposing is more complicated than most systems that I know (including big names like Microsoft Azure and AWS), I really don’t see the need for all of these features at this time.

Things that are not needed IMO :

• ability to create more levels
• grid system
• super detailed granularity (for helper, for authority, etc)

As far as I’m concerned, the MVP has 2 levels of security defined at the map level. A possible stretch would be to have these levels defined at the initiative level instead of the map level.

[tomnixon]

Yes that's true. I was going for comprehensive first and expecting to strip it back as needed. I was also thinking about technical debt if you build permissions for limited use cases then have to expand it later.

If it helps to stick to two levels, I wouldn't strip the lower level all the way back to read-only.

How about regular users can:

• Add new initiatives but not delete them
• Add or remove themselves from any initiative and change their roles
• Add other helpers to initiatives and set their roles (but not remove them from initiatives)

I think this would probably meet Tom@zappi's need better than read-only (although I don think having a read-only view of the map would be useful as well. I can even imagine having the ability for it to be publicly accessible on the web.) We could check this with Tom before building.

[Safiyya]

Technical debt works the other way round actually : the more complex the feature, the more technical debt we incur. In most cases, it is more difficult to remove code and make the codebase simpler (because the added complexity makes it difficult to read/debug) than adding code on a simple codebase. Engineers have actually a lot of acronyms and phrases to describe that phenomenon :

• YAGNI (You Ain't Gonna Need It) https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
• Swiss army knife / kitchen sink https://sourcemaking.com/antipatterns/swiss-army-knife
• Overengineering https://en.wikipedia.org/wiki/Overengineering

It always helps to attach a monetary value to any added feature.... at the rate of a UK-based freelancer (£350 -£500/day) , would you pay roughly £2000 to have all of these implemented now and maybe remove them later ?

Here is a 2-part blogpost about technical debt and overengineering https://www.turbo360.co/blog/over-engineering---part-1-rqog0m

[Safiyya]

To summarize,

• Regular users

  • Add new initiatives but not delete them
  • Add or remove themselves from any initiative and change their roles
  • Add other helpers to initiatives and set their roles (but not remove them from initiatives)

• Admin users

  • Everything a regular user can do
  • can change authority, helper and description on any initiative
  • can add or remove users to a team
  • can change the team jargon

[tomnixon]

Sorry, I think we missed each other here! I meant strip the requirements back, not actually build it and then remove code later.

I'll send your summary above to Tom H and see if it meets his needs.

[tomnixon]

From Tom H: "Like it - seems a creative way to allow people to be engaged without being able to pull the whole thing apart. To be really honest at this point I'm not completely sure, but it feels right. I'm expecting to have more feedback on permissions as more people become active."

[Safiyya]

Management (front-end)

• [x] Create roles

  • [x] User can deserialized roles
  • [x] Permissions are assigned to users at login

• [x] Team page

  • [x] Members tab
    • [x] add dropdown to change role in members table
    • [x] only Admin can edit roles
    • [x] only Admin can create users
    • [x] only Admin can invite users
    • [x] All users can resend invitation
    • [x] only Admin can permanently delete a user (with confirmation)
  • [x] Import tab
    • [x] only admin can import users
  • [x] Settings tab
    • [x] only admin can change team jargon & team name

• [x] Teams page

  • [x] only Admin can create a new team

• [x] Profile page

  • [x] Display role

• [x] Signup

  • [x] user created through signup are Admin per default

• [x] Activate

  • [x] check that activated users get the appropriate role (chosen by the registered user)

[Safiyya]

Content (front-end)

• we keep admin and regular roles for management (team, members , jargon , etc) permissions
• the authority of an initiative can define who amongst helpers can/cannot edit an initiative. The ones who can will be able to edit everything on an initiative but cannot delete it
• only an authority can delete their initiative
• by default , helpers cannot edit anything but their roles
• not sure yet how to deal with initiative creation and what rights has the creator

TODO

• [x] Creation
  • [x] anyone can create a new initiative
• [x] Deletion
  • [x] Admin users can delete any initiative
  • [x] Standard users can delete initiative only if they are the authority
• [x] Modification
  • [x] Tree structure
    • [x] only Admin can change the tree structure
  • [x] Name
    • [x] authority can change name
    • [x] secretaries can change name
  • [x] Description
    • [x] authority can change description
    • [x] secretaries can change description
  • [x] Tags
    • [x] authority can change tags
    • [x] secretaries can change tags
  • [x] Helpers list
    • [x] adding
      • [x] authority can add helpers
      • [x] secretaries can add helpers
      • [x] other helpers can add themselves
    • [x] deleting
      • [x] authority can remote helpers
      • [x] secretaries can remote helpers
      • [x] other helpers can remove themselves
  • [x] Helpers roles
    • [x] authority can change helpers roles
    • [x] secretaries can change helpers roles
    • [x] other helpers can change their roles
  • [x] Tag
• [x] an authority can grant helpers the right to edit more than their roles (everything else)
• [x] handle change detection in tree

Questions

• Initiatives without authority can be deleted by anyone ?

[tomnixon]

I've done some testing although not exhaustive yet. From what I have seen I think it's generally working as expected - well done!

Only thing I was unsure about is whether a secretary should be able to change the Authority of an initiative. At the moment they can't, but I'm thinking they probably should be able to do that. this would also mean that in effect secretaries could delete an initiative (since they could first make themselves the authority and then delete it.) I think I'm OK with this. If someone has been made a secretary then they have been entrusted with looking after that initiative in Maptio.

[tomnixon]

We also need to tidy up the user interface. We need some better labels/tooltips for things. Did you want to come back to this later? Also looks messy having "XX YY can edit this initiative" repeated so many times. I think it would look neater if there was a checkbox next to Role with a heading at the top saying 'Can edit?' This label could also have a tooltip saying 'Check this box to allow contributors to edit the details of this initiative.' Something like this:

[Safiyya]

The labels/tooltips/copy was my first worry, so if you could come up with phrases for each cases, that would help. I will try that UI suggestion next.

[tomnixon]

I'm thinking we should change the tooltips to simple messages like the ones below to just tell the user they don't have permission, but also include a 'Learn more' link to a knowledge base article that explains how permissions work. Drag and drop: "You don't have permission to drag-and-drop. Learn more." Padlocks: "You don't have permission to edit this. Learn more."

[tomnixon]

On the team page, can you change the heading from 'Role' to 'Permission' (just so it's not confused with how we use the term Role elsewhere.)

[Safiyya]

All of this will deployed in staging in about 10 mins.

[tomnixon]

The improvements are looking good! We're getting there.

A few issues I can see:

• [x] The permissions advice tooltips are persisting too much. Like this - I can get 3 displayed at once. They should really only appear on hover over the padlock or when the user actually tries to do something they are not allowed to do, and they should go away again easily.

• [x] Permissions tooltip is appearing when I roll over the description field, even if I don't click and don't roll over the padlock icon.

• [x] The learn more link for the padlocks is not always going to the KB.

• [ ] How about changing 'Can edit' to 'Admin' since a contributor is effectively being granted admin rights for this initiative?

[Safiyya]

The first is actually difficult as I’m using an open source bootstrap add on that :

• doesn’t allow for tooltips (displayed on hover) to have a link
• doesn’t allow popovers (displayed on click) to disappear when the mouse is not hovering

I tried a mix of the two (basically the whole afternoon) and that’s the result so far... I’ll try some more tonight or we’ll have find a different solution.

IRT label of “can edit”, I think “Admin” is confusing, especially for the real admins. Maybe something like super , delegate, deputy ? or any from this list https://www.google.com.lb/search?q=deputy+synonym&oq=deputy+synonym&aqs=chrome..69i57j0l5.6679j1j7&sourceid=chrome&ie=UTF-8