-
Notifications
You must be signed in to change notification settings - Fork 0
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
LPS-134986 Flattening Permissions #1487
LPS-134986 Flattening Permissions #1487
Conversation
Please only forward necessary changes to Brian Chan during stabilization. Nonurgent changes should wait until the ongoing DXP 7.4 GA1 and Portal 7.4 GA4 release has been completed. For more details on the release timeline and status, see product-delivery. |
To conserve resources, the PR Tester does not automatically run for every pull. If your code changes were already tested in another pull, reference that pull in this pull so the test results can be analyzed. If your pull was never tested, comment "ci:test" to run the PR Tester for this pull. |
All the planned changes are just for SearchPermissionDocumentContributorImpl, right? |
SearchPermissionDocumentContributorImpl and I also believe we need them in SearchPermissionCheckerImpl. But yes, just for Search. |
Please see joshuacords#99 |
LPS-134986 and conversation on PTR-2599.
Note: Arthur suggested I have you review this @Preston-Crary here.
Previous PRs:
liferay-appsec#483
liferay-appsec#480
Goal: Create a permission flattening method to provide what will be indexed by the Search Engine in order to properly permission filter at the Search Engine Level. This method is necessary for LPS-134878. The expected output of this method is a Set of Sets of RoleIds whose combination describes the minimum roles necessary to view a Asset including the permissions inherited from it's parent folders.
Quick Example: Consider this structure: JournalFolder1 > JournalArticle
JournalFolder1 View Permission Roles: Role A, Role B
JournalArticle View Permission Roles: Role A, Role C
The desired output for the JournalArticle would be: [[Role A], [Role B, Role C]] (as roleIds).
[Role A, Role C] or [Role B, Role A] aren't necessary because simply [Role A] sufficiently describes the minimal view permissions.
[Role B, Role C] describes that both Roles are necessary for the user in order to view the JournalArticle.
Author: @joshuacords
cc/ @arthurchan35