Skip to content
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

Workflow transition on defaultPage is propagated to its container #3932

Closed
sauzher opened this issue Mar 28, 2024 · 8 comments
Closed

Workflow transition on defaultPage is propagated to its container #3932

sauzher opened this issue Mar 28, 2024 · 8 comments

Comments

@sauzher
Copy link

sauzher commented Mar 28, 2024

BUG/PROBLEM REPORT (OR OTHER COMMON ISSUE)

What I did:

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

  1. create a folder BAR
  2. create a page BAZ inside BAR
  3. Publish both BAR and BAZ
  4. set BAZ as default page of BAR
  5. Retract publication on page BAZ

What I expect to happen:

  • changed the page BAZ state only

What actually happened:

  • changed folder 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 applied transaction.

What version of Plone/ Addons I am using:

  • plone4, plone5.2 or plone6 classic
@yurj
Copy link
Contributor

yurj commented Mar 28, 2024

@stevepiercy
Copy link
Contributor

What happens if you put two pages inside a folder, and unpublish only one of the two pages?

@sauzher
Copy link
Author

sauzher commented Mar 28, 2024

@stevepiercy The issues raises only when the page is set as defaultPage of its container. Only one page at time can be the default.

@yurj the toolbar link is 404. Alas, the plone demo site is automatically reset often to be useful as reference here.

@yurj
Copy link
Contributor

yurj commented Mar 28, 2024

it is 404 because I've deleted the `_authenticator' value. The main part was the link pointing to the folder instead of the page.

I'm thinking it to be a feature:

https://github.com/plone/plone.app.content/blob/2a089344cc5ff99ef6a3be578c88c7c8619b1027/plone/app/content/browser/content_status_modify.py#L129C1-L142C18

        # If this item is the default page in its parent, attempt to publish that
        # too. It may not be possible, of course
        if check_default_page_via_view(context, self.request):
            parent = aq_parent(context)
            try:
                parent_modify_view = getMultiAdapter(
                    (parent, self.request), name="content_status_modify"
                )
                parent_modify_view(
                    workflow_action,
                    comment,
                    effective_date=effective_date,
                    expiration_date=expiration_date,
                )

It is there from many years, still in content_status_modify.cpy script.

@stevepiercy
Copy link
Contributor

I think it's a feature, too. It does not make sense to publish an empty container. If you retract the default view of a container, then the container itself should also be retracted. If you want to have the container remain published, then set another page as the default view.

@sauzher
Copy link
Author

sauzher commented Mar 29, 2024

@petschki
Copy link
Member

petschki commented Apr 1, 2024

I would also say this is the expected behavior for defaultPages. Otherwise you can change the folder state only via folder_contents or we have to implement an extra action in the toolbar for the "defaultPageContainerState" which adds extra complexity to the already complex "default page" thinking ...

EDIT: In Volto there are no Folders at all, so the folderish page behaves the same like Classic-UI defaultPage when you change workflow states ... which all in all is more understandable, than the other way IMHO

@mauritsvanrees
Copy link
Sponsor Member

I would also say this is expected behavior.
It may have surprised you, but not doing it this way would be more surprising.

@mauritsvanrees mauritsvanrees closed this as not planned Won't fix, can't repro, duplicate, stale Apr 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants