Provide the client with permissions flags for create content

Should this be postponed on 📌 Allow XB to be used on all node types Active

I think we should still do this for page + node--article, even if 📌 Allow XB to be used on all node types Active would definitely need to refactor this.

This is a because without this, the following will always be visible:

Secondarily, this hard-blocked 📌 Add generic create entity support Active .

Adjusted the proposal.

Note that this can assume a single XB field per content entity type+bundle, if that changes in 📌 Spike: explore merits of one XB field per exposed slot in content templates Active , it'll be up to that issue to tweak the logic introduced here.

Looks great!

One question, plus needs a follow-up for fixing cacheability.

Already approved 👍

Back to Wim per !1178.
I'm 50% on each option, so your call. The client UI will probably need to check the absence of the key anyway.

I wanted to merge this, but on a final pass I'm afraid that the proposal was too incomplete after my adjustment in #6. 😅

Nope, that's because XB controls the "create entity" route: experience_builder.api.content.create — which is why simple booleans suffice, and the XB UI can then call its contentApi.createContent.

Attaching the patch that I had written locally, but which fails on the way it tries to pass the label via XbResourceLink's target attributes, because it's a translatable string, not a plain string.

Merged :)

This unblocked 📌 Add generic create entity support Active , and increased the need for 📌 Add access handler cache metadata to ExperienceBuilderController Active .

I'm slightly too late to the party but I've just merged in upstream changes over at ✨ Create React Permission Utilities Active and the shape of the permissions object is now more complex as a result of this and as a result is going to make the FE code more complex to work around it.

Previously xb.permissions was a simple

interface permissions {
  [key: string]: boolean;
}

This made it easy for the FE to quickly assert if a user had or did not have a given permission by simply checking that list of booleans.

Can this new contentEntityCreateOperations object be moved into the root of drupalSettings.xb instead of inside the permissions object?

#15: or … what about going from this which was merged:

"permissions": {
  …
  "contentTemplates": false,
  "contentEntityCreateOperations":{
    "xb_page":{"xb_page":"Page"},
     "node":{"article":"Amazing article"}
   }
}

to

"permissions": {
  …
  "contentTemplates": false,
  "create:xb_page": 'Page",
  "create:node:article": "Amazing article",
}

?

(Casting that string to a boolean is trivial.)

The format of contentEntityCreateOperations which was merged is useful - it's easy to iterate over to build the list of "New x" buttons in the UI. Your proposal in #16 means, to build the list of "New x" buttons, I would have to iterate over the permissions object, filter to just keys that starts with 'create:' and then split the key by : to get the entity type and bundle info.

Maybe there is some value to having the permissions listed in the permissions object as you propose, but I think only if that was in addition to still having the info in the original format elsewhere e.g. drupalSettings.xb.contentEntityCreateOperations

"contentEntityCreateOperations":{
    "xb_page":{"xb_page":"Page"},
     "node":{"article":"Amazing article"}
   }

Follow-up MR moving the contentEntityCreateOperations outside of xb.permissions

Automatically closed - issue fixed for 2 weeks with no activity.