Extremely Slow to Change Workflow State

To be fair, I really like the implementation when you demo it that way. It makes sense. The docs make me think Plone is harder to work with than it is.

But when you have this:

And a user casually changes that folder to private...

you get this:

image

flipmcf via Plone Community wrote at 2022-5-19 14:05 +0000:

...
First, I have a question:
True or false: The most accepted way to change an object’s permission is through a workflow transition.

Most of my analysis has this truth a foundation. If it’s not true. I need to step back.

This is true for permissions usually controlled by a workflow, e.g.
View and Modify portal content.
Of course, it is not true for other permissions (but they can
likely be disregarded for this discussion).
`

I think this is false, but not sure.

It is true (in general).

But, typically, for permissions controlled by a workflow, there
is an override at the object itself and it usually prevents inheriting
from above.
For those objects, higher up permission mappings for respective permissions
are not relevant.

I was unaware that an indexing took place. Well, of course the object being transitioned needs to be reindexed, but not it’s children. At least that the position I’m defending and the subject of this whole post.

It depends on the workflow:
assume you have a workflow where making a folder private should
make all chrildren private. Then, the children must get reindexed
(partially) to prevent the children to be found by searches.

...
Other objects in that folder with workflows assigned will retain their permissions.

Provided that the local permission mapping has inheriting from above disabled.

So, my experiment is to use debug to change a workflow state on a folder to private, reindex only that folder, (no transition events) and see if the image becomes private.

If it is not reindexed, a search can return it.

Hi!

you can submit a bug report but I would try on a local installation. The site demo.plone.org is cached, so you should maybe add a parameter in the url to get around it (adding &a=1 for example and so on) everytime you change something. Also in the left screenshot the page link is red, so it is private. You've to publish it If you want Anonymous to find it.

In Plone 6 the public content is searchble by Anonymous even if the containing folder is private. So the docs are correct IMHO. I didn't try with a local Plone 5.2.

Hi.

Local test was complete, but was more complex. Not default types.
There is a small chance that these non-default types and workflows affected this test.

  1. created a 'section' (basically a folder, but customized)
    Initial state 'public draft'
  2. created a 'story' within the section (basically a news item, but customized)
    Initial state 'public draft'

Specifically in this order:
Transition story to 'public'
Transition section to 'private'

story is accessible by url and available in search to anonymous users.

One of us is different: demo.plone.org or engtest dot rfaweb dot org slash english

Looks like you need to reduce that user's roles or permissions. That's the real problem, not the "I brought a quill to a typewriter documentation fight" problem :wink:

You are absolutely right!

But not really.

In our workflow, a senior editor or even a junior editor might get word from above to remove something from the website. That’s a ‘make private’ move.

Also, regardless of the role, the ‘creator’ role will always allow this transition.

I’m not saying a good role assignment won’t help. Especially regarding these huge folders, But I am saying it just pushes the problem to an edge case.

  1. No user except manager should be able to kick off a multi-hour reindex.

  2. It is not clear to the average user that changing the workflow state of a folder has the potential to kick off a multi-hour job that writes to thousands of objects.

Transitioning a workflow should not lead to “the server is down”.

Maybe a warning to the user is appropriate? I had a similar situation not so long ago:

Off the top of my head then I’d say you need a queuing system like CastleCMS’ for handling potentially long running operations.

Or make it so creator doesn’t have that on folders

Or make it so that transition requires an extra bit of logic