Add distinction between global editors and collection editors, and admins

[benoit74]

We need a distinction between global editors and collection editors:

• global editors are allowed to interact with all collections
• collection editors need to be granted access to one or more collection

We also need an admin role which is needed for operations on zimfarm notifications + users.

We need to implement this collection editors permission management in the whole CMS, like it has impact on book and titles permissions.

A user with collection_editor role but not allowed on any collection has (at this stage) no more rights than a viewer. It is just a "validation" that he is allowed to have rights on one or more collections.

Assignment of this role + collections is done by admins. I think we should do that in users management screen + API, next to the role assignment.

[elfkuzco]

Here's how I am currently thinking of modelling it:

class Permission(Base):
    """Object-level permission granting an account access to a specific resource.

    Used when role-based permissions don't provide blanket access.
    Extensible to any resource type via the ``namespace`` field.

    Examples:
        - namespace="title", name="read", resource_id=<uuid>  -> can read that title
        - namespace="title", name="read", resource_id=NULL     -> can read all titles
        - namespace="book",  name="update", resource_id=<uuid> -> can update that book
    """

    __tablename__ = "permission"
    id: Mapped[UUID] = mapped_column(
        init=False, primary_key=True, server_default=text("uuid_generate_v4()")
    )
    account_id: Mapped[UUID] = mapped_column(
        ForeignKey("account.id", ondelete="CASCADE"), index=True, init=False
    )
    namespace: Mapped[str]  # "title", "book", "collection", "account", …
    name: Mapped[str]       # "read", "create", "update", "delete", "archive", …
    resource_id: Mapped[UUID | None] = mapped_column(
        default=None, index=True
    )  # NULL = all resources of this namespace (wildcard)

    account: Mapped["Account"] = relationship(init=False)

    __table_args__ = (
        Index(
            "ix_permission_lookup",
            "account_id", "namespace", "name", "resource_id",
            unique=True,
        ),
    )

API currently allows to create user with a specific role which would translate to the user owning access to all resources in the namespace.

@benoit74 , what do you think about this model?

[benoit74]

I don't know how complex this is too implement, but this is beyond what we need ATM.

For now we only need to grant access at collection "namespace" level.

Supporting any kind of "namespace" is beyond what we need, so I would be OK if we implement something more straightforward because I'm really not sure we will ever need to grant access to any kind of namespace.

That being said, if there is a mostly similar order of magnitude in terms of implementation complexity, I'm totally OK to move to this proposition since it "opens doors" to more advanced configurations when needed. I'm just a bit worried it costs to much to implement and maintain, and gives a false sense of customization capability. Because even if we can attach proper permission to each API, is this really meaningful once we move to the UI screens where each screen might involve multiple API and some might fail due to missing permissions.

What I'm sure is that for now I want the UI to allow to grant permissions only at collection level.