Multi-Tenancy Permissions

[xeruf]

Is your feature request related to a problem? Please describe. I would like a user on my instance to create and manage their own mailing lists - it is no problem if I see them.

Describe the solution you'd like A lists:create permission? Maybe for proper permissions a list role needs to be created automatically then and assigned to the user.

For testing, I created a user only with subscribers:import permission, and the user can see Lists>Forms but get an error when clicking on it.

I am running v4.1.0 via docker compose

[xeruf]

Plus, after adding the lists:get_all permission, I can see a list of lists, but the interface gets stuck when clicking on a list:

[knadh]

@xeruf that shouldn't happen! Could you share the URL where this is happening and the exact steps to reproduce this issue?

[xeruf]

1. Create a user with only subscribers:import permission and login
2. Click on Lists>Forms
3. Get permission denied settings:get error (Error 1)
4. Add lists:get_all permission and reload
5. Click on Lists and then on a List - I am guessing it is refusing because of the missing lists:manage_all permission, but there is no error message, just console errors and no response from the interface (Error 2)

Generally I find the permission system needs quite some work - a lot of permissions are subsets of each other but treated as independent - you cannot manage a list without having the permission to view it? So maybe set permissions with a Slider? (Feature Request 1) For example:

Lists Access: <-- Only List Roles -- View All -- Manage All -->

This also makes it more clear that the lists permissions are on top of the List Roles, which was not clear to me in the beginning - I thought lists permissions are needed fro any lists access

[dragonwocky]

@knadh @xeruf I think I've got the same use case: users should have scoped access to a set of lists, but be able to add new lists to that set themselves.

So far the closest I've gotten is a list role + user role with lists:manage_all enabled and lists:get_all disabled. This only shows lists from their list role on the lists page, and lets users create new lists - there's just no way for them to then manage those new lists. Ideally it should be possible to add lists created by a user with a list role to that list role automatically?

I agree as suggested above that the lists:manage_all permission might be more appropriate to split into lists:create and lists:manage permissions for consistent scoping of access to only those lists granted by the list role or according to lists:get_all.

---

I've also discovered that even with lists:get_all and subscibers:get_all all disabled, users can access the details of subscibers to lists they don't have access.

• /api/lists/{id} is blocked if a user does not have permissions (✅).
• /api/subscribers/{id} is accessible if a user does not have permissions (❌).
• /admin/subscribers/lists/{id} is accessible if a user does not have permissions (❌).

Similarly, users can view/manage campaigns sent to lists they don't have access to even when campaigns:get_all and campaigns:manage_all are disabled.

• /api/campaigns and /admin/campaigns include campaigns sent to lists users do not have access to (❌).
• /api/campaigns/{id} and /admin/campaigns/{id} are accessible if the given campaign was sent to a list the user does not have access to (❌).

This feels like a bug, let me know if I should open a separate issue for it. The campaigns:manage_all permission is possibly also redundant if campaigns:get_all and campaigns:manage are combined intuitively.

---

Edit: campaign and subscriber permissions work as expected when lists:manage_all is disabled. So maybe not a bug. I'm starting to understand why it behaves like this, but it still feels counterintuitive to have such broad permissions.

[github-actions[bot]]

This issue has been marked 'stale' after 90 days of inactivity. If there is no further activity, it will be closed in 7 days.