Workflow transition on defaultPage is propagated to its container

Plone Support
,
1

Step to reproduce on a vanilla plone5.2 or plone6 classic:

  • create a folder BAR
  • create a page BAZ inside BAR
  • Publish both BAR and BAZ
  • set BAZ as default page of BAR
  • Retract publication on page BAZ

Expectation:

  • changed the BAZ state only

Sperimented:

  • changed BAR state also

The same happens if page BAZ and foler BAR are private and you publish the page BAZ. You'll get BAR published also.

The same happens despite the workflow associated on the contents. It seems that the matters is the ID of the transaction applied.

Is this a BUG or a feature? :thinking:

alessandro.

2

It's a Bug, if you repeat your steps in the folder_contents view and set state of the page 'bar' via state-button, then only the page is private. Please open an issue.

2 Likes
3

Here at the CMFPlone issue tracker please

1 Like
4

Thank you guys.
Here it is: Workflow transition on defaultPage is propagated to its container · Issue #3932 · plone/Products.CMFPlone · GitHub

alessandro.

2 Likes
5

Well, this is the behavior of Plone since ever (at least 4.x) ... I would not define this as a bug. If a Folder has a default page and you only change the state of the page, you would have to go to the folder_contents always to change the state of the folder too ... this adds IMHO extra complexity to the already complex "default page" thinking ...

1 Like
6

ok. I've got surprised then (Workflow transition on defaultPage is propagated to its container · Issue #3932 · plone/Products.CMFPlone · GitHub)

I would point out that Plone is great in many ways but there are a subset of "features" that row against it's greatness.

There are "complex use cases" doable only by a administrator/developer (and this is expected in all the framework) and other "complex use cases" doable by a simple editor which is GREAT (create custom type, define a whole workflow, content rules, collections, tiles/block, url aliasing, caching rules, translations...)

There are "simple use cases" doable by anyone (and this is expected in any framework) but, when there are "simple use cases" that needs to be done by an administrator/developer we have a problem.

Plone has problems in how it manages, let's say, "top folders" in medium to big portals.

Renaming an item it's a simple thing, a simple/trivial use case.
Publishing/unpublishing an item, the same

Try to rename or publish/unpublish a top folder in a big portal... there are high probabilities that it would not converge due to conflict errors, and the task needs to be delegated to an administrator/poweruser/developer.

In this particular scenario I've got surprised because I unpublished a simple default page, and Plone took over 30 seconds to commit the transaction. Then I realized that it's parent folder got revoked too and Plone, in these cases, fire a recursive security reindex. That folder contained thousands elements.

Renaming a top folder (it's another scenario) it's even worse because Plone does a full reindex (of all indexes) of the whole subtree. not a joke.

This is not meant to be a rant as it might seem but this is just food for thought.

alessandro.

7

I totally agree. A warning should be raised like when you try to delete a related content. I think the linkintegrity package could handle this case, maybe the framework team can think about it.

After the warning, a administrator/poweruser/developer can remove the page as default view and the unpublish it, and reassign it as a default view.

8

Haha ... after 20 years of Plone I still got bitten by this right now. I thought, when I change the state of a default_page in the folder_contents it only changes the state of the page and not the folder too ... nope it changes the whole folder (same logic as in toolbar --> of course :man_facepalming:t3: )

In my special case I need a public folder with a private default page in order to access its contents but get a login when you browse to it directly... don't ask why :wink:

9

I just tried this and it changes the folder too when you change the state of a default page in folder_contents which makes sense, because the state change script is the same.

10

I retract my statement. It's not a bug it's now a feature. :yum:

11

One could argue that when I do this in folder_contents it should change the state of the (default_)page only ... nevertheless in both cases there should be a warning when I do this via toolbar and via folder_contents before performing this action.

12

Isn't the better solution to do the indexing asynchronously?
I thought we already had this builtin for indexing on save so using the same method for renaming, deleting, state change and user deletion (another one that can take time) should be possible?

To keep this in context, with all folderish content like Volto, unpublishing a page will unpublish its contents I presume? So this default page behaviour is consistent with that.

A warning in both cases is probably good but also not taking so much time to do it would also be good. it is a bug if a simple task can't be done due to it taking so long.