In board view use Description field toggle to show if entity has a description (like Trello)

As someone that’s trying to migrate our Trello use cases to Fibery boards I would like to be able to view if an entity has a description or not, similar to how Trello does it with their cards.

YlRnEdBnpm

I imagine this could be enabled using the Fields dropdown where if Description is toggled a similar icon is shown on cards where there Description field is not empty.

NOW FIXED see post #7

How about this for a fugly workaround :slight_smile:

[DELETED]

Of course, out of curiosity, I have to ask what you are using to trigger the automation, because it’s not yet possible to trigger on rich-text changes?

I have to give you props, because while that is truly hideous - it could work.

Ok, well that’s an even larger problem. LOL

I’m guessing this somewhere on the roadmap? Because I don’t see an existing feature request for “trigger on rich-text changes” . This is the closest similar thread:

EDIT: A workaround for this workaround may be to use On Schedule trigger?

1 Like

At this point I’m three workarounds deep into getting this to work so I might just give up but I guess I could use this type of Scheduled trigger below for the automation.

The downside is that the “Has Description” flag will be only set one way, that is to say it will only show that a description was added at some point and not update if the description is removed.

Quick update:
It seems like the API does support clearing the value of a single-select using null, but problem lies with the .updateEntity function.

The devs are working out what the fix is, but in the meantime, you could use the following (slightly less fugly) workaround:

[DELETED]

Fixed now, see below.

Hello.
I’ve fixed the issue with script failure on setting null to single-select field via fibery.updateEntity api. It should work ok now.
Sorry for inconvenience.

2 Likes

Here is the updated code and instructions for this automation + script based workaround to show if a entity / card has a Description:

Setup

  1. Add a single select field named: Has Description
  2. To this field add a single option with the value: ...
  3. Set the icon of this field to one of the :memo:“write” or :page_with_curl:“paper” emojis
  4. Create an automation rule When > On Schedule, every one hour Then run script:
const fibery = context.getService('fibery');
for (const entity of args.currentEntities) {
    const description = await fibery.getDocumentContent(entity.Description.Secret);
    const hasDescription = entity['Has Description'].Name
    if (description && !hasDescription) {
        // set Has Description field if not already set 
        await fibery.updateEntity(entity.type, entity.id, {
            'Has Description': "...",
        });
    } else if (!description && hasDescription) {
        // clear Has Description field if no description
        await fibery.updateEntity(entity.type, entity.id, {
            'Has Description': null,
        });
    }
}

How it works

Note: When it becomes possible to trigger on rich-text changes, you might be able to do the entire workaround automation without using the script.

Edit: If you want an icon to show for fields other than Description, the process is much simpler and can be done without using scripts. See this example here:

1 Like

Hi Dimitri, thank you for this!

I’m not technical enough to understand scripts but how is yours different from the one in here: Allow Rules/Formula Involving Rich-Text Fields - #14 by rothnic

That one uses a checkbox field “Detecting Description” and the script goes like this:

// Developer reference is at api.fibery.io/#action-buttons

// Fibery API is used to retrieve and update entities

const fibery = context.getService('fibery');

// affected entities are stored in args.currentEntities;

// to support batch actions they always come in an array

for (const entity of args.currentEntities) {

    // the rich text field is a document, which requires a special id to get access to

    // In this case, the rich text field is "Description", so we request that field be included

    const entityWithExtraFields = await fibery.getEntityById(entity.type, entity.id, ['Description']);

    // as long as we have the rich text field looking valid, let's do something with it

    if (entityWithExtraFields['Description']) {

        // just saving a shorter reference to it

        const dsc = entityWithExtraFields['Description'];

        // get the rich text field contents as markdown (supports md, html, and json)

        const doc = await fibery.getDocumentContent(dsc.secret, 'md');

        // now we can search the rich text for whatever we are looking for

        // In this case, lets just see if the doc is non-null and non-empty, 

        // then update a checkbox

        const docExists = ((doc !== null) && (doc !== ''));

        await fibery.updateEntity(entity.type, entity.id, {

            'Detecting Description': docExists

        });

    }

}

I think the other topic is more generic, but yes, @rothnic’s script example is basically achieving a similar thing.
However, I think his script is updating a checkbox, whereas @Dimitri_S’s is updating a single select.
The way that these fields are represented on a card is somewhat different.

One other technical difference is that @Dimitri_S’s script is looking for the existence of the description field, but won’t detect if the description is empty.

const description = await fibery.getDocumentContent(entity.Description.Secret);

This is getting the secret, which is like an id for the document, but it doesn’t check the contents of the document.

const docExists = ((doc !== null) && (doc !== ''));

This statement performs both checks for the document to exist, but also will detect if the document is empty. You could also perform other checks here in addition to (doc !== '').

1 Like

Just to clarify, if you don’t type anything in the description field, both scripts effectively work the same, but if you were to type something and then delete it (so that the description field is blank) the scripts will behave differently, since the doc now exists, but is empty.

Is that correct @rothnic @Dimitri_S ?

Correct. Yeah, I initially missed that, then after testing I adjusted the script to account for that. It might be an edge case but wanted to clarify since the scripts seemed somewhat different in how they were getting to a similar outcome.

1 Like