-
Notifications
You must be signed in to change notification settings - Fork 10
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
With Elemental a page level save & publish fails to represent element update (inline edits only) #50
Comments
Having a hard time reproducing this one. Could use more details or a screenshot. |
I have split the incorrect author name as I believe this is separate (can reproduce without Elemental) |
I have updated the OP with recreation details :) |
I'm pretty sure this is the expected result. From what I can tell, you don't need separate users to replicate this issue. What's happening here is just highlighting the difference between publishing element changes on page save versus from with in the elemental editor. These are always going to be separate events. Snapshots tracks user actions, not database mutations. This is because, fundamentally, the snapshots module is just a timestamp provider, so tracking multiple mutations in the same user action is something we've tried to avoid. For clarity:
Of course, it is true that in that publish, a block was modified, but the block is treated as page content. You can also modify the title of the page, hit publish, and you don't get a "modified page" entry. You just get "publish." If content blocks were created lazily, e.g. "add new" just created an entry in the UI and not in the database, then we wouldn't expect to see anything in the snapshot table for that event, but because that add event represents something new being added to the ownership graph (albeit "empty"), we get a new snapshot. |
Incorrect author issue should be resolved by: a06a95f |
Sorry, missed the earlier comment. I'm happy with that, I was thinking about what you've explained previously too. I guess although the technical differences are apparent, the immediate differences to a user may not be... it becomes far more to the domain of UX rather than "computational deficiency". I guess the outstanding question I have that might turn this around again is: |
This is for inline editable elements only, in combination with an immediate publish action (not save, then publish - thus does not affect 'separate screen' element editing).
A new version entry is created, but lists the wrong author (see #51), and fails to show that an element was altered as part of the snapshot. An auditor is left with an entry containing no edits, and an invalid attribution.
Recreation
admin/pages/edit/show/2
, add aContent
element.Save & Publish
on the Page.admin/pages/edit/show/2
, and edit the Content elementSave & Publish
on the Page."Editor" adds & edits content element
"Default Admin" edits content element
Applies to inline editing only
Notes on other "workflows"
Non-inline element edit (e.g. userform), page level publish
This is a natural two part process and does not manifest the issue, as the separate save step creates a snapshot entry.
Individual element save, page level publish
Does not manifest the issue, as it is a two step process as above with non-inline editing
Individual element publish
Does not manifest the issue. Could not replicate with inline editing as an error seemed to occur. Cannot manifest with non-inline editing either, as the save & publish action creates a single workflow entry at that point, as does saving (& publishing at page level).
Untested
I have not tried any further usage paths such as publishing via campaigns.
The text was updated successfully, but these errors were encountered: