Fix permission issue for editing or deleting instances #151

Merged

tobru merged 3 commits from 148-instance-edit-permissions into main

2025-07-11 14:55:48 +00:00

rixx commented

2025-07-11 10:17:29 +00:00

Member

Alternative to #148 – does this resolve the problem observed? I followed the other PR in making it so that only org admins, not org members, can change instances.

Additionally, I added a rule that grants "admin dashboard" permissions to staff users. Up until now, staff users were able to see, edit and delete objects, but did not see any indication of this on the dashboard, which was empty.

Alternative to #148 – does this resolve the problem observed? I followed the other PR in making it so that only org admins, not org members, can change instances. Additionally, I added a rule that grants "admin dashboard" permissions to staff users. Up until now, staff users were able to see, edit and delete objects, but did not see any indication of this on the dashboard, which was empty.

rixx force-pushed 148-instance-edit-permissions from 4c0a656ed4 to 5feabda513

2025-07-11 10:25:56 +00:00

Compare

rixx referenced this pull request

2025-07-11 10:28:12 +00:00

Service instance edit and delete permissions tied to Django permissions #131

tobru commented

2025-07-11 12:18:51 +00:00

Owner

@rixx Unfortunately, no. A regular user without any Django permissions (staff or superuser) cannot edit or delete a service instance. IMHO we should not rely on the Django permissions but on the role the user has in the Organization.

rixx added 1 commit 2025-07-11 14:38:59 +00:00

Make rules compatible with instance checks

Tests / test (push) Successful in 26s

Details

0bd895c486

rixx commented

2025-07-11 14:39:10 +00:00

Author

Member

@tobru Hm, but that's what's meant to happen regardless – you can see that Django uses the django-rules permissions in User.has_perm by checking out this PR and comparing the look of the admin interface as a staff user.

I found the bug, though – the problem was that the checks were originally tailored to the Organization model, and were not flexible enough to look up the organization when given an instance. Fixed this in 0bd895c.

@tobru Hm, but that's what's meant to happen regardless – you can see that Django uses the django-rules permissions in `User.has_perm` by checking out this PR and comparing the look of the admin interface as a staff user. I found the bug, though – the problem was that the checks were originally tailored to the Organization model, and were not flexible enough to look up the organization when given an instance. Fixed this in 0bd895c.