feat: adds collection CRUD ui

[jrcastro2]

• closes 5 - Implement full collections management + Browse tab visibility rules CERNDocumentServer/cds-rdm#632

Grabacion.de.pantalla.2026-01-28.a.las.15.mp4

[kpsherva]

I am wondering, and it would be nice to hear from the others too. Shouldn't the UI implementation be in invenio communities as well?

[egabancho]

I remember talking with @slint about this some time ago, and they (Zenodo) would like the ability to hide the collection management from the interface because they don't want any community owner to be able add collections to Zenodo.
We discussed ways to implement that, and permissions seemed to be a good candidate back then.

It might be worth checking if this is still the case.

[ntarocco]

don't want any community owner to be able add collections to Zenodo.

I doubt that it is entirely true.
They want to limit it for some communities, but for most of them, it should be allowed.

Can't we have a "manage collections" permission, that will hide/show/control the mgnt part of the community's collection? An instance can override the default, and implement its own.

[jrcastro2]

This is still being discussed.

[kpsherva]

why do we need to know in the community access if the collections are enabled?

[jrcastro2]

Right, good point, is not anymore needed, was meant to enable the collections management per community, but I guess we can simply rely on the permission levels and let the owners (or whoever is granted access) to manage itself. Will remove this.

[kpsherva]

to be discussed: only owners, not maangers?

[kpsherva]

I think this complicates things slightly and I am not sure if I understand what is the use case for having granular rights on the collection of the community.
my understanding is:

• if someone can_read the community and it's records, they should be able to also see the collections created on the community. Why would we hide from anyone a list of available search queries or how we group content?
• can_manage_collections, I would rather place it in the CommunityPermissionPolicy, because if there is no community, there is no collections to manage. If we are aiming to restrict the collections management to some role then the policy should go to the invenio-collections module and should not be dependent on the community at all. ping @slint for input.
  In addition I think community managers should also be able to manage collections.

if you remove this policy class, you can also remove the config variable and additional reading prefix in ext.py

[slint]

Some quick thoughts:

• agree on having managers also be able to manage collections (it's in the name anyways :) )
• regarding placement, given that at some point there will be support for global collections (or other types, as folks requested) having a dedicated section for "permissions for community collections", would probably make sense... Having this on the community permission class would be most "fitting" now, similar to how we have can_manage_files, etc. on record permsisions

[kpsherva]

to summarise:

• we should have can_manage_collections in CommunityPermissions (can_read is not needed) which includes also CanManage() generator
• remove CollectionsPermissionPolicy completely
• remove the reading of prefix "COLLECTIONS" in the ext.py

[jrcastro2]

We could do all that but we wouls still need to set COLLECTIONS_PERMISSION_POLICY to - in this case - CommunityPermissions. If we want to remove the reading of the prefix "COLLECTIONS" that would mean that we need to wire this up in invenio-app-rdm, the downside is that anyone using invenio-communities with collections outside rdm would need to configure that as well. Please confirm this change and I will go ahead, thanks!