- Issue created by @jessebaker
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
As long as we agree on what the server will pass to the client in π Pass current user's XB permissions to the XB UI Active , work on this could begin in parallel. But that probably makes little sense?
- πΊπΈUnited States mglaman WI, USA
π Pass current user's XB permissions to the XB UI Active is finished, can the updated and agreed upon format be updated here? Are we using raw permissions from Drupal or should it be createPage, etc because that is not what was done in the other ticket.
- πͺπΈSpain penyaskito Seville π, Spain πͺπΈ, UTC+2 πͺπΊ
@mglaman That includes the config-related permissions, which are all-or-nothing so are just flags. But we might want to still postpone on π Update `ApiContentControllers::list()` to expose available content entity operations in `meta` Active for the content related ones.
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
#4++
Given that this could otherwise result in information disclosure vulnerabilities (not access bypass because the server side pieces are taken care of, at least once π [PP-1] Add entity access checks to routes that deal with entities Postponed + π [PP-1] Update `experience_builder.(experience_builder|api.layout.get) routes` to respect content entity update/field edit access of edited XB field Active are done), going ahead and tagging this a blocker for π± Milestone 1.0.0-beta1: Start creating non-throwaway sites Active .
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
- πͺπΈSpain penyaskito Seville π, Spain πͺπΈ, UTC+2 πͺπΊ
- πͺπΈSpain penyaskito Seville π, Spain πͺπΈ, UTC+2 πͺπΊ
Added the different scenarios of permissions that need to be exposed to the client UI.
- πͺπΈSpain penyaskito Seville π, Spain πͺπΈ, UTC+2 πͺπΊ
just formatting
- π¬π§United Kingdom jessebaker
In the interests of keeping things as simple as possible on the FE, I was hoping to get something like the following
JSON:
{ "drupalSettings": { "xb": { [...] "permissions": [ "read global regions", "update global regions", "delete global regions", "read sections", "update sections", "delete sections", ... ], } } }
Because then in the UI checking if we should display a button or not is as simple as, for example:
JSX:
<> {drupalSettings.xb.permissions.includes('delete sections') && ( <button>Delete section</button> )} </>
- @jessebaker opened merge request.
- πͺπΈSpain penyaskito Seville π, Spain πͺπΈ, UTC+2 πͺπΊ
Amazing π
NW per @larowlan review and I think I spotted a wrong permission check, but this looks amazing already and covers more scope than I expected. - π¦πΊAustralia larowlan π¦πΊπ.au GMT+10
penyaskito β credited larowlan β .
- π¬π§United Kingdom jessebaker
Finally got to the bottom of a number of issues that were causing a lot of friction in writing the Playwright tests for this work. All resolved now and ready for another round of review.
The summary on the MR is the most up to date place for all info on this work.
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
Did thorough manual testing. No problems found.
Tip for fast manual testing: change
'permissions' => [ 'globalRegions' => $this->currentUser->hasPermission(PageRegion::ADMIN_PERMISSION), 'patterns' => $this->currentUser->hasPermission(Pattern::ADMIN_PERMISSION), 'codeComponents' => $this->currentUser->hasPermission(JavaScriptComponent::ADMIN_PERMISSION), 'contentTemplates' => $this->currentUser->hasPermission(ContentTemplate::ADMIN_PERMISSION), 'publishChanges' => $this->currentUser->hasPermission(AutoSaveManager::PUBLISH_PERMISSION), ], 'contentEntityCreateOperations' => $this->getContentEntityCreateOperations(),
to
'permissions' => [ 'globalRegions' => $this->currentUser->hasPermission(PageRegion::ADMIN_PERMISSION), 'patterns' => $this->currentUser->hasPermission(Pattern::ADMIN_PERMISSION), 'codeComponents' => FALSE, 'contentTemplates' => $this->currentUser->hasPermission(ContentTemplate::ADMIN_PERMISSION), 'publishChanges' => $this->currentUser->hasPermission(AutoSaveManager::PUBLISH_PERMISSION), ], 'contentEntityCreateOperations' => [],
etc. to test any combination of things.
Found two bugs, both in the same area:
- π¬π§United Kingdom jessebaker
I'm not sure it's possible to actually get into those situations (yet?!) but good catch. At the moment, you can't even access XB if you don't have permission to edit XB pages so if you can access XB then you will always have at least one option in the menu.
Anyway I've added some more robustness around the UI when people have no permissions or can delete things but don't have any other items in the menu which should keep this looking tidy in the future no matter what configuration of permissions people end up with!
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
At the moment, you can't even access XB if you don't have permission to edit XB pages so if you can access XB then you will always have at least one option in the menu.
Is that true? What if I can create/edit articles?
In any case, it won't be true anymore very soon, because π Add permission for "Use Experience Builder" Active will definitely allow you to load XB if you cannot use
Page
s at all, assuming you have an editable XB field on article nodes.Thanks for adding that robustness β I won't test again, I bet you tested it thoroughly ππ
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
/me typed "u", return, cmd+space, click "Save" β¦ and didn't spot that it didn't select π
-
wim leers β
committed 7fd7f19b on 0.x authored by
jessebaker β
Issue #3516641 by jessebaker, wim leers, penyaskito, mglaman, larowlan:...
-
wim leers β
committed 7fd7f19b on 0.x authored by
jessebaker β
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
π€©π€©π€©π€© And β¦ the XB UI actually starts to come fully alive! π§ββοΈ