[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: PNG File column.png     PNG File message.png     PNG File pending-changes-message.png     PNG File prepare.png    
Issue Links:
relation
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.

  • I logged in as superuser and modified the about page by adding a new component
  • I logged out and logged in again as peter, went to the about page but saw no message.

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 missed to add a little detail

I executed all the described steps as the user "Peter" and there was no "superuser" editing this page.

Log in as "Peter" and make sure there is no superuser editing this page
Add a component with areas to the page. I used the column layout.
You will get the described message although there is no other user editing the 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 ]

We might be able to delay the registration of the observation-listener until the page has been loaded.

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:

  • Log in as "Peter" and create a new page
  • Open this new page and make sure there is no superuser editing this page
  • You will get the same message
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 ( MAGNOLIA-6686 ), message will likely change too indicating now correctly that page was changed by user herself making it less confusing.

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?
seems to be a longer shot in that case, as I don't see ourselves unregistering/reregistering obs whenever we add a component—just in case it has some auto-generated content.

#2: I could imagine such an mgnl:autoGenerated property; yeah, few questions arise then:

  • does soft-locking receive events with enough granularity to detect it, or does it simply listens to arbitrary events under that path?
  • do we want to remove that property when no-longer needed/and if so, when? I don't have any reasonable answer for that one.

#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)

  • and yeah, that would be a behavior change

#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?
(btw, I'm curious to see how 4.5 soft-locking was circumventing that, if it did)

Comment by Federico Grilli [ 30/Sep/16 ]

(btw, I'm curious to see how 4.5 soft-locking was circumventing that, if it did)

I got curious too, of course I guess that is how we worked around it in 4.5.x

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).
In audit logging, we log statements like "superuser (on behalf of peter)..." iirc

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.

Generated at Mon Feb 12 07:14:44 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.