On top of the role, we need to store a mapping (I assume, in the swh-deposit database?) of which clients the moderator is allowed to view. Since we'll have to handle this information, is a new keycloak role *also* needed?

On top of the role, we need to store a mapping (I assume, in the swh-deposit
database?) of which clients the moderator is allowed to view.

Currently, the moderation view permissions are dealt with at the archive level [1] So i
don't think there is a mapping in the swh-deposit db (and I also don't see one related
to the list-admin-view in the swh-web db [2]). I don't think that's dealt with django
permissions at all? @anlambert do you confirm ^

TTBOMK, it was instrospecting the connected user's keycloak role... but now i'm confused
when i read the code for that part. [1]

[1] https://forge.softwareheritage.org/source/swh-web/browse/master/swh/web/admin/deposit.py$19-30

[2] both staging and prod swh-web db

select * from auth_permission where name like '%deposit%';
+----+------+-----------------+----------+
| id | name | content_type_id | codename |
+----+------+-----------------+----------+
+----+------+-----------------+----------+
(0 rows)

Time: 17.377 ms

Since we'll have to handle this information, is a new keycloak role *also* needed?

The idea was to avoid having to give too much permissions to a user which do not need to
push deposit... But I guess the answer for that question will be clearer with an answer
from the previous point?

TTBOMK, it was instrospecting the connected user's keycloak role... but now i'm confused
when i read the code for that part. [1]

[1] https://forge.softwareheritage.org/source/swh-web/browse/master/swh/web/admin/deposit.py$19-30

[2] both staging and prod swh-web db

User permissions are stored in Keycloak database not in django one so that query result.

You could store the list of deposit client names in a custom Keycloak user attribute that will
be made available in the JWT token or store the mapping between a username and the
clients directly in the deposit database.

TTBOMK, it was instrospecting the connected user's keycloak role... but now i'm confused
when i read the code for that part. [1]

Well not really the code... more like keycloak...
I did not find the ADMIN_LIST_DEPOSIT_PERMISSION = "swh.web.admin.list_deposits" permission in keycloak (for the role swh-deposit).

I found it back not on the swh-deposit role but on the swh-web role... that's why i got lost.
(But that makes sense since like i said, it's the archive/webapp which deals with those permissions ;)

I found it back not on the swh-deposit role but on the swh-web role... that's why i got lost.

Yes because it is a webapp permission to enable the deposits admin UI (https://archive.softwareheritage.org/admin/deposit/).

The existing swh.web.admin.list_deposits role seems to correspond to the feature described in the task.

Only the deposit clients mapping is missing.

Only the deposit clients mapping is missing.

I don't understand what a deposit client mapping is (sorry).
Do we need it ^?

In the end, @olasd is right, we don't need an extra role...
What we need to do is editing a user, give them the client role swh-web and then affect it the role swh.web.admin.list_deposits and then they are good for listing deposits.

Adding a new client role swh-deposit-moderator with role swh.web.admin.list_deposits as default role will make things less complicated administration wise though.

Only the deposit clients mapping is missing.

I think what we want to achieve here is to allow a user without the permission to push deposits to
browse a subset of the deposits list. For instance a user related to HAL should only browse HAL
related deposits.

Only the deposit clients mapping is missing.

I think what we want to achieve here is to allow a user without the permission to push deposits to
browse a subset of the deposits list. For instance a user related to HAL should only browse HAL
related deposits.

Ah maybe @moranegg do you concur ^?.
I was focused on only giving access to the admin view.

In T3906#78219, @ardumont wrote:

Only the deposit clients mapping is missing.

I think what we want to achieve here is to allow a user without the permission to push deposits to
browse a subset of the deposits list. For instance a user related to HAL should only browse HAL
related deposits.

Ah maybe @moranegg do you concur ^?.
I was focused on only giving access to the admin view.

I concur.
I think we can give access to all deposit in the beginning, since most information is public.
In the long-term it would be preferable to give access to the subset of deposits.

Here is the list of keycloack roles:
https://forge.softwareheritage.org/source/puppet-swh-site/browse/production/data/common/common.yaml$3398-3410

I can find the role:
swh.web.admin.list_deposits

Does this mean that the task is resolved?