Admin UI elements do not reflect read/write access rights

Steps to reproduce

Steps to reproduce:
1. With an admin user, create an event with the following ACLs

  • ROLE_ADMIN read/write

  • ROLE_ANONYMOUS read access
    2. Create a (non-admin) user and assign that user all available UI roles
    3. Click on the details-button in the "Actions"-tab and browse, e.g. to the metadata Tab

Actual Results:
All fields are editable, the changes, however, are not stored when closing the details view. There are no indications of failure in the UI. The log outputs errors, when trying to edit something, please refer to err_log.txt (ADMIN-URL replaces the URL of our admin node).

Expected Results:
Event details should only be editable, if the respective user has write access and possesses the respective ROLE_UI_EVENTS_DETAILS_***_EDIT role.

Workaround (if any):

Similar problems arise with the remove-button in the Actions-Tab. However, the UI gives some feedback here ("Task could not be created"). Also possibly with the "tasks"-dropdown, although some tasks might not require write access.

I set priority to 'Minor' since, as far as I can tell, the (non-privileged) user cannot do real damage in the use cases mentioned above. It's mainly just confusing to the user.


Greg Logan
March 27, 2018, 3:50 PM

Whoever fixes this, please see the minor discussion on as well.

Your pinned fields
Click on the next to a field label to start pinning.




Katrin Scharnowski


Incorrectly Functioning Without Workaround