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

Re-evaluate logic of the different provisioning bits #968

Open
xmo-odoo opened this issue Oct 24, 2024 · 0 comments
Open

Re-evaluate logic of the different provisioning bits #968

xmo-odoo opened this issue Oct 24, 2024 · 0 comments
Labels

Comments

@xmo-odoo
Copy link
Collaborator

If a user loses their review rights (update_reviewers) their partner gets "emptied" and the user is moved to portal, however it's not disabled, as a result it's still returned by list_users, and thus doesn't get re-provisioned if it's enabled again.

This means e.g. if an employee leaves the company then comes back, their user needs to be updated by hand, or disabled for the provisioning to re-trigger.

This would be solved by disabling the user after portal-ing it (leaving an enabled partner record), the initial consideration was that e.g. an employee leaving to work at or as a partner's might still need to interact with the mergebot but although that is true the mergebot does not use portal, it has no portal features whatsoever. It only has portal because that's a dependency of website. Furthermore free signup is disabled, so the only way a user should be created is via provisioning (or user creation by an admin).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: ideas
Development

No branches or pull requests

1 participant