Notes for Documentation

This page contains information that should be incorporated into the documentation eventually.

What happens to open invitations when a group switches from "invite only" to "no member can join", for example?

More generally, what happens if the permission or condition_template is changed after an action passes a permission, hits a condition template, and generates a condition?

The answer is different if the permission changes and if the condition_template changes. This is because currently, the action being re-run will get the absolute current permissions but may get old conditions.

If the permission changes, and the action no gets far enough in the permissions pipeline to trigger a conditional (say, because the actor no longer has any type of permission) then the action will fail.

If the permission stays the same or changes in a way that still triggers a condition, then the action will pass, because the system checks for the condition by pk of action, so it will find the condition associated with the action and see whether it passes.

We may want to change get_or_create_condition to look for a condition item that matches the condition_template's type and configuration, as the behavior above is confusingly inconsistent. However, for our invitation example, the answer is actually consistent - the invitation is always invalid, because "anyone can ask" and "anyone can join" both configure the AddMember permission to require self-only - that is, actors can only add themselves, and so the action which triggers the invite (where an actor adds the invitee) will not pass. And of course "no new members can join" will also not allow AddMember to pass. The only way an invitation might still work is if the original action was created by someone with a governing permission or foundational permission (although if there are conditions on governing or foundational action in the group, that would then kick off a separate condition).