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

Enhancement: Set default error message for all concurrecy issues #1158

Closed
hofmannc opened this issue Sep 9, 2019 · 3 comments
Closed

Enhancement: Set default error message for all concurrecy issues #1158

hofmannc opened this issue Sep 9, 2019 · 3 comments
Assignees

Comments

@hofmannc
Copy link

hofmannc commented Sep 9, 2019

Testserver: qa imeji
Browser: ff
Version: 4.6 - build date 2019-08-30 12:57:36
User: admin

Actions:
user1: edits collection xy
user2 (admin): Admin -> Browse user -> select user 1 -> revokes grants of collection xy
user1: saves changes ->

same for "edit user group"
same for withdraw collection and edit collection info in parallel (current warning:; Page has to be reloaded/error during editing)
same for selete ans edit in parallel (current warning: "error durching editing")

Observation: user gets message "insufficient permissions 403"
Expected Result: Defned default message for concurrency issues is displayed

@MPDLTam
Copy link
Contributor

MPDLTam commented Dec 17, 2019

  1. Access rights of a collection change (are revoked) while user edits that collection:
    The error message "You do not have sufficient permissions to perform this action. Contact the administrator for more information." feels correct. When trying to save the collection the permissons to save changes to this collection do not exist any more.
    Note: A more detailed error message might help user to understand the situation better.
    Note: Changes are actually saved, which is a bug, see also Passed user objects are not reloaded form database during CRUD operations #1155

MPDLTam added a commit that referenced this issue Dec 23, 2019
- Check status of Item or Collection with database object (for
thread-safety)
MPDLTam added a commit that referenced this issue Jan 2, 2020
(part 1), fix

- Added exception class that can be extended by classes
  that want to provide a meaningful error message to the user
  (ImejiExceptionWithUserMessage)

- Refactored WorkflowException

- Fixed bug in CRUDTransaction
MPDLTam added a commit that referenced this issue Jan 7, 2020
(part 2)

- Added new exception type (ImejiExceptionWithUserMessage) to exception
handling in presentation layer
MPDLTam added a commit that referenced this issue Jan 7, 2020
- Added error messages and labels.
MPDLTam added a commit that referenced this issue Jan 7, 2020
- Moved message in messages file
MPDLTam added a commit that referenced this issue Jan 8, 2020
(part 3)

- Refactored ReloadBeforeSaveException (extends now
ImejiExceptionWithUserMessage)

- Refactored ImejiExceptionWithUserMessage
@MPDLTam
Copy link
Contributor

MPDLTam commented Jan 9, 2020

To sum up:

The ticket looks at situations in which two users access and edit/change a shared object (i.e. item, collection, user, user group) simultaneously without knowing of each other.
Imeji provides three different "safety mechanisms" that can be triggered when users' actions on a shared object interleave. Each mechanism produces a different user error message.

Situation 1: Two users edit or change the content of a shared object simultaneously.

Saftey mechanism triggered: "Reload before save"

Example: Two users open an item simultaneously and edit its (meta-) data, i.e. title and author list. The user who saves last will see this error message:
Error during metadata edit! Item has been altered in store. Reload before saving.

The general format of the error message is:
[Error/Couldn't do something]. [Item/Collection/User] has been altered in store. Reload before saving.

Situation 2: At least one user changes the status of the shared object such that the other user's action is not valid any more.

Safety mechanism triggered: "Valid operation", check if the intended operation is valid for the object and its current status

Changes in an object's status are:

  • create object
  • delete object
  • publish object (item and collection)
  • discard object (item and collection)

Forbidden is (example):

  • edit a discarded object

Example: Two users access a published collection simultaneously. One user starts to edit the (meta)-data of the collection. The other user discards the collection. The first user then tries to save her/his changes. The user will see this error message:
Error during editing of the collection. Cannot update collection because collection is discarded.

The general format of the error message is:
[Error/Cannot do something]. [Operation not possible/valid]

Situation 3: At least one user changes the access rights of a shared and concurrently accessed object.

Safety mechanism triggered: Authorization (This situation is linked to ticket #1155 )

Example: One user opens a shared collection for editing while the other user revokes the first user's grant for the collection. The first user tries to save her/his changes without knowing that permissions have been revoked.

! Currently the first user's changes are still saved (shouldn't #1155). Only when re-reading the collection from database in order to present it in GUI, the change in access rights is detected and error message

Insufficient permissions (Forbidden) [403]
Notification: You do not have sufficient permissions to perform this action. Contact the administrator for more information.

is shown.

ToDo in #1155: Show error message of sort:
"Could not [do something]: You don't have permission to [do something]".

Note:
Sequence of safety checks:

  1. Are you allowed to access the object? (case 3)
  2. Is operation valid given current object status? (case 2)
  3. Has object changed and needs to be reloaded before saving? (case 1)

In situation 1 the first two checks pass and the 3rd fails.

MPDLTam added a commit that referenced this issue Jan 9, 2020
@MPDLTam MPDLTam closed this as completed Jan 13, 2020
@MPDLTam MPDLTam reopened this Jan 17, 2020
MPDLTam added a commit that referenced this issue Feb 3, 2020
- Refactoring of existing code
- Relocated security check into Jena transaction
- Changed exception handling in EditCollectionBean
MPDLTam added a commit that referenced this issue Feb 3, 2020
- Deleted unused Class
MPDLTam added a commit that referenced this issue Feb 4, 2020
Added user that is not logged in
MPDLTam added a commit that referenced this issue Feb 4, 2020
MPDLTam added a commit that referenced this issue Feb 4, 2020
- lower layers were fixed with #1158
- added exception handling for NotFoundException and NotAllowedError
@hofmannc
Copy link
Author

hofmannc commented Feb 11, 2020

Testserver: qa imeji
Browser: ff
Version: 4.8.1 - build date 2020-02-05 11:46:22
User: default
Result: ok with following observations:
Situation 2: Thrown error message is "Error during editing of the collection. " instead of "[Error/Cannot do something]. [Operation not possible/valid]" --> will be fixed in new ticket #1182

Situation 3: will be fixed in ticket #1155

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants