ISSUE-252: User variation does not permeate to Menu Local task (tabs) render cache when viewing an AMI set #253
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…t (on entity view/rendered page) is not varying by user This is one way of solving it, AMI set entities cache should not vary by "Role" bc the fact that we have "operation own AMI set" permissions makes same role -> different behavior based on how sees the Object. That works well on the actual "access" but as explained in the comments of this hook leads to diss-appearing tabs (not the actual permission/access to the route) when two users sharing the same Role access one of those users owned AMI set. Another way would be to return even the neutral access responses (so the case when the not owner access it) with the "user" context ... will test tomorrow what the effect of that is. @alliomeria i will need to evaluate if this also happens with Metadata Display entities
DiegoPino
added
External Bug
Contributor
|
This is newer to me too, @DiegoPino, probably because most of the time I'm always logged in as an/the admin role. The double/stuck 'Edit' button was in an IR partner, yes--and thinking back, it was only happening for a user with a non-admin role type. |
Member
Author
|
@alliomeria thank you. Will ask you more tomorrow about that previous issue. Appreciate it |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is one way of solving it, AMI set entities cache should not vary only by "Role" bc the fact that we have "some operation on own AMI set" permissions makes same role -> different behavior based on who sees the Object. That works well on the actual "access" but as explained in the comments of this hook leads to disappearing tabs (not the actual permission/access to the route) when two users sharing the same Role access one of those users owned AMI set. Another way would be to return even the "neutral" access responses (so the case when the not owner access it) with the "user" context ... will test tomorrow what the effect of that is. Weird is no core/contributed entity does that. @alliomeria i will need to evaluate if this also happens with Metadata Display entities on format strawberry field.
Caching here is really not a performance issue. One will never have 1 million AMI sets, nor 1 million Twig templates ... also this really looks like a Drupal 10.2++ or 10.3++ change, we never had that before and we are not the only ones reporting stuck Menu tasks (I even think we saw 2025 something like that, a "weird" edit button in one of our partners NODES @alliomeria ? maybe an IR repo?)