Feature Request: Granular Roles, create read only etc custom role permission combinations

[xet7]

Moved to here from #2876

Current Wekan permissions are Admin/BoardAdmin/NoComments/CommentOnly/Worker. Current permissions are hardcoded with changes all around Wekan codebase.

Granular Roles would bring:

• Settings at Admin Panel and REST API how to set permissions
• Each current permission from Roles, Card Settings etc to be defined separately
• Add more to REST API

Technically I will do it this way:

• Change current permission system to alanning:roles
• Add each permission check to that alanning:roles
• Add code for REST API etc at wekan/models/
• See Worker Role issue and Worker Role commit for more details. Also search ChangeLog for Worker etc.

Progress in this will be added to Wekan Roadmap with amount of bounty.

This is a big feature, that requires a lot of changes. Target for this bounty is about 2000 euro.

It's possible to participate to this bounty with any payment method at https://wekan.team/commercial-support/

[xet7]

Moved to here from #2109 (comment)

From @smokhtari-pacdev about global webhooks

This is a problem when boards are private and people don't want others (let say other admins) to see their activity as it sends out the details of private boards too. I suppose it shouldn't be doing that by default. If someone wants that on a Private board they should add it there.
Thank you!

Reply from @xet7

There is multiple issues here:

• Other admins, this relates to granular roles (this issue) and Teams/Organizations Add Feature: Teams/Organizations similar to Trello #802
• For which users what is private? Limiting what "Global Webhooks" does would add more complexity. Would someone like to fund this issue?
• Current Wekan permissions for boards are private/public. Public boards are visible to everyone at Internet as read-only with URL, and visible at Public Boards tab list when logged in.
• How private that should be? If you mean "to the max", then it's database encryption MongoDB Encryption and Wekan #890 and your added long password that decrypts at browserside and only stores encrypted data at server. Most likely this would need full rewrite of Wekan that is very expensive. Then there is questions about forgot password, losing data if password is not known, key management, etc.
• Some have asked Wekan to have super admin feature to see all boards Wekan have. Should Wekan have that feature?
• When user account is deleted, should all of that user's boards be deleted too, where is no other members? I have not checked how deleting works currently.
• With all of the above, where is the limit what features are within scope of Wekan, and what are not? So that we would not end up with too many settings and complexity (well, although we already have too many settings).

What do you all think?

[xet7]

Moved to here from #3404

From @Mythotical

With how things work today, being able to only assign Admin role to a user or they are just a normal user is something that isn't big. What I suggest is a usergroup system or allowing us to add more roles where we can have User, Viewer, Mod, Admin, etc. This way if I don't want to assign the admin role to users just so they can access my private board(s) I can set up a new role with permissions to allow viewing and posting on private board(s).

This process could have its own page in the Admin Panel. Don't list Admin role, leave that how it is but anyone who signs up is a User or whatever the default role is we set up. Then add a new field to the users edit form that is a dropdown to change their role from User to something else we created.

I know this is probably going to be a big request since things would have to be changed in the code to use if statements based on permissions so I don't expect it anytime soon. I may try to add this in myself, if I succeed then I'll do a pull request to submit the changes.

[Mythotical]

Has anyone paid anything toward this bounty yet? If I can I'll pay something toward but I can't afford the full 2,000 euro.

[xet7]

@Mythotical

Nobody has paid anything related to this bounty yet. Any amount can make possible some progress.

[Mythotical]

@xet7

Ok then, I'll try to pay something toward this bounty in the next week or two. I have to wait to get paid by clients before I can commit to the bounty but I will gladly pay something toward progress on it.

[xet7]

@Mythotical

Thanks! I'm currently In Progress of coding Teams/Organizations #802 .

[xet7]

Related Editors can not modify label titles / colors #2113 , with this granular roles that permission could be made per-role enabled or disabled.

[xet7]

Moved to here: Feature Request: Restrict Creation of Boards #1928

[xet7]

Moved to here: delete attachement is missing #3397

[xet7]

Moved to here #1861 , more roles etc, see issue for additional details

[xet7]

Moved to here: Add-Feature: Restrict registration to specific E-Mail domain #1823

[xet7]

Moved to here: Comment only Permission Can move checklist item #1418

[xet7]

Moved to here: Feature request: Option to change default to "tracking" from "muted" for all users / new users. #1235

[xet7]

Moved to here: Add Feature: Anonymous user with write access on public board #1124

[xet7]

Moved to here: Notifications only work when watching whole board - you can't watch only specific lists or cards #1005

[xet7]

Moved to here: new members only able to register at home page #490

[xet7]

Moved to here: On sandstorm, share link does not let users edit the board #349

Summary: Allow edits by anonymous users on all platforms, if there is permissions for that. Try to figure out how to generate per user id, because usually all anonymous users show as same one user id.

Anonymous users required also on Friend, etc, if having anonymous user is allowed. FriendUPCloud/friendup#114

[xet7]

Moved to here: Even members can assign cards to other members. #282

[xet7]

Moved to here: enhancement idea for the "new user invitation for private board" workflow #441

[Nevarro]

I couldn't find anything towards "granular permissions" in the roadmap. Do you have any ETA for permissions that allow restrictions, for example, for lists? This would be very useful for our work.

