Index managerRolesAndUsers on the object itself

[reinhardt]

... without switching from client to admin.

Refs syslabcom/scrum#2640

[thet]

Code wise, it does look good to me. Except that I'd wish for more comments, explaining some architectural details which are wired into the code but hard to understand. E.g. why is the "Owner" role removed in manageRolesAndUsers. Or why this replacement of client with sectors in filter_permissions - what are these hard-coded content ids all about again?

Business logic wise I can't say much, because it's hard for me to understand. I always have to rethink myself into OiRA after being away from that project for some time, because there are is so much implicit, undocumented business logic and un-Plonish code weaven into that app.

[reinhardt]

I don't know about the Owner role. Perhaps that's copied from allowedRolesAndUsers. The docstring does say that it's modeled after that one.

Surveys are copied from sectors to client when they are published. That's a peculiarity of euphorie, but I think it's a bit too basic to explain it in the mailing list code. It's a fact that's used all over the place. In case of the mailing lists we only want to show tools that the user has admin permissions on (i.e. on the CMS side, in sectors). OK, maybe that's worth mentioning? But if you know that each client tool has an admin counterpart in sectors then it kind of explains itself, doesn't it?

Would it help to go through the code in a call?

[reinhardt]

I've pushed a fix (removed more lines from managerRolesAndUsers) and added a docstring to filter_permission.

[thet]

Thanks, also for the explanation above. copied them into my own oira docs :)
LGTM