Add Object permissions to project and allow set add_check globally or per-project

[mchehab]

Currently, patchwork doesn't allow granting permissions to add_checks without promoting an user to superuser.

This patch series:

• add a button at project admin, allowing to select per-project add_check permissions;
• change the logic which accepts adding check to use either a global add_check permission or per project, per-user permission;
• now, having a maintainer status is orthogonal to add CI checks: maintainers that need to also update CI need to be granted with CI add checks permission.

[stephenfin]

@mchehab Could you propose these against the main branch and I'll backport them myself?

[mchehab]

@mchehab Could you propose these against the main branch and I'll backport them myself?

Done. I'll keept django-guardian~=3.3.1 dependency, but feel free to use a newer one if you prefer.
I will dropped one patch (4e3d25d), which is not seem to be doing any difference.

[mchehab]

Thanks for changing the baseline. My user were unable to change the baseline indication at the PR.

[mchehab]

hmm... this one requires more work... it actually added "add <project>" instead of "add <checks>"

[mchehab]

I changed this one to RFC, as some work is still needed to be able to have per-project permissions.

[mchehab]

Ah, the patch I dropped made some difference (or perhaps a re-run on manage.py migrate).

It is now shown:

so, besides add/change/delete/view project, there is an "add checks" over there.

[mchehab]

Tests with https://github.com/mchehab/pw_tools:

User without global "add_check" permission:

$ ./pw-checks.py -p local set 20260606114703.5-1-ruoyuw560@gmail.com foo warning "" "No link"
ERROR: 147247: foo failed to set 'warning': 403 Client Error: Forbidden for url: http://127.0.0.1:8000/api/patches/147247/checks/

After granting patchwork | checks | add_check at Users admin:

$ ./pw-checks.py -p local set 20260606114703.5-1-ruoyuw560@gmail.com foo1 warning "" "No link"
INFO: 147247: foo1 set to 'warning'

After removing patchwork | checks | add_check at Users admin:

$ ./pw-checks.py -p local set 20260606114703.5-1-ruoyuw560@gmail.com foo4 warning "" "No link"
ERROR: 147247: foo4 failed to set 'warning': 403 Client Error: Forbidden for url: http://127.0.0.1:8000/api/patches/147247/checks/

After granding Projects -> <project_name> -> <Object permissions> add_check permission:

 $ ./pw-checks.py -p local set 20260606114703.5-1-ruoyuw560@gmail.com foo4 warning "" "No link"
INFO: 147247: foo4 set to 'warning'

In summary, both coarse grained and fine grained add_check permission worked.

[matttbe]

Thank you for looking at this! I have a couple of questions/ suggestions of you don't mind.

[matttbe]

(patch is not defined in this first commit)

[mchehab]

I'll fix on a next rebase (I'm currently in vacations - will likely do it next weekend).

[matttbe]

Could you move it to the test one, please? I guess that's why the CI is no longer passing

[mchehab]

ok, will do at the next rebase.

[matttbe]

Sorry, I think you should keep it there, but add it in the tox.ini file (and in the README one as well I suppose)

[matttbe]

Is this a behavioural change? If yes, could this be avoided not to make upgrade difficult? Especially on large instances with many users :)

[mchehab]

Yes, after the change, enabling/disabling checks become an independent permission.
I suspect that, even on large instances, there are typically just one user that do CI check additions on a given project - usually a special account for it; the other maintainers shall not have any business adding CI checks.

You got a point though: it could be better to set it by default during migration. Not sure if is there a way to teach migrations to set it by default for maintainers to preserve existing behaviour.

[matttbe]

Or do it in 2 steps: one without a behavioural change that can be backported, then changing the permissions. But yes, ideally setting it by default during the migration would make upgrade smoother.