[
https://issues.apache.org/jira/browse/QPID-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15432942#comment-15432942
]
Lorenz Quack commented on QPID-7340:
------------------------------------
I think the current behaviour is exactly as you describe how it should be.
doPurgeUser is called from the configurationThread and performs the deletion
from the authentication provider and group providers first.
Then in the while-loop it calls UserPreferences#delete() which submits deletion
tasks to the preferenceThread executor and returns a future.
We do not wait for those futures but immediately return.
I guess, looping vs recursion is largely a matter of taste so I am inclined not
to change it or do you have reasons to prefer recursion in this case?
> Implement purge user managed operation
> --------------------------------------
>
> Key: QPID-7340
> URL: https://issues.apache.org/jira/browse/QPID-7340
> Project: Qpid
> Issue Type: New Feature
> Components: Java Broker
> Reporter: Keith Wall
> Assignee: Lorenz Quack
> Fix For: qpid-java-6.1
>
>
> When a human user leaves an organisation, it is normally desirable to remove
> the records that belong to that user. Implement an operation to allow a
> named user to be removed. This could be hooked to to an organisation's
> 'leavers-feed'.
> This operation should remove:
> * preferences
> * for authentication providers that manage their own database, the user's
> password entry
> * for group providers that manage their own database, remove the user from
> any groups
> What ACL permission should protect this operation?
> What if a Virtualhost is offline at the time the operation is invoked?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