[xet7]

@Nevarro

Nobody has yet funded this feature at https://wekan.team/commercial-support/ so this has not been added to Roadmap yet.

[xet7]

Because this is not funded yet, there can not be any ETA.

[xet7]

Sure if some other Wekan contributor has time to implement some of this, pull requests welcome.

[xet7]

I added this Granular Roles to Roadmap to list Waiting for funding.

[e-gaulue]

Well, I read this thread. Here are ideas.

Present situation

1. Wekan admin can access to the administrative panel

2. Board admin can:

• Set visibility of the board
• Create/Manage/Archive swimlanes and lists
• Invite members and set their "type" :
  • admin (give right at board level)
  • normal (card level)
  • nocomment (card level)
  • comment only (card level)
  • worker (card level)

Demands

I've seen the idea to create teams and organizations using alanning:roles. It looks like a huge work. By the way, granular permissions are great but boring to manage (Welcome to the active directory World). How to keep wekan simple? Inheritance is already a complex idea.

Here are few features right management should handle. All of them are not link to users but to objects, but maybe it can be dealt by alanning:roles anyway (through scopes? I don't know).

Organisations
      \- Teams
            \- Users

Boards
  \ \-  Lists  -\
   \- Swimlanes -\
                  \- Cards

Roles

Use cases:

• Members can just add on top in a list and cards are stuck to their position afterwards: good to keep chronological cards order regarding a subject. (Example of List Role)
• Public archive: Duplicate the last week board and set the duplicate board as RO
• Corporate information: Read only or comment only swimlane and/or lists (Those last two are in fact linked, its RW, RO, comment only at card level, with inheritance form Board, Swimlane/ List)
• Allow card modification to author only (Same it's a Role at the Card level that could be inherited from above)
• Public, members, author cards visibility

So, sometimes, I really wonder who owns the Roles : the users or the cards? If alanning:roles can cross them, it's great.

We need to be clear on the use cases and see how we would handle each of them. Wee need to list them all and prioritise. I can imagine easy GUI tools to set Roles to Board/Swimlane/List/Card.

Regards,

[xet7]

@e-gaulue

I've seen the idea to create teams and organizations using alanning:roles. It looks like a huge work. By the way, granular permissions are great but boring to manage (Welcome to the active directory World).

Currently roles have been manually hardcoded, and can not be changed at all. Some complain that normal user can not drag-drop swimlanes etc. Changing them to alanning:roles would replace manual code, and roles being like tags. I think that alanning:roles implementation is more robust with it's server- and clientside code, than existing manually hardcoded roles.

How to keep wekan simple?

Wekan has been way beyond simple already some years ago. Wekan has huge amount of settings already, for many use cases. Some Wekan users have commented that they use most Wekan features already, features should not be removed.

Inheritance is already a complex idea.

That alanning:roles has option to use inheritance, but it's not mandatory. At first I plan to use those roles like tags, so each user can with tag belong to:

• Organization
• Team
• Role

I really don't know how to implement Teams/Organizations #802 without Granular Roles.

So, sometimes, I really wonder who owns the Roles : the users or the cards? If alanning:roles can cross them, it's great.

There will be settings at Admin Panel and REST API. For each role, checkmark does it have some permission.

We need to be clear on the use cases and see how we would handle each of them. Wee need to list them all and prioritise. I can imagine easy GUI tools to set Roles to Board/Swimlane/List/Card.

Oh please don't, you are thinking too complex, there are billions of use cases, Wekan is already used in most coutries of the world.

In practice, with role tags, I will make most hardcoded settings to be modifiable.

About these options, I prefer a) because it will be less work:
a) implement general feature that covers many use cases
b) implement each feature separately

Each of those current roles have been implemented separately.

[xet7]

From @mfilser

I am also interested of implementing granular roles/permissions (#3022). What are your plan's here? Did you already start with it?

No, I did not start with it.

It is possible to implement Granular Roles/Permissions this way:

a) Add https://atmospherejs.com/alanning/roles

b) Using current WeKan roles:

1. Current roles are here: https://github.com/wekan/wekan/wiki/REST-API-Role

2. Find related permissions code:

cd wekan
./find.sh isAdmin
./find.sh isCommentOnly
./find.sh isNoComments
./find.sh isWorker

3. For each of those Roles, they have checks in WeKan code, what is allowed or not. You can search for word role at:
   https://github.com/wekan/wekan/blob/master/CHANGELOG.md
   for related code.

4. For those Roles, it's possible to add:

• New table to database
• Add each role name, permission etc to database
• Add Admin Panel options to enable/disable each permission for each role
• Maybe possibility to add new role name, that has different permission

[akkari93]

Any funding for this yet? Would implementing this allow setting a role for users to only see tasks they're assigned to and not any other task on the board?

[xet7]

@akkari93

There is no funding for this yet. Yes that kind of custom role would then be possible.

[NeronJ]

@xet7 how much funds do you need to cover this?

[xet7]

@NeronJ

2000 euro. It's mentioned in 1st comment of this issue #3022 (comment)

[NeronJ]

@xet7
Thanks. I missed that one. I'll explore the possibility to get this via a client.