Extremely Slow to Change Workflow State

I agree with everything there. It does depend on the workflow. So….

Should the default folder workflow recursively transition child objects and update security settings?

I would say no. Save the time and cpu.

——-
The “advanced” workflow page does have the checkbox to transition child objects. The documentation says to use that if you need to “make a folder and all it’s contents private”. It’s still possible, even without designing a special workflow, it’s just not the happy-path through the UX.

By default permissions are acquired from parent objects, so children need to be reindexed if permissions changed.
We don't really have a good way to check for that, so on workflow change or permission change we just reindex it - at least that works (most of the time).

There's an issue for this here @@sharing causes reindexing of a possibly large amount of content without warning and without feedback · Issue #1270 · plone/Products.CMFPlone · GitHub . It refers to experimental.securityindexing, which aims to aid in this.

It would be awesome if you could try experimental.securityindexing out and see if that would still work!

Roel Bruggink via Plone Community wrote at 2022-5-18 18:14 +0000:

By default permissions are acquired from parent objects, so children need to be reindexed if permissions changed.

The permissions managed by a workflow are usually not inherited
but maintained locally at the object.

Therefore, I would provide a way to control whether changing
a folder state should update the security setting of its content.
When I have understood a former comment correctly, then this is
already possible.

1 Like

afaik when, say, the View permission is changed, reindexObjectSecurity is called so portal_catalog does/doesn't return the children. That should be the allowedRolesAndUsers index.

I’m not feeling confident yet on this discussion. I don’t know if I’m not explaining my case well, or if there is much more at stake than I think.

I will admit that it’s risky to change the paradigm “run security checks just to be perfectly sure”.

Starting from the documentation (see link above) but not using documentation as a foundation of the argument.

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.

I think this is false, but not sure. 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.

For default content types and workflows, If a folder is made private, a direct-descendent child image will acquire the folders permissions because the image has no workflow state property. Acquisition rule.

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

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 so, then there is no reason to reindex the image.

Other objects that do have workflows are not transitioned, so the user is not changing their security, and indexing is unnecessary.

Does this make sense?

From documentation:

  • However, any published content of a privatefolder (or even of any of its sub-folders) willappear in the site search, even for anonymous users.

Are these two statements at odds? Is the built in “site search” concerned about allowedRolesAndUsers

Is there other use cases I’m missing?

More importantly, from the docs:

Thus, putting a folder in the private state is not a guarantee of security for any of its contents. Unless, of course, all the content has been made private, as well. This can be done in bulk and in a single step, as described in Advanced Control.

Those docs are incorrect. Published pages inside unpublished folders are not searchable by anonymous users - nor other users who cannot view the unpublished folder.
Try English for fun :slight_smile:

This is why the indexing happens and why it takes so long :smiley:

It’s maybe an important distinction to be made between “workflow transition to private” and “Change View Permission”

They are closely related.

But workflow transitions encapsulate instructions to update view permissions.

If there were two UI paths: one for workflow and one for view permissions, I would think users would expect view permission changes to be recursive, but not workflow state transitions.

I still think workflow transitions should not reindex the children.

But I’m afraid it’s only my use-case, and I’m not seeing a bigger picture yet.

Also, the “indexing acquired attributes” argument seems strong. If I index an image (no workflow state) does that image’s metadata get written with an explicit view permission?

Or does a request of image metadata view permissions ‘miss’ the attribute and look at parent metadata instead?

(Acquisition hurts my head. Thanks Jim!)

Ha! Awesome!

Documentation -vs- implementation fight!

I love my job.

1 Like

Implementation always wins :wink:

2 Likes

Write the documentation first! :innocent:

I'll bet that the docs were written first, but didn't get updated after fixing the problem.

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