[MAGNOLIA-3250] Content deleted from authoring instance even when deletion from public instance(s) fails Created: 14/Jul/10  Updated: 17/Jan/11  Resolved: 07/Jan/11

Status: Closed
Project: Magnolia
Component/s: activation
Affects Version/s: 4.3.2
Fix Version/s: 4.4.2

Type: Bug Priority: Major
Reporter: Arjan van Bentem Assignee: Federico Grilli
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relation
is related to MAGNOLIA-3456 Self-publishing a deleted page will m... Closed
is related to MAGNOLIA-2156 Editors can delete content (direct ac... Closed
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:

 Description   

Deletion (and deactivation) seems to rely on the user credentials on the authoring instance and the public instance(s) to be the same. If authentication on the public instance(s) fails, then deletion will fail with an HTTP 401. The editor is shown an error message.

However: even when deletion has actually failed, the content is still deleted from the authoring instance. One needs to log in to each public instance to fix this.

Example error message (same message for normal deactivation, and for deactivation triggered by deletion):

Can't deactivate: : 2 errors detected:
Not able to send the deactivation request http://<primary-server>:8080/.magnolia/activation: Server returned HTTP response code: 401 for URL: http://<primary-server>:8080/.magnolia/activation on <primary node name>
Not able to send the deactivation request http://<secondary-server>:8080/.magnolia/activation: Server returned HTTP response code: 401 for URL: http://<secondary-server>:8080/.magnolia/activation on <secondary node name>



 Comments   
Comment by Arjan van Bentem [ 24/Jul/10 ]

As an aside:

When using the Workflow module and configuring a /commands/website/deactivate workflow, then that workflow also affects the standard right-click delete option. As deletion is obviously deactivation followed by deletion, firing the standard delete first fires that /commands/website/deactivate workflow (at least the way I configured that). Immediately after creating that workflow, the delete process continues to really remove the node. Hence, even before a publisher has taken a look at the work item, the given node is already gone from the authoring instance.

So: when changing the deletion command to not actually remove the content from the authoring instance when deactivation has somehow failed, then maybe that fix can also take other reasons for failure into account, like the "in progress" of a workflow.

Comment by Federico Grilli [ 28/Dec/10 ]

I was not able to reproduce this bug on Magnolia 4.4: I actually got a 401 response code error but this time author and public instances are consistently aligned when deletion and/or deactivation fails, e.g. no node deleted on author but still present on public. The previous buggy behavior seems to have gone with the support for mgnl:deleted, deletion activation and removal of the content after activation of deletion (see also MAGNOLIA-2251).

Comment by Federico Grilli [ 07/Jan/11 ]

Seems to have gone with 4.4 release and the resolving for MAGNOLIA-2251. The current correct behavior can also be quickly verified on our demo sites.

1) go to http://demopublic.magnolia-cms.com/.magnolia/pages/adminCentral.html as superuser
2) change superuser password
3) go to http://demoauthor.magnolia-cms.com/.magnolia/pages/adminCentral.html as superuser
4) delete a page and activate the changes

In the inbox you will see a publishing error message mentioning the 401 response code. Nonetheless, the page is still there on the author as it is on the public.

I tested the correct behavior both on a EE installation and an CE one.

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