Skip to content

Introduce different permissions for user profile data handling

Johannes requested to merge Jo-introduce-permission-class-for-profile-administration into master

What does this MR do?

I worked on user profile permissions as I believe orga, bieb, bot/amb -checks should only be part of *permission classes if possible. This helps having everything consistent and easily changeable. Permissions in general also allow to disable modules or functions if there are problems with an easy return false; at the beginning of a method.

To understand things better it might be a good idea to look at the code. Permissions changed slightly here. Especially for forms, menu entries and methods an orga had only theoretically permission to but just was callable via api or hidden links.

Some methods/places:

  • show history: maySeeHistory()
  • edit other peoples profile: mayAdministrateUserProfile()
  • show foodsaver ambassador menu in regions: mayHandleFoodsaverRegionMenu()
    • delete foodsaver from region: mayDeleteFoodsaverFromRegion()

You can not access lower level regions where you are not ambassador for anymore. For ambassadors of higher level regions this was possible before. Check it out: https://beta.foodsharing.de/?page=foodsaver&bid=XXXXX This was possible before but half broken (only members where shown but no edit menu). This makes it easy to enable later with menu entry and already correct/fixed broken previous permissions.

Restored. You can not access workgroups with this tool anymore: https://beta.foodsharing.de/?page=foodsaver&bid=734

How confident are you it won't break things if deployed?

Quite but would like to take a closer look with users after beta deploy

Links to related issues

none

How to test

Steps a reviewer can take to verify that this MR does what it says it does e.g.

  1. Checkout branch locally
  2. Use your IDE to navigate to both permission classes
  3. Switch on/off methods by returning true/false and see if things change

Screenshots (if applicable)

  • only backend changes

Checklist

  • added a test, or explain why one is not needed/possible...
  • no unrelated changes
  • asked someone for a code review
  • joined #foodsharing-beta channel at https://slackin.yunity.org
  • added an entry to CHANGELOG.md (description, merge request link, username(s))
  • Once your MR has been merged, you are responsible to update the #foodsharing-beta Slack channel about what has been changed here. They will test your work in different browsers, roles or other settings
Edited by Alex

Merge request reports