Workflow owners do not necessarily have access to their workflows: user comparison fails

Steps to reproduce

Steps to reproduce:
1. Create a user in the admin UI
2. Create a group with all the available roles except ROLE_ADMIN and ROLE_USER_ADMIN and ROLE_SUDO and add the previous user to it.
3. Log in with the new user and start a "Fast" workflow

Actual Results:
The workflow hangs in the Cleanup operation. Actually, the operation has failed but is not displayed in the admin UI.

Expected Results:
The workflow should run without problems

Workaround (if any):
Add the value "security/*" to the parameter "preserve-flavors" of the "cleanup" operation.


Rubén Pérez
May 31, 2016, 1:02 PM

The problem happens because the role information is stored as attachments in the Mediapackage --they are deleted as part of the cleanup operation, but they are requested immediately afterwards, which causes an exception.

The (already deleted) ACLs are not requested in three cases:

  • The user is the general ADMIN user

  • The user is one of the tenant's admin user

  • The user is the workflow owner

For unprivileged users, the later case fails because the comparison between the current user and the workflow owner fails. This happens because the field "provider" in one of the users is null, while it is "opencast" in the other. However, both users are actually the same, but the information is not completely populated in one of the cases.

Since the "provider" parameter since to be of little use, my proposed solution is to remove the condition that two equal users should also have equal providers. I.e. the "equals" method in the JaxbUser class should not take the "provider" parameter into account.

Fixed and reviewed


Rubén Pérez


Rubén Pérez


Incorrectly Functioning With Workaround

Tags (folksonomy)



Fix versions

Affects versions