Missing lookup to filter a board

I’m trying to setup a board to show the Merge Requests related to each user (I’m using Gitlab integration)


Here is how the relation from User to Merge Requests is defined

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

On the User details I can properly see the MRs

Side note : it would also be helpful if on the User details I could see Merge Requests in a view (typically a board) instead of only with fields.

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.

1 Like

Thanks for the answer.

I’ve setup new lookups from MR to Users:

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.

OK, perhaps I misunderstood how your databases are related. Can you clarify the relations (between User, Member gitlab and Merge request)

I think I also got confused by the 3 “user” tables (notion import, fibery users, gitlab members).

Here is my updated configuration:

  • Gitlab Member (std integration) has 4 relations to MRs and one to User

This works well on the Gitlab Member page or to create reports

  • User has a 1 to 1 relation with Gitlab Member

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.

To be continued after next meeting, sorry

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 :slight_smile: I’ll create another thread about that if needed.

From a Gitlab Member (in a smart folder), I can create a Board View with filtered MRs

On the User database, I’ve created relations to MR via Gitab Member. The MRs show on the User page as expected:

When I try to create a Board View in the smart folder for User, I cannot filter the MR in a relevant way:

If I add a lookup from MR to User (via Gitlab Member)

Now only I can filter the board view as expected

In summary, I can find workarounds around this, but I was puzzled by a few behaviours:

  1. the fact I cannot change the view on the User entity, for a relation defined on the User, from fields to board
  2. 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)
  3. 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 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 :crossed_fingers:
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.

Thanks a lot for the clarification ! I suggest these paragraphs are added to the documentation :wink:

1 Like