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

api.content.get no longer returns content that is inside a inaccessible container #549

Closed
pbauer opened this issue Dec 18, 2024 · 2 comments · Fixed by #550
Closed

api.content.get no longer returns content that is inside a inaccessible container #549

pbauer opened this issue Dec 18, 2024 · 2 comments · Fixed by #550

Comments

@pbauer
Copy link
Member

pbauer commented Dec 18, 2024

Given a private container /Plone/cannot-view and a published item /Plone/cannot-view/can-view I cannot traverse to the item any more since Plone 5.2:

with api.env.adopt_roles(["Member"]):
    api.content.get(path="/Plone/cannot-view/can-view")
with api.env.adopt_roles(["Member"]):
    portal.restrictedTraverse("/Plone/cannot-view/can-view")

I think that breaks user-expectations of the api and should be changed.

In Plone 5.1 it still works, since Plone 5.2 it raises Unauthorized. The reason may be that a different guarded_getattr seems to be used in restrictedTraverse but I'm not sure - the import is the same but the executed code is different.

In a project I instead used unrestricedTraverse and then checked the View-permission for the object:

obj = portal.unrestrictedTraverse(path)
if obj and api.user.has_permission("View", obj=obj):
    ...
@ale-rt
Copy link
Member

ale-rt commented Dec 18, 2024

I am happy if this is fixed.

In a project I instead used unrestricedTraverse and then checked the View-permission for the object:

Which is something similar to what the catalog does:

Fixing this issue should improve consistency.

pbauer added a commit that referenced this issue Dec 20, 2024

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
… user (#549)
pbauer added a commit that referenced this issue Dec 20, 2024
pbauer added a commit that referenced this issue Dec 20, 2024
@pbauer
Copy link
Member Author

pbauer commented Dec 20, 2024

The pull-request fixes it but I'd really like to know which change is the underlying cause and if we can and should address that.

pbauer added a commit that referenced this issue Dec 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants