- Issue created by @mayur-sose
- 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
On the surface, this seems to be a pure client-side matter: it should handle 403s more nicely. That's true, and it'd solve 90% of the problem.
But in reality, we need that last 10% too: the XB UI was initialized with a certain set of permission assumptions: those passed by the erver (at
ExperienceBuilderController) to the client, after which the client "forever" assumes these to be true.So we need a mechanism to inform XB that XB needs to reload the page (which seems "a lot" but really isn't, because … permissions don't change often mid-session!). We already have polling for auto-saving. So … that's what should provide that instruction.
Note that Drupal already has the necessary information for exactly this, worked on by yours truly over a decade ago in #2005644: Use client-side cache tags & caching to eliminate 1 HTTP requests/page for in-place editing metadata, introduce drupalSettings.user.permissionsHash → :
$settings['user']['permissionsHash'] = \Drupal::service('user_permissions_hash_generator')->generate($user);IOW: this requires both client-side and server-side changes.
- 🇫🇮Finland lauriii Finland
This is slightly off topic but we probably need a similar issue for changes to the code base (i.e. XB version). The reason I'm bringing this up here is so that we can think what other use cases should force a refresh in the client.
