[MGNLSLOCK-38] Peter gets mistakenly "pending changes by superuser" messages Created: 18/Nov/15 Updated: 09/Feb/17 Resolved: 16/Oct/16 |
|
| Status: | Closed |
| Project: | Magnolia Soft Locking Module |
| Component/s: | None |
| Affects Version/s: | 2.5 |
| Fix Version/s: | 2.6 |
| Type: | Bug | Priority: | Neutral |
| Reporter: | Fabian Schneider | Assignee: | Oanh Thai Hoang |
| Resolution: | Fixed | Votes: | 5 |
| Labels: | support | ||
| Remaining Estimate: | 0d | ||
| Time Spent: | 3d 1.5h | ||
| Original Estimate: | 5d | ||
| Attachments: |
|
||||
| Issue Links: |
|
||||
| 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: | Saigon 66 | ||||
| Story Points: | 8 | ||||
| Description |
|
Steps to reproduce on the demo instance: 1. Make sure there are no unpublished changes. 2. Add a component with areas such as "column layout" to a page The user Peter will see the following message although there is no unpublished content and no editing superuser. |
| Comments |
| Comment by Federico Grilli [ 18/Nov/15 ] |
|
Thanks for reporting this issue. I moved it to the SoftLocking module cause it concerns this functionality. Actually I wasn't able to reproduce it.
The behaviour you're describing is actually expected if you logged at the same time (two different browser sessions) with e.g. both superuser and peter. In that case if both users were looking at the same page and, say, superuser modified it, then peter would see that message. It has nothing to do with the publish status of the page, rather with modifications of a page opened/edited concurrently by two or more users. I'll close the issue but feel free to reopen it if you think this is not correct and if you have more details about how to reproduce it. Hope this helps. |
| Comment by Fabian Schneider [ 19/Nov/15 ] |
|
Thanks for your response and sorry for the short description. I executed all the described steps as the user "Peter" and there was no "superuser" editing this page. |
| Comment by Espen Jervidalo [ 19/Nov/15 ] |
|
This is most likely due to the area nodes being auto-generated during rendering. Since the Soft-locking is observing the website-workspace for changes, it will detect the changes and display the warning. So it is essentially correct: The page has been modified during rendering. AFAIK there's no way to distinguish auto-generated content from user-generated one. We might be able to delay the registration of the observation-listener until the page has been loaded. |
| Comment by Fabian Schneider [ 19/Feb/16 ] |
This would be very helpful. The behavior described confuses our authors constantly. |
| Comment by zzzzJens Kolb (Lemonize) (Inactive) [ 29/Mar/16 ] |
|
@ejervidalo - any news on this ticket? |
| Comment by Diana Racho [ 02/Jun/16 ] |
|
Hi, we have a similar problem:
|
| Comment by Jan Haderka [ 26/Aug/16 ] |
|
Can you try to reproduce it on Magnolia 5.5.? With changes done for ops executed in system context ( We might still want to defer registration of the observer tho to remove it completely. |
| Comment by Ervin Vystup [ 26/Aug/16 ] |
|
Yes, I was able to reproduce it on magnolia-enterprise-pro-demo-bundle-5.5 snapshot from August 26. Superuser is still mentioned in the message. |
| Comment by Mikaël Geljić [ 30/Sep/16 ] |
|
#1: delaying could work for page-level auto-generation; wouldn't it be (much) harder to achieve the same on component-level? #2: I could imagine such an mgnl:autoGenerated property; yeah, few questions arise then:
#3: longer shot as well, though I'd agree it would make more sense as both cases are user-induced authoring actions (—one could argue rendering is a little ill/late to manipulate content)
#4: differentiate system user from superuser: same thing, too big if we want this at all? #5: ignore all events from the superuser user: would argue admins should have proper users with superuser role instead of using superuser straight. Perhaps we can get consensus on that? |
| Comment by Federico Grilli [ 30/Sep/16 ] |
I got curious too, of course
|
| Comment by Mikaël Geljić [ 04/Oct/16 ] |
|
Thanks fgrilli, had suggested we try a similar approach to what's been done in audit-logging: change auto-generation to eventually set mgnl:lastModifiedBy to some form of user-(privileged). Biggest concern there is when authors create pages with autogenerated areas/components without opening the page at all. Autogeneration will eventually kick in via anonymous. But at least this case here should no longer occur, since soft-locking goes along with the page-editor. Either page will be autogenerated before being edited, or peter will get a notification about himself (privileged), which we can further discard if necessary. Still no silver-bullet imo but I don't mind much there. |