gchq
Because stream processor filters are dependant on the user that created them for creating tasks there needs to be some dependency checking when deleting users
I tried this with a processor on a pipeline - is that what this issue refers to? If so deleting the owning user doesn't seem to delete the processor. Is this issue mostly about deleting the stream processor filters at the same time as deleting the user?
Is there also a UI aspect? What would an admin expect to see when trying to delete a user that has stream processor filters?
- Nothing, just delete the user. I.e. deleting the user's stuff is implicit in deleting a user and they shouldn't have to ok.
- A warning.
UI issue for 6.0 that might block resolution of this: a user can currently be deleted using Tools -> Users. This deletes it from the main User store, which is the auth service. This delete does not cascade to deleting the user in Stroom! It probably should. The Stroom user can be deleted from Tools -> User Permissions.
The issue is that the pipeline will attempt to run in the context of the deleted user and throw errors in the log
A few questions regarding this:
- Does the processor still actually process the identified streams in the filters i.e. is this a cosmetic issue with respect to errors in the logs. Or is there no output produced?
- Is the behaviour the same for deleted vs disabled accounts?
- Will the enhancement allow you to transfer ownership of said processor filters if deleting/disabling a user?
- Is using a service type account for processor creation a better business process given this situation?
7.6-beta.7 now has a user dependencies sub-tab on the User top level tab. This will show filters that have the user set as their RunAs user. Deletion of a user will also be prevented if dependencies exist.
