Defect #1256
Open multiple metadata edition forms can mess session data and result in data inconsistency
Status: | Affected | Start date: | 02/04/2016 | ||
---|---|---|---|---|---|
Priority: | Normal | Due date: | |||
Assignee: | - | % Done: | 30% | ||
Category: | CATALOG | ||||
Target version: | - | ||||
Affected version: | 4.0.0 |
Description
Open multiple metadata edition forms can mess session data and result in data inconsistency:
How to reproduce (not recommended in production !):- Open metadata "A" in edition
- Open metadata "B" in edition (don't close A, use a new browser window or tab)
- Save metadata "A"
- Cry
- On edit, multiple values are stored in session, and they're not linked to IDs/GUIDs
- If you edit a second item, the first one's data are overwritten
- If you save the first item form, with some of the session's data of the second one -> big mess (examples: wrong relations stored in DB, wrong ids stored in CSW server... )
- Clean option (aka rich man's option) : rewrite everything, at least:
- Session store on edit
- Save
- All ajax calls
- Import
- Replication
- Synchronize
- Child synchronize
- Everything that I missed
- This also means that we move away from component creator's logic / MVC usage
- Simple option : keep the 'one form at a time' and disallow the save of an metadata if the session ID's doesn't match with form's values
- Check on save, inform on fail
- Inform user by AJAX that the metadata cannot be saved anymore (to prevent loosing to much work of edition)
- Lock the form
- Show a message (see screenshot : simple_option_lock.png)
Dear TC, what do you think ?
History
#1 Updated by Blatti Yves about 2 years ago
Simple option could be achieved with an ajax polling, and disable the form could be done like this:
//disable form jQuery('.metadata-edit.front-end-edit #form-metadata select').prop('disabled', true).trigger("liszt:updated"); jQuery('.metadata-edit.front-end-edit #form-metadata button').prop('disabled', true); jQuery('.metadata-edit.front-end-edit #form-metadata a.btn').not('.collapse-btn').prop('disabled', true).addClass('disabled'); jQuery('.metadata-edit.front-end-edit #form-metadata :input').filter(':text,:password,textarea').prop('disabled', true); //show message Joomla.renderMessages({'error': ['<b>Cette fiche est verrouillée</b><br/>Vous avez ouvert une autre fiche en édition, ou votre session a expiré. Il est impossible de sauver cette fiche.'] }); //move to top jQuery("html, body").animate({ scrollTop: 0 });
#2 Updated by Blatti Yves about 2 years ago
- % Done changed from 0 to 10
I proposed a temporary fix in revisions 9454 + 9455 + 9463, it's the client side polling/locking.
#3 Updated by Blatti Yves about 2 years ago
- Assignee deleted (
Technical Committee) - % Done changed from 10 to 30
Poor man's version will be integrated in V4.4.0.
Issue remains open for a cleaner fix in future.
#4 Updated by Blatti Yves about 2 years ago
Temp fix implemented in #1268
#5 Updated by Blatti Yves over 1 year ago
- Priority changed from High to Normal