- Issue created by @joelpittet
- 🇨🇦Canada joelpittet Vancouver
I'm simplifying the scope as it seems the relationship and field are actually working (my migration needs a bit of help for the roles apparently).
- 🇨🇦Canada joelpittet Vancouver
D7:
→D10 (Work in Progress):
→In D7, access was determined based on the role labels, which allowed targeting roles across bundles more easily.
In D10, I’ve shifted to using role IDs, but the tradeoff is that I can’t easily target roles across bundles unless I explicitly include each one.Would it make sense to introduce a role name (label-based) lookup helper so that the behavior mirrors D7?
One concern with continuing to rely on role machine names is the potential for duplication—especially if roles are auto-generated per-node,
resulting in names likeENTITY_TYPE-ENTITY_BUNDLE-member
andENTITY_TYPE-ENTITY_BUNDLE-member-1
.Any suggestions or direction would be appreciated.
- 🇮🇱Israel amitaibu Israel
Just to make sure I understand. I don't remember how it works on D7, but based on what you wrote, you want each role label to appear only once (Admin, Member, Non-admin).
And it should work regardless of the group type, because you want it to filter by the role label?Can you give your use case, that might help finding the right solution
- 🇨🇦Canada joelpittet Vancouver
We have various views with exposed role filters—like filtering for who’s the chair of a committee, or who’s an administrator of a group. In some cases, we also want to filter by any role except "Hidden" or "Portfolio” (that’s a real example). From a user’s perspective, they don’t care which group type (bundle) a role is attached to—they just want to filter by the Role (label).
I’d prefer not to prefix the role labels with the bundle to distinguish them to the site builder configuring this, and since that would mean using grouped exposed filters and manually relabeling everything for clarity, which adds unnecessary complexity. So I guess I am leaning towards the helper to lookup roles by label and just showing (unique) labels like D7 had.
Feel free to disagree if that doesn't make sense still
- 🇮🇱Israel amitaibu Israel
Just throwing an idea: `OgRole` is a fieldable entity. So you could have a `field_simple_label` that would hold the name of the role as you expect to.
Then Views core Contextual filters could be setup to filter by that field.
Does that make sense for your use case?
- 🇨🇦Canada joelpittet Vancouver
That’s a novel idea—definitely good to think of alternate approaches. That said, I’d prefer not to add custom fields just to filter roles by label. It feels a bit off to decouple the display label from the core role entity, and it adds extra overhead that’s easy to miss or forget about later. At that point, using a grouped exposed filter in Views might be simpler, even if it requires some relabeling.
What I was originally thinking was something like adding a method to OgRoleManagerInterface, maybe getRolesByLabel(), to return a unique list of roles keyed by label regardless of bundle. But maybe there’s some resistance to that since it could introduce ambiguity or complicate the API? Curious what your take is?
The current MR shows what's in the screenshot in comment #3 BTW