I guess I expressed myself badly.
Here’s an example of what i mean: say the Project type has a single select field, with the options ‘Not started’, ‘In progress’ and ‘Completed’, and is associated with tasks that themselves have a boolean field that is ‘Done’, it might be desirable to only allow the user to choose ‘Completed’ if all related tasks have ‘Done’ = true. Otherwise, that option is greyed out.
Or another (random) example: you have a family tree app, with the type ‘Person’ and they can be related to an other Person via a relationship ‘Marriage’. You could limit the possibilities based on characteristics of the Person, e.g. only allow Person to be linked to an other Person (via Marriage) if both Persons have age > 16 (or whatever is culturally appropriate!)
By talking about single select, mutli select and relations, I was just emphasising that they are all in fact types under the hood.
It wasn’t really about transformation or anything more complicated, and yet it is not the same as field visibility being conditional.
I guess I expressed myself badly.
Interesting, yeah. So thinking about this more holistically, what I think I’m seeing is a system that:
- Can be applied to both fields and groups
- Can control either visibility or “locking” (user can see but not change data)
- Uses formulas to determine these states based on values of 1 or more other fields
If you want 1 field to be influenced by another field, you probably edit the field to be influenced. Multiple fields could be referenced in the “visible or locked if” formula, e.g. “if both Field X and Field Y are empty, hide Field Z”. The same could be applied to groups, i.e. edit the group, and apply a formula in “visible or locked if”. Perhaps the formulae could be made more sophisticated if there are other properties one might want to control?
Anyway, does that make match your concept?
To be honest, the thing I would probably like to see the most is an iteration of the current auto-relations whereby instead of having matching rules being used to determine which relationships will exist, the rules (or even better, a formula) are used to define which relationships could be chosen from by the user.
Good Commentary guys and @Oshyan! I wanted to respond on this last point - Chris, you helped me earlier understand the auto-relations and your Test Case usage of them is very nice. But in my day-to-day I haven’t found any use yet, although I continue to try. While I use extensively all other Fields, including lookups in both directions, as part of what makes Fibery so helpful to my needs.
Would love to see continued development as a priority of variations of all this, and hopefully integrating Formula Filters and Automations, and perhaps Conditional Formatting (“When Entity is “closed,” change color to “green” etc.) soon.
Any updates on dependent dropdown lists? We wanted to implement statuses and sub statuses.
It is already possible to have ‘suggestions’ in the dropdown that are based on the value of another field (if the two fields are relations):
Is that useful?
But there isn’t yet the ability to restrict the dropdown options and prevent a user from ignoring the suggestions.
I think this is not quite enough as these are not intuitive to set up, I am frequently surprised to see them popping up when I have set up my relations a certain way. It seems @Eugene_Vabishchevich would like to see this feature too, and I’m guessing @Oshyan given his expansion of my original request into an even more well-written one. Not to beat a dead horse that I’ve commented on already a few times tonight, but none of us are able to vote for this request (unless Eugene still has a vote), but we all presumably have a need. I have a big need and have had it since I wrote this request 1 1/2 years ago.
Are you talking about types or fields? I don’t want to create additional types for dependent dropdown lists. For instance, if I have a dropdown field I want to add the second dropdown but display its values dynamically based on the State.
So yes, I was talking about fields that are links to types, rather than single-select dropdowns, sorry.
Yes I second this around this request. It would be great to be able to simply create drop downs that can dynamically relate to results in other drop downs. Very important for categorizing data in Fibery. In fact, with this functionality I could vastly reduce both the amount of Types/Db’s in Fibery - simplifying my instance. I could also remove some very LONG single-selects I’ve had to concoct to allow me to categorize Entities, when if I could use dependent drop downs, which basically provide a sort of “sub folder” functionality, I’d have a much more elegantly organized set of data in Fibery.
I would really like such a feature, especially the conditional relationship evoked by @Chr1sG
We are currently trying to leverage Fibery as a framework for Holacracy. I think it can work (which is already incredible) but we are sometimes pushing the limits
We have plenty of use cases where conditional relationship would be useful: a User takes on a task as one of its role in Holacracy so would like to restrict the Role relationship to only the Roles of this user. When dealing with a Circle, only suggest the Roles available in this Circle.
The auto-suggest feature does help a lot but it is too limited somehow.
We are working on relationship filters but in the meantime, I’m curious about this:
In what way is the auto-suggest feature limited for you as it stands?
Well relations are sometimes indirect and not easy to infer by the auto-suggest engine.
For instance, a Task as one Owner (a user), a Owner as many Roles. I would like, once a Task as a Owner, that the suggested Roles are the one filled by the Owner. Unfortunately, it does not happen
Thanks for the extra info.
Indeed the current auto-suggest relies on the relations following a specific structure, and it’s a pattern your use case doesn’t fit.
I hope there will be some good news for you soon
This is quite a long topic with many replies, but I’d be interested to know if the relation filters that were released recently can solve some/most/all of the use case?
I was looking for something you could do with single and multiple-select fields, so with relations not really what I was hoping for. Do you think the very first example at the top of this thread could be handled by the filters? Maybe I don’t understand this well, so if that’s possible, please enlighten me, thank you!
For the example in the first post of the topic, you would need the categories (Meat, Vegetable and Fruit) and the examples (Beef, Pork, Spinach, etc.) to be in databases
(and it assumes that you would be choosing a single example, based on the value of the category)
The case for relation filters being supported for single-selects is in the backlog.
Ok thanks for getting back to me. Yes so that’s what I thought. It’s a point frequently made by @Oshyan that I subscribe to pretty strongly as I move along in Fibery and months/years pass, and that is to avoid creating a db unless it’s absolutely necessary. In fact my team has many potentially db-level groupings that are instead categorized by using single or multi-selects within one DB so we can avoid setting up too many db’s. Proliferating db’s leads to all kinds of issues that could be solved with polymorphic, which is one feature I really hope gets out of the backlog at some point!
So in this case I would definitely not want to create a db just for those few ways of categorizing the entities.
This is something I have been coming across repeatedly as well. I fully agree with this sentiment:
I think given that single/multi select fields appear to be databases under the hood, it does seem logical that the filter could be extended to them as well. This way the users can extend the database without having to manage it as a full-blown database.
This might be mostly psychological but I can imagine it becoming very difficult to manage multiple “Status” databases when all you are trying to do is to allow the “Status” drop-down field to be dependent on another field.
Is there any possibility that we will see the filter functionality (as described above) will become a feature in the near future? This would really help keeping the clutter to a minimum.
I know using a separate database has been suggested as a solution. However, I do find that new users are totally confused by the ability to click through the field and get to a “status” entity page. I think having single/multi-select fields be just drop-downs makes them very useful. The fact that you have to make an effort to open them as entities means that users are not confused by the seeing the “>”.