New entities are not automatically linked using their creation context if they are related via an auto-link Rule

Bugs & Issues
, , ,
1

Consider two DBs, Parent and Child:

  • Parent DB has a [Children] collection of Child entities
  • A Child has only one Parent, and it has a [Parent Id] field for specifying its Parent
  • The relation uses an auto-link Rule: Child [Parent Id] = Parent [Public Id]

In order to link a Child entity to a Parent, the Child’s [Parent Id] field must be set to the Parent’s [Public Id].

In the simpler case where there is no auto-linking Rule (i.e. just a regular one-to-many relation), if we create a new Child entity within a Parent’s entity view, via its [Children] collection “New” button
image
, then Fibery will magically link the new Child to this particular Parent. Automatic context! :grinning:

However, in this case where an auto-linking Rule is used to connect Children to Parents, this automatic linking does not happen; if they should be linked (which in this context is obvious) then the user must manually set the new Child’s [Parent Id] field in order to make the link (if the user has manually created the new Child entity).

Meanwhile the newly created Child entity shows up in the Parent’s [Children] collection as if it was linked, though it is not. When the view if refreshed it will be gone! :astonished:

In this simple case (i.e. the Child entity is created in the Parent’s entity view, in its [Children] collection) the creation context makes it obvious that this linking really should be done, and Fibery COULD certainly do this for us, which would be GREAT :grinning:

I do understand that an auto-linking Rule could be much less obvious, and more difficult for Fibery to automatically link. But this seems likely the most common and easiest case (maybe 90%+ of all auto-link Rules?) that just use Public Id.

Another possibility: Using a Form. Forms are not currently smart enough for this either :confused:, but if Forms were enhanced to allow the new entity’s field values to be set from Formulas, then the Form could set the new Child’s [Parent Id] to be the Parent’s [Public Id] using a Formula.

TL;DR Using an auto-linked relation means losing Fibery’s very cool capability to use entity creation context to automatically link a new entity to its context, and this is sad :confused:. But hopefully this situation will be improved.

2

Auto relations are read-only, and the linked items will depend on the linking rule(s).
If you have a view that uses the auto-relation as the context, then in order for Fibery to force the items to be linked, it would need to be able to ‘reverse engineer’ the rules to work out what thing(s) it needs to change in order to link the items.
In some cases, the rules can themselves utilise read-only fields (creation date, created by, public ID, formula fields etc.) which Fibery cannot modify. I think this could end up being a technical pandora’s box.

Indeed, when you create an entity in a view with a filter, Fibery will attempt to apply the filter to the newly-created entity (and fail in the case of a read-only situation) and the entity will disappear when the view is refreshed.
This is the same behaviour for all views, pretty much (and is similar to sorting, where the position might change on refresh).
Given that solving the issue of auto-setting (read-only) auto-relations is not likely to be solved any time soon, I’m not sure what alternative behaviour might be preferred. It could be designed so that it is not possible to create new entities in a view where the filter settings cannot be applied to them, but this would seem to be a worse option IMHO.

3

Out of curiosity, why do you use this:

as the way to link children to a parent?

What sets/defines the Parent Id field, and why can’t whatever-it-is do the job of directly linking the parent?

4

I will probably just remove the auto-link rule here, and make it a regular relation, but the idea for using the rule was just to make it hard for users to accidentally add or remove Child entities.

I don’t have an automation that sets up the [Parent Id] to link the Child. This is not part of a production system yet - still experimenting.

5

In which situations should it be hard for users to add Child entities (given that the initial post talked about wanting to create a Child entity and link it to its parent)?

6

Not wanting to make it hard to create and add Child entities to a Parent – just hard to accidentally change their existing linking, so it’s not done accidentally.

Ie, it is easy to accidentally change the “One” end of a normal Relation field just by assigning it to some other entity, if you aren’t crystal clear that it can only be assigned to one at a time.

7

You mean that a user can unwittingly ‘steal’ a Child from it’s existing Parent by linking to a new Parent?
If so, it sounds like you would benefit if there were relation filters on collection field, so that you could exclude Children who have a Parent from being chosen, when trying to create/link…

Did I understand it right?

8

Yes, exactly.

Because we have no field-level permissions, it is very possible for a user who needs some edit access to an entity to have too much access, allowing them to change everything that should not be changed.

Eg: one Project => many Tasks

When viewing a Task entity that is already linked to a Project, a naive user could click the Project field expecting to open the linked Project (because they don’t yet know to click the little “>”), but instead they are presented with a drop-down menu of Projects… which is deadly, because if they click one, they will link this Task to an entirely different Project (on a bad day) :dizzy_face:

There is no good way to distinguish fields that are adjusted in daily use, from fields are meant to be more stable/permanent (like the Project–Task relation).

Auto-link Rules have the advantage of making it more difficult to change such relations by mistake, which affords a higher level of idiot-proofing – but at the cost that it becomes impossible/cumbersome to create new entities contextually, since the relation’s auto-link rule prevents the regular automatic context linking from happening, so it has to be done manually, which is a PITA…

Which is the point of this thread. :point_up_2: