Limit parent selection to those created by owner

Created on 18 September 2024, 7 months ago
Updated 20 September 2024, 7 months ago

Problem/Motivation

As long as there is no filter, children can be created with other user's parent content.
This leads to complaints and eventually necessitates further ownership control efforts.

Steps to reproduce

You can create a solution with the "Views: Filter by an entity reference view" option instead of the "Entity Hierarchy" reference type. You can solve the problem with the view reference for the content type where you use the ERH field type. This way, only the current user's contents are filtered.
However, other problems may arise here. That is; children tabs appear on other content types where you do not use ERH field type.

Unfortunately, "Limit Entity Reference Owner" module, which offers another solution for the Owner filter, does not work with the Entity Reference Hierarchy module.

In the end, neither approach worked. How can we find a solution within ERH module itself?
Thanks

Proposed resolution

There should be a parent content filter that allows member to select only their own content.
Screenshot & Inspired by " Limit Entity Reference Owner β†’ " module.

πŸ’¬ Support request
Status

Closed: won't fix

Version

5.0

Component

Code (module)

Created by

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @pearls
  • Status changed to Closed: won't fix 7 months ago
  • πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10

    This doesn't meet the 80% use case.

    If you need this functionality, I would suggest creating your own selection plugin and modifying the query behaviour to match. Happy to provide advice on how to achieve that.

    Thanks for taking the time to file an issue.

  • Wouldn't it be better to leave the issue status active? Maybe a different perspective can provide a solution.
    Thanks anyway.

  • πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10

    Hi, the status reflects the likelihood of this feature being accepted into the module. I think it is better to set a realistic expectation rather than waste someone's time working on something that will never go in.

    The offer to help code a custom module for this stands though

Production build 0.71.5 2024