[IN DEV] Entity-level permissions

[Matt_Blais]

@Chr1sG

adding a (strictly controlled) linked database is as easy as adding a new field (and where it is possible/easy to edit the linked entity’s properties without having to navigate to it

If that’s like a JOIN, that would be FABULOUS
– i.e., if we could treat/use a linked entity’s fields as we can the main entity –
and it would answer a big part of the need for some kind of polymorphism, and allow for much better DB normalization.

"Joins" - include related entity's fields in Views

Yes, this is related to Inheritance-like functionality: Example: If I have a Project Type that is related (1:1) to a SEO Info Type, my desire is for a Projects Table View that can display and edit the fields of the related SEO Info entity (if it exists). The issues with using Lookups for this are: Each Lookup field must be manually created (cumbersome, and error-prone if field definitions change) Lookups do not allow editing the related values in the Table View

Allow Automations to Update entities via Lookup fields

I am frustrated by the inability of Rules to Update entities related through a Lookup It means more Javascript, which seems unnecessary.

Allow Rules to trigger "When linked entity is Updated"

@Chr1sG, yes there are existing workarounds. The case for this is really about reducing complexity, i.e. not having to create additional lookups, and avoiding having to remember that a particular field is actually modified from a related entity (which is not how I like to build things). It’s a maintenance headache. I have actually found myself forgetting why I created a particular lookup or relation, and deleting it, only to (re)discover later that it was added it to perform some kind of work-…

How to best model Hierarchical Types?

The goal is to make the schema/DB structure as clean as possible; i.e., no duplication of fields, and no extraneous fields. (see Database Normalization) So e.g.: all of the different project types need “tasks”, so “tasks” should belong to a generic “parent” Project type. only “website projects” need a URL (brochure projects do not), so the URL field belongs in the “website project” type, not in the generic Project type.