Add list:create permission for multi-tenancy

[dragonwocky]

See #2395.

Separating out list creation from list management permissions allows for proper scoping of list roles, such that users can create and modify as many lists as they want without other users being able to get a look at their lists or subscribers.

When a list is created by a user with a list role, that list is automatically added to their list role. If the user has no list role, then the list is created as normal. A new list role could be created for these users, but I don't think it's necessary. I assume that users will either have a list role, or have the lists:get_all permission and not need a list role to see their created list.

(As a bonus fix while I was working on this, I've removed the advanced search field from the UI for users without the subscribers:sql_query permission.)

I've included a database migration with this to add the new permission to existing users. Hope this is helpful and can get merged! Thanks for all your work on this project, of everything I've tried it's stood out best by far.

[knadh]

Thanks for the PR @dragonwocky.

When a list is created by a user with a list role, that list is automatically added to their list role.

The issue with this is that all users who have the same list role will end up getting access to the list.

[dragonwocky]

This works the way I'd want/expect for my use case. The idea of list roles is that two users with the same role will always see the same lists, right? If you didn't want them to get access to the same lists, you'd put them in separate list roles.

I don't believe Listmonk has fine-grained enough permissions to give a user access to a list without giving their list role access to it. I could make the behaviour configurable per list role?

---

Edit: Making the behaviour configurable per list role would essentially just be adding a second toggle for the same permission, and it doesn't make sense to allow a user to create a list at all without granting them access to it.

a) You don't want users to create lists at all (disable lists:create).
b) You want users to create lists, and share those with other users (put them in the same list role).
c) You want users to create lists, but keep them hidden from other users (put them in different list roles).

I think documenting this on https://listmonk.app/docs/roles-and-permissions/ should be enough? Alternatively the permissions system could be expanded to give individual users access to a list irrespective of their list role, or implement list role inheritance, but that feels like overkill.

[xeruf]

that really makes sense and would help us a lot!
How is the state here?

[dragonwocky]

I've just pushed a couple more features necessary for my use case. In summary:

• The lists:create permission gives users scoped ability to create lists for their own list role.
• Enabled messengers (e.g. SMTP servers) are configurable per-list role, with an override permission (messengers:get_all) and default access to the email messenger if all others are disabled.
• Default `from` addresses are configurable per-SMTP server.

@xeruf there are a couple of semi-significant changes here, so in terms of official release depends on @knadh's plans but hopefully 5.1.0? In the meantime I'm using this Dockerfile:

FROM golang:1.24-alpine AS builder
RUN apk update && apk add make nodejs yarn git
RUN mkdir -p /listmonk && cd /listmonk \
  && git clone --depth 1 https://github.com/dragonwocky/listmonk.git . \
  && make dist
FROM alpine:latest
WORKDIR /listmonk
COPY --from=builder /listmonk/listmonk .
COPY --from=builder /listmonk/config.toml.sample config.toml
COPY --from=builder /listmonk/docker-entrypoint.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/docker-entrypoint.sh
ENTRYPOINT ["docker-entrypoint.sh"]
CMD ["./listmonk"]

The next thing might to be figure out some sort of scoping or per-user defaults for templates.

[xeruf]

thanks, I think I'll be giving it a try in the course of this month

Right now I am still on v4.1.0 and one challenge I have is those same permissions for campaigns - i.e. I cannot give a user access to only own campaigns or of specific lists but maybe that's already solved with v5?