The problem is I cannot properly filter Merge Requests associated via the Gitlab User, even when scrolling in the list of relations there is only links through Tâches
For your case, you need a lookup in the Merge Request database to get the Users (you currently have it the other way around).
Then it should show up as a context filter option.
But I see no change in the UI for filtering a report (I’ve even tried to create a new report from the user), so I still cannot create the report I need. I’m wondering if there is a limit in the displayed relations when creating the report (there seems to be dozens of ways to link a user to a task in my organisation). Maybe this is an issue with sorting / paginating these links ?
For instance, those suggestions going through 4 or more tables is not very relevant
Another side effect of inverting the relation (MR to user instead of user to MR) is that I no longer see the MRs on the user page.
This is not enough to create a board in the Gitlab Member page, showing MRs filtered by Gitlab Member.
If I add a lookup from User to MR (through Gitlab Member), I can see the MRs on the User page, but still cannot filter the board (as you explained above) Note I would prefer here to see those as a board or list, not only as fields.
Are you trying to set up a board view on the entity view of the Gitlab Member?
I thought you were trying to setup a board view within a smart folder of Fibery Users…
Another question: given that a Gitlab Member can be ‘related’ to a Merge Request in 4 different ways, which of these relations is to be used for filtering Merge Requests?
Sorry for the mixup, I’ve tried both, since any would meet my needs. I expected both board views to behave the same but they seem to be slightly different.
That’s a good point ! For the moment I’m fine with creating several board views for the different relationships.
In the future I will try to setup a relation for people “involved” in a MR through any of the 4 relationships, I think I saw a hint in the forums about that. Let’s keep this out of the scope for now I’ll create another thread about that if needed.
In summary, I can find workarounds around this, but I was puzzled by a few behaviours:
the fact I cannot change the view on the User entity, for a relation defined on the User, from fields to board
the fact that to create a board view in a smart folder, I need to define the relation the other way around (from MR to User)
the huge amount of suggested filters (I guess this is OK in general, I just have a big structure at the moment. A quick improvement could be to sort the suggested filters by the amount of tables to go through, rather than by table).
If I understood correctly, 1 and 2 imply that I need to define the lookups on both ends if I want to have a board view on both the User entity and a User smart folder.
Side note : I was especially puzzled by 1. and 2. since I took some time to read the documentation about lookups and board views and found no hint about these restrictions (I might have missed the relevant lines)
Perhaps I can explain how Fibery works with respect to these (interconnected) issues, and then hopefully it’ll help clarify things a little.
Lookups
Lookups are read-only fields that will show a collection of entities. They actually are very similar to formulas under-the-hood.
At the moment, they are only able to be shown as lists on entity view, so the features that are available for standard relation views (sorting, colour-coding etc.) are not available. This might be improved soon
They are ‘one-way’ only. That is to say, if you have the databases A → B ← C (where → means one-to-many) creating a lookup in A to get all the Cs from its Bs does not affect C in any way.
As you discovered, if you want to see As in entity view for C, you need to create a ‘mirror-image’ lookup.
Smart folders and context views
If you create a smart folder based on database A, you can add any views you like, and they will be context-filtered by default. So you can easily show the Bs that are linked to any given A.
Without any lookups, the ‘routes’ that are available for context filters are limited to those which traverse many-to-many or many-to-one relations.
In the above example (A → B ← C) it is not possible to show the Cs that are (indirectly) linked to A because there is no route from C to A except via a one-to-many relation.
If the relationships were A → B ↔ C, then it would be possible.
If you add a lookup in C (getting the As from its Bs) you now have a direct path from C to A, and this can be used for your context filter.
Relation (context) views
Relation views in entity view are really powerful, and by default, also use a context filtering, following similar rules. However, most of the time, a relation view will show the entities via a direct relation (but it is actually possible to configure them to show entities from any databases where a direct or indirect relationship exists).
I hope this is useful info.
With respect to this:
it’s a rather inevitable side-effect of having a complex schema that there can be many direct and indirect routes between any two databases, but you’re right that it might be an improvement to order them by the number of ‘stepping stones’ in the route rather than grouped by database.
I’ll pass this on to the dev team.
I’ll create another thread about that if needed.
