CHANGELOG: February 25 / Hierarchical Lists (beta), some improvements

I’m sorry if ‘I’m teaching grandma to suck eggs’ but did you know that you can add as many fields as you like to single-select/multi-select fields? (they are basically just types, but without the same visibility at the app level).
So you can actually have Text/Rich Text fields associated with a single-/multi-select, and people can view all the details with Alt-click like normal entities.
You can even choose to have simple Text fields visible when you’re using the single-/multi-select as a column heading (but not Rich Text fields :frowning: ).

1 Like

FWIW, yeah, it would be nice if the Fibery fields weren’t set in stone, so you could change them (single-select to standard type, one-to-many to many-to-many, number to text etc.) but I’m sure the Fibery guys have this in the backlog :slight_smile:

1 Like

Can we have the option to show buttons in the hierarchical list entries, please :pray:

2 Likes

This already works in Hierarchical List, check this gif

2021-02-27 11.39.25

Indeed

Indeed this is not supported and lists work only with true types. The reason is quite technical, Project Type does not have relations to Issue Type single select and system has no chance to display it. What you want is a mix of Hierarchy and Groups, but that is hard to implement in our paradigm. I’m not sure how to solve this problem so far.

1 Like

It will be done.

2 Likes

[UPDATE: Thanks to @cannibalflea for pointing me to what I was missing - didn’t realise that I had to enable recursion by selecting the ‘recursion’ symbol when configuring the list. It’s not a bug, it’s an undocumented feature :wink: ]

OK, then I must be experiencing a bug.

The hierarchical list is not showing the items as sub-entities… :frowning:

I don’t think @rothnic was meaning that Issue Type was a single select.
He does in fact say,

so I think his request is that hierarchical lists support many-to-many relations (as well as one-to-many).

It was just me that introduced single-selects into the discussion, confusing things, sorry…

Did you click the icon that enabled this mode? 2021-02-27 15.43.53

Yes, thanks.
I updated my post after @cannibalflea gave me the clue…

My request is to support many to many relationships. In this example I’m only referencing types imported via the JIRA integration. There are no single selects utilized for the JIRA integration iirc. I used the auto-linking to make sure there is an association between the Issue Type and Projects.

If there is a work-around of some kind, I’d be interested… I just can’t find one.

That is correct, but the suggestion was helpful. I haven’t looked too closely at single selects mainly because I’ve stayed away from them in other tools, where they can be more limiting. If there was a way to assign a single select, similar to the auto-linking of types, then it would be an option for me.

The real reasoning on why I used a proper Type for “Issue Type” example is just because that is how it comes in via the JIRA integration.

Hey guys! My team has been moving along with the Hierarchical List View, and one big piece of feedback I have right now is I’d really like to be able to have the Cards/Boards functionality when displaying the entities of being able to determine size of the Entities. In other words, the options of:

Compact
Line
Default
Full

Or something equivalent.

In particularly we are really missing descriptions of fields that are part of “full” cards in board view. I am trying to emulate one of the best views of Target Process when the Parent Entity rolls up values from the children, such as total effort, etc, and this can be toggled open or closed.

I can do this set-up in Fibery with Hierarchical Lists, but we can’t see what those values are without the labels that you get in Full Cards in Boards. We have many formulas at times, so without these labels, you can’t have easy readability as to what number represents what value.

Thanks!

2 Likes

This is kinda what I had in mind when I wrote

1 Like

Great that we are on the same page here. I just hope the team is counting this as two votes for the feature! No way to know for sure, since - and I hesitate to bring it up - but we can’t just “vote” for each others’ suggestions. But perhaps the team will actually respond and confirm!

Thanks for the tip, I did not know !

But to be honest I don’t see why we need the 2 similart but different concepts.
Those implicit type created by select/multi-select are crippled types:

  • not displayed when editing the types (need to click on 1 value, then 3 dots button then “edit type”)
  • values not searchable in the global search
  • cannot be reused in other Types: seems that in theory you can add other relationships as new fields, but when I tried I always had the error “Cannot create field. Invalid schema”

@mdubakov Why do we need those 2nd class citizens types? As @rothnic I tend to create groups of tags or partition as real Type, so they are visible and can have description fields (as @Chr1sG said you can do that on single-select/multi-select types, but not possible to add in a table view as you can do with a Lookup on a linked normal Entity).

The specific display properties of single-select/multi-select types could be merge in the regular types:

  • icon field: should be merge with Avatar extension, and when selecting Avatar we could chose between icon or upload a file
  • background color: we could also add the possibility for normal type to override the Type color at the entity level to mimic the same behavior.
1 Like

Under the hood Select/Multi-select are usual Fibery Types. We added these things since many people expect to have them and Types is a hard concept to grasp. Also you often just need a selector without additional clutter (when you add it as a real Type you see it everywhere, in the schema, in views setup etc.).

I do agree that icons and backgrounds should be unified though, but it is harder to do for usual Types since it is somewhat weird when you set a background for a single entity. How explain it to people?

3 Likes

This is interesting! Would there be a possibility in the future for users to convert a simple select/multi select to a fully qualified entity? I know there is ongoing work on field type conversion so hoping this is also possible. This will allow users to start simple but expand things in the future.

1 Like

Looks like that we can only have an hierarchy list on the same type if it’s on the first level. Is there a way to make it happen on the other levels too?

Thanks!

Not currently.

1 Like

Very good explanation, thanks! :smiley: