Rich Text field from a Formula

[Matt_Blais]

Right now you cannot choose “Rich Text” as the Type of a Formula field

But why not? Underlying Rich Text content is just text (markdown/HTML/JSON).

There are interesting possibilities here, like:

• Automatically-generated, auto-updating, entity-specific (or not) dashboards
• “Read only” Rich Text fields
• Live, “always up to date” documents that display current information from other sources - like a Status Report or Summary
• All of these ideas are already possible (sort of), but unnecessarily awkward:

@Matt_Blais

Otherwise we need awkward workarounds like creating a Rule that overwrites the content with what it “should” be, if it is accidentally modified, or a button to initialize/restore the content, etc.

[Chr1sG]

@Matt_Blais

Automatically-generated, auto-updating, entity-specific (or not) dashboards

What are your examples of what you would include in a ‘dashboard’? I know a lot of people use the word, but I suspect there is quite a bit of variation in what people mean by it.

How do automatically-generated dashboards differ from what is currently possible with either smart folders or relation views?

@Matt_Blais

“Read only” Rich Text fields

When per-entity permissions are available, will appropriately granted access levels solve this? or are you referring to field-level access control?

@Matt_Blais

Live, “always up to date” documents that display current information from other sources - like a Status Report or Summary

Is there something about current documents/rich text fields and their embedded view capabilities that you perceive as not being ‘live’ / ‘current’?
Does ‘other sources’ include data from outside Fibery?

With reference to the topic you linked to, you can create embedded views which are context-filtered. so I am wondering if the missing part is the ability to auto-replicate across all entities of the same type?

If so, then I think that one possible solution is supporting more variety in layout options for entity view (so that the existing relation views can be arranged in a ‘dashboard-like’ layout) rather than actually adding any specific functionality for rich text fields.

[Matt_Blais]

@Chr1sG

@Matt_Blais

“Read only” Rich Text fields

When per-entity permissions are available, will appropriately granted access levels solve this? or are you referring to field-level access control?

This would require field-level control – I’m talking about protecting a single Rich Text field from UI changes. That’s what a Formula/Lookup accomplishes.

@Chr1sG

What are your examples of what you would include in a ‘dashboard’?

My “Project Dashboard” example – a Rich Text that presents a concise summary of data from the Project and related entities, i.e. the current state of affairs for this Project (see example below).

I would want to be able to embed Fibery Reports and other views into such a Dashboard (already possible), as well as calculated info like estimated completion date, tasks outstanding, etc.:

 Client:             YoyoDyne Propulsion SYstems, Inc.
 Client Contact:     jbigboote@yoyodyne.com  
 Project Manager:    Floopy Jupers
 Target:             22-Jan-2024
 Completion:         55%
 Prognosis:          Good

This Dashboard should exist in all Project entities (showing their own info, obviously). I don’t want to manually create it in each Project, and ideally the data is “always live”. It should also be resistant to accidental overwriting by a user.

Right now the only way I see to do this is to create a Rule that overwrites/recreates the Rich Text content from a template when component fields are updated, and/or hourly – better than nothing, but not ideal.

But I’m not even sure it’s possible right now for a Rule that defines some markdown to create all the varieties of embeds, context-aware embedded views, etc. for a Rich Text… maybe need a script that creates JSON??

@Chr1sG

Is there something about current documents/rich text fields and their embedded view capabilities that you perceive as not being ‘live’ / ‘current’?

That depends on how the data is getting into the Dashboard – is it generated just once, or generated repeatedly, or does it consist of references which are fundamentally “always live”?

Partly this request reflects my desire for more control over formatting and presentation of information. Embedding a Fibery view in a Rich Text results in a very specific data presentation/format; and when viewing the result it’s not necessarily easy to just select it like ordinary text and copy and paste it somewhere else (e.g. into an email).

There are advantages to having a lot of flexibility over how info is displayed/formatted.

@Chr1sG

I am wondering if the missing part is the ability to auto-replicate across all entities of the same type?

That is part of it, yes.

@Chr1sG

If so, then I think that one possible solution is supporting more variety in layout options for entity view (so that the existing relation views can be arranged in a ‘dashboard-like’ layout) rather than actually adding any specific functionality for rich text fields.

That would definitely be welcome, but it would not address the need for greater control over formatting and arranging arbitrary data into a single Rich Text area that could be selected/copied/pasted.

[Chr1sG]

@Matt_Blais

My “Project Dashboard” example – a Rich Text that presents a concise summary of data from the Project and related entities, i.e. the current state of affairs for this Project (see example below).

The example that you gave of a dashboard, looks a lot like a set of existing entity fields/data arranged in rows, one above the other, which is why I wondered if greater options for entity layout would provide what you need.

In general, the contents of fields should vary from entity-to-entity, whereas the view settings (for entity view and for any relation views it contains) are the same for all entities of a given type.
So I basically agree that the issue to me is about

@Matt_Blais

control over formatting and presentation of information

Just because a rich text field allows lots of options for layout choices, it is fundamentally a ‘field’, implying that its contents (including the layout within the field) will vary from entity to entity.
It seems like we’re discussing leveraging the layout options of rich text fields to get per-type dashboard layouts, which is paradoxical.