- π¬π§United Kingdom jrsouth
Rerolled to apply against RC15, however that version seems to introduce a related control (
removed_reference
) which renders this patch partly redundant.Needs unpicking, but this should keep anyone currently using this patch running for the time being.
- πΊπΈUnited States dcam
I suggest closing this issue as a "won't fix." This is a permission issue, not a reason to add more bloat to the field widget's settings. As noted in #20, Drupal Core includes granular permissions which may be configured to only allow access to edit or delete a user's own Media entities. In my opinion, this would need an explanation of how the permissions are insufficient enough to justify additional burden on maintainers and frankly every site builder who has to set up the widget.
- π¬π§United Kingdom jrsouth
I disagree, this suggested change directly addresses a common requirement of sites with large (and changing) user bases.
No matter how good the training is, users make mistakes. This is exacerbated by a changing population of users, e.g. as staff leave and arrive at an organisation. As site builders/admins, if we can easily prevent a mistake from being made, we should, and this change enables us to do so.
The classic example is a user creating a page containing a media item customised to that page. They then later create a separate new page and re-use the media item, editing it inline to be more suitable for this new page, without realising that it's now unsuitable for the original page.
You could argue that this is simply user error, but the suggested change allows site maintainers to easily prevent this common mistake from being made, which directly improves the user experience.
And yes, the permissions around editing/deleting a user's own media items are insufficient, as demonstrated by the example above β the unintended consequences are due to editing the user's own media entity. (And we certainly don't want to prevent editing wholesale, because that's still needed.)
There would be no burden on site builders, since it defaults to the current behaviour, making it purely opt-in.
The burden on maintainers is very likely to be minimal given the essentially static nature of this patch for the last 5+ years.
- πΊπΈUnited States dww
Yeah, I can see the benefit of allowing users to be able to edit their own entities (via other UI paths) but *not* to do so via IEF. I'm +1 to having these be widget settings. But for this to not be a maintenance burden, this feature *definitely* needs solid test coverage before it can be considered. Also, it should target the forthcoming 3.1.x series, since 3.0.0 is deep into RCs and IMHO it's too late to be adding new features there...
- π΅π±Poland adr_p
Rerolled against rc19 and:
- Replaced
empty($entity_id)
calls (that don't work for entities with machine names) with$entity->isNew()
. - On the widget configuration form, dynamically hide "Keep or delete unreferenced..." if the "Allow users to delete existing..." checkbox is unchecked.
- Don't display the "Keep or delete..." setting in the widget configuration summary if configured not to allow deleting existing entities.
- Replaced