cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

One-way reference relationship

One-way reference relationship

Relationship fields are resource intensive and hard to update through scripting. Partly due to the risk of a "cyclical" trigger error. IBPL fields reference an item in a relatively unobtrusive way, and display in a convenient text link format when not being edited. But IBPL fields can only back one type, and have many other restrictions to how they can be used. If we could have a new field type with the better attributes of both a relationship and an IBPL, it would open up many possibilities. This would be a one-way reference to another item.

For example, you could place such a reference on all content items so that they reference their own document. Content doesn't currently have a direct reference to its document, since the contains relationship is used for content sections. With a reference field you could set up FVA fields to values that are on the document. To do this with IBPLs you would need a separate field for each document type. And trying to maintain a single relationship on all content items has the potential for errors.

I would imagine this field could be edited like a relationship, but would appear similar to an IBPL. Or maybe there could be an option of having relationship-like editing or drop-down editing.

1 Comment
Aquamarine

I like the idea, as it addresses some flaws the we've missed for years.

At least in the document <> content area there is a possible workaround.

The computed Field Document ID gives you the ID of the containing document and this ID can also be used in other computed expressions, eg,

a field shortext "Contained by Document Title" =

(RelExists("Contained By") and  IsContent() and IsLive() )? isEmpty(getFieldValue(DocumentID(), Summary),Text("-unknown-")) : emptytext()

 

But this has it's limits, like all computed fields