I would propose a redesign of the workflow, as we are switching to the bodies management. This more abstract model is not that easily representable in simple tables, so I proposed the following design:

https://www.onenote.com/webapp/pages?token=xRV4uKwKxGJO9y7wgfxosx-roKlohthogpD3totySM1Dk781-R9mCuNYDqpistuPTbIgy1YRDqhqkomapRW_n53RWfxQSzET0&id=636290705359961271

Questions

1. Should the body roles be defined globally and/or for a body. It might be nice if each body's board could set up own body-roles that are unique, but also have some in common over all bodies of a specific type (all have a board e.g.)
2. Can we add a short description in case we go for design 1)
3. Which level will the role-edit permissions have in a body? Meaning, is it either someone can add/remove people to ALL/NONE body-roles or should it be that someone can just add/remove people to SOME but not all roles?
4. To not confuse it with global roles, should we rename body-roles to "circle"?
5. Frontend stuff we have done something in events, we created a json object on the fly while processing the request which holds a lot of can-permissons. Like can.edit_details, can.apply, etc for easier handling in the frontend. Actually we created that permission object in a middleware in the backend, but the frontend would just get that delivered and can then easily adapt the visible fields. This way a change in permissions would just have to be done in that middleware and not twice in the frontend and the backend. Should we do the same in core? Would make things easier in the frontend
6. Should we add a visibility field to body-roles, meaning who can see that I am in that role? So on the body-view, some roles are shown and others are not