Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removing user from auto-provisioned Service Group is not persisted after Service Group change #1592

Open
baszoetekouw opened this issue Sep 16, 2024 · 2 comments
Assignees
Labels
bug Something isn't working discuss Needs to be discussed; do not implement as is.

Comments

@baszoetekouw
Copy link
Member

After the implementation of #1384, CO admins can remove the "auto-provision" checkbox from a Service Group, in order to remove users from the group.

However, if that happens, and after that the Service group is edited, the group in the CO is returned to auto-provision state and all member are back.
This is probably unexpected for the CO admin.

To reproduce:

  • create auto-provisionign service group
  • connect Service to CO
  • in CO, edit group, remove auto-provision
  • in CO, remove user from group
  • in Service, edit description of the Service Group
    result: in the CO all CO ,member will be member of the group again.
oharsta added a commit that referenced this issue Sep 19, 2024
@oharsta
Copy link
Collaborator

oharsta commented Sep 19, 2024

Confirmed and agree that is somewhat strange behaviour. What would the desired behaviour be? Without making it too complex preferably.

@FlorisFokkinga FlorisFokkinga added the bug Something isn't working label Sep 30, 2024
@logan-life logan-life self-assigned this Sep 30, 2024
@logan-life
Copy link
Contributor

logan-life commented Oct 1, 2024

Confirmed, reproduced with one caveat:

If you edit the Application Description and uncheck auto-provision then the members are not re-added to the application group. This is checked by default, so editing the application description isn't really the thing that is causing the behavior. It's editing the application description and leaving the checkbox ticked that causes the behavior.

So it seems that what is happening here is that the auto-provision checkbox from the application side has more "priority" than the auto-provision checkbox from the collaboration side.


Auto-provision checkbox is available in two places:

  1. Home > Application > Application Group - Auto Provisioning yes/no
  2. Home > Organization > Collaboration > Group - Auto Provisioning yes/no

My feeling is that the CO should have priority here. That is, a decision made by the CO admin to not auto-provision members to an application group should override the desire of the application group to auto-provision members.

In this scenario, the expected behavior would be:

In application, create auto-provisioning application group
Connect Application to CO
in CO, edit group, remove auto-provision
in CO, remove user from group
in Application, edit description of the Service Group and leave the auto-provision checked
result: in the CO all CO member will not be a member of the application group, and neither will future members.

In essence, unchecking the auto-provision box on the CO side should override whatever setting is present on the application side.

Thoughts welcome!

@logan-life logan-life added the discuss Needs to be discussed; do not implement as is. label Oct 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working discuss Needs to be discussed; do not implement as is.
Projects
Status: Needs refinement
Development

No branches or pull requests

4 participants