Fibery seems to have a feature where it will auto-set various fields on new entities, based on the currently-applied filters in a view. Sometimes that feature is nice, but more-often it has been frustrating - so I’m looking for a way to disable it, on certain views.
This is most commonly an issue on our “Inbox” view, which I use to triage all new bugs/stories/production support/etc. I’ve trained everybody to go there to add new entities, and there are workflow states set up that manage that view.
That page has a complex set of filters, both hard-coded and user selectable. There are two primary ways this causes problems:
- Recently I added a built-in filter to show “Production Support” cards (which is a value in the required Type field) on the Inbox, regardless of their State. But now whenever somebody makes a new entity on that page, it always defaults the Type to Production Support - even though it’s critical for the user to make an explicit choice for that field, when they create the Entity. (It is literally the only required field, just so users are forced to make that choice when filing a new entity.)
- Sometimes a user filters the page down to just themselves. I have a filter named “Mine” that looks to see if they are assigned to any of a few different user fields. But then when they create a new entity, they get assigned to all those fields. (This behavior hasn’t been totally consistent - it doesn’t seem to happen all the time, and when I’ve tried to reproduce it it hasn’t been consistent, so I’m not sure if it’s really the same issue.)
So I think ideally I’d just like a way to completely disable that auto-setting of fields, based on the filter, on this specific view. But even if I could just disable that feature system-wide, that would be better overall; I think it generally causes more problems than it’s worth.
Possible solution, but may be annoying to set for each field:
Make a new formula field which equals the field you want to filter by. Then filter by the formula, not the editable field.
This will then filter correctly, but not auto-fill on create.
I think it would break a lot of things, especially when it comes to context view filtering. If you had to specify the project when adding a new task when you are clearly within a specific project in the UI, I think that would get annoying.
I think it may also be a thing of making specific views for specific things, then when they make a new entity in that view, it’s expected that it’s an entity for that specific thing. I can see there may be exceptions to this, but that’s generally how I approach it.
Hm - thank you for the idea. That might be worth it.
And I see what you mean about the feature, overall. I guess I was thinking about too simply. Maybe what I really want is some sort of way to mark specific filters as excluded from this behavior.
Looking around my other views & filters, just now, I realized that sometimes (or often!) I’ve been getting the behavior I want entirely by accident. For example, I have a view where this doesn’t happen (in a desirable way) because my filter was a “not” filter, rather than an “is” filter.
…which gave me a reasonable workaround, for the first issue - I switched the filter to be “not any of the other types” and that fixed the problem when new entities are created. It’s clunky, but it works.
Ooh that’s a smart way around it too!
Are they single selects or a to-relation to a database? There may one more workaround if they are a to-one relation.
If it’s a to-one. You can filter by the name of the type, and not the status entity itself:
Then it also won’t auto-populate.
Some potential future problems:
- If you’re doing “is not” and selecting all the options, if you add an option later you’ll need to go in and configure all the views you did that in.
- If you’re filtering by text name and you change the type name later, you need to change the filter in all the views you configured this.
The Type field is a single-select field. And yeah, if I add another type, this filter will break. But that’s unlikely to happen; this particular Type field is core to many workflows, and has been carefully designed.
1 Like
