Rebased, if it passes tests it's RTBC.
I have a preference for a collection_permission as mentioned in
#9
🐛
Content authors cannot see components
Active
.2, but Wim has a preference for the proposal at
#9
🐛
Content authors cannot see components
Active
.1 (the current implementation). As apparently the _user_is_logged_in is not a blocker anymore for [#16136330], we can leave this as is, and decide later if we need (or not) a follow-up.
No, we still need to do that. The access handler has changed, but the 'administer themes' permission is still there in the route access requirements.
Created draft MR with the discoveries from 🐛 ContentCreatorVisibleXbConfigEntityAccessControlHandler's `view` access must refuse access to disabled config entities Active
Created 📌 Implement `lookup_keys` in Component for optimized queries Active
penyaskito → created an issue.
Spend some time looking at this with @bnjmnm.
We have two options:
a) Adding _none to the json schema, and then unset the _none on submission because we definitely don't want that stored.
b) Doing this client-side (on DrupalSelect or InputBehaviors).
In the drupal widget world, this happens on #element_validate, where we unset the value if _none and not required.
As we aren't triggering that on props widgets (and that's fine AFAIK), I think is less hacky to replicate that client-side. Ideally this would be contained in DrupalSelect, so looks like the less hacky of the alternatives while both look like similar efforts.
+1
If I got this right, we are missing issues for:
- Add permission for "Publish Experience Builder Content" (see point 12 in the IS).
- Add permission for "Use Experience Builder", so we can access XB without an actual content (e.g. so we can create the first page).
I think this should be PPed on 🐛 ContentCreatorVisibleXbConfigEntityAccessControlHandler's `view` access must refuse access to disabled config entities Active (which should be ready to land if RTBCed).
Re #9: A `collection_permission` might be unavoidable. See
#3525572-11: Implement OAuth2 authentication for API endpoints related to code components →
where Bálint has issues with oauth, and we might want to remove the _user_is_logged_in
✨ Enum vales do not have translatable labels Active landed in time for 11.2.0
True
The key to potentially rethinking our permissions is that when using them in OAuth2 scopes, we need to have 1:1 relationships. A scope can't be associated with multiple permissions.
Is this a limitation of the dependencies we are using? I don't think it's a technical limitation by oauth2 itself.
Working on the PoC found a bug with the current implementation, to consider when implementing tests for this.
Attaching patch for the fix.
balintbrews → credited penyaskito → .
TBH was a full PoC. Just the last developments of the new ComponentSource ideas broke other things ^_^ and didn't update yet.
I plan to update this tomorrow morning and maybe spend some time here.
This is partially unblocked, as we could hardcode segmentation rules for now.
Will see if
📌
Expose available segmentation rules via HTTP internal API
Active
can be tackled first though.
➡️♻️
Yes! Moving to 📌 Personalization component source Active
📌 React UI for creating Personalization Segments Postponed and potentially most of 📌 React UI for editing segmentation rules in Personalization Segments Postponed are unblocked now!
Unblocked now!
Thanks, this is a bit annoying.
balintbrews → credited penyaskito → .
Crediting wim leers, effulgentsia for work on architecture.
I thought this was ready, but wait, we still need the auto-save integration.
Fixed issue summary.
Unpostponed.
Created 📌 Add FilteredPluginExistsConstraint constraint for validating Segment config entity Active , back to RTBC
penyaskito → created an issue.
Fix looks good, so good that it broke the tests that assumed a theme that it's not installed. We need to fix those tests.
penyaskito → created an issue.
penyaskito → created an issue. See original summary → .
🏓 Back to NR for feedback.
We can definitely be extra-safe and make uuid optional instead of removing it, but Occam's Razor says this was a copypasta 10 years ago.
This one is not a beta-blocker per @lauriii, and definitely the lesser priority of the 4 defined ones.
We would need some research on how we plan to do this, mapping with a field? using a geoip external service? Other segmentation services?
In that edge-case, I'd assume there is a change: the updated timestamp.
Not sure how we would like to handle it, but IMHO works as expected.
I think this is good enough for unblocking other issues.
Created a bunch of follow-ups.
I think this is good enough to iterate with.
penyaskito → created an issue.
penyaskito → created an issue.
penyaskito → created an issue.
penyaskito → created an issue.
penyaskito → created an issue.
You don't post your recipe, so just guessing, but FYI recipes don't install dependent config _entities_ unless explicitly said.
You need
config:
import:
your_module:
- node.type.foo
Tagging as we don't have a component.
Kinda related I just created
✨
Conditions should have a flag for ANY/ALL
Active
Wish we had a component, using a tag meanwhile.
penyaskito → created an issue.
Credits for inputs.
Rebased again, guess too late for 11.2.0 now tho.
Assigning for the feedback you asked and removing tag. Not saying that you are the one who should fix the tests 😁
penyaskito → created an issue.
Thanks!
penyaskito → created an issue.
Looked a bit at this with Gábor.
This will be the first step to make Webforms XB compatible, but not enough. I'd suggest we keep the scope here to make it FullyValidatable.
The bad news, as this uses a yaml blob in its config, a custom xb transform will be needed for the widget.
The good news, parts of this aparently was done already in WebformTranslationConfigManager for compatibility with config translations form integration.
Feedback was addressed.
How is that casted back to a numeric then? Do we need to use int|string everywhere?
I'm not sure this is the way forward. I'd prefer it to be nullable than allowing a string.
penyaskito → created an issue.
I like ComponentBlockPreRender event.
We might need this for blocks that we don't support yet aside of TitleBlock. E.g. those with lazy render placeholders?
Might be used too in
📌
Handle block contexts
Active
for setting the context values when we support context aware blocks.
Or even a more general ComponentSourcePreRender event, because this might apply to other component sources, not only blocks.
jwilson3 → credited penyaskito → .
Crediting Lauri and Mark for work on product definition and design/UX before I forget 😊
Crediting Lauri and Mark for work on product definition and design/UX before I forget 😊
Crediting Lauri and Mark for work on product definition and design/UX before I forget 😊
That would definitely simplify things. I assumed we wanted the client to be dumb about this.
What I had envision would be something like
POST /xb/api/v0/layout/{entity_type}/{entity}/personalize
with { components: {uuid-component-1, uuid-component-2}, variant: my-variant}
And that would encapsulate the same operations you described.
penyaskito → created an issue.
penyaskito → created an issue.
penyaskito → created an issue.
penyaskito → created an issue.
penyaskito → created an issue.
penyaskito → created an issue.