[MGNLUI-5591] JCR clipboard may contain references to deleted nodes Created: 16/Dec/19 Updated: 24/Jan/20 Resolved: 23/Jan/20 |
|
| Status: | Closed |
| Project: | Magnolia UI |
| Component/s: | None |
| Affects Version/s: | 6.2 |
| Fix Version/s: | 6.2 |
| Type: | Bug | Priority: | Major |
| Reporter: | Christoph Meier | Assignee: | Rishab Dhar |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
CE-demo-webapp; 6.2 (Snapshot: 2019.12.10 09:26:46) OS-X 10.14.6, Forefox-71 |
||
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
| Date of First Response: | |
| Sprint: | UI Framework & 6.2 Ramp up 15 |
| Story Points: | 3 |
| Description |
|
JCR clipboard keeps the references to the copied/cut nodes, even after their possible deletion. In case that happens, even canPasteInto checks may fail (like elaborately described in cmeier's investigation). Proposal to fix: |
| Comments |
| Comment by Aleksandr Pchelintcev [ 06/Jan/20 ] |
|
initial description cmeier I have observed various I differentiate between
to properly update the actions availability. I assume the issues described here have nothing to do with action availability configuration. Case which requires an app restartThis is the "worst case" I have observed. (It has confused me for quite some time. But now at least I know how to reproduce it. The reproduction procedure is a bit complex, but I cannot offer a simpler atm.) To reproduce
The action Publish is not available. It doesnt't help to open a detail editor. This "strange state" may have also an influence on the availability of other actions. I have just analyzed in details those which are listed here. What is described until here, I could reproduce "always". Worst case scenarioIn the "worst" case (of the already worst case ... ups) the workspace seems to be "screwed". Case which requires subapp swapIn this case, the Actions availability on the detail subapp is out of sync, however, by swapping to the browser and then swap back to the detail subapp, the Actions availability gets properly updated. To reproduce
After having published, on the Detail subapp, the action "Publish" remains, the action "Unpublish" does not appear. |