My version: 0.45.3
I've got two tables: contacts and customers.
All my customers are contacts but all my contacts are not customers.
Contacts have a PK and an FK that point to the customer PK.
I build a dashboard and I want my user to be able to filter (select) a customer or a contact using their id (PK).
When a customer is chosen then a contact is chosen too => I don't manage to make this one works
When a contact is chosen then a customer maybe chosen too => when this is the case I don't manage to make it works either.
All my questions are relationally linked to a question that have two columns (IdContact, IdCostumer). Filter on contact is linked with the IdContact field of all the cards and Filter on customer is linked with the IdCustomer field of all the cards.
What I'm missing?
Regards,
I think it only works one way. In the filter you want to be restricted, you define the linked filter.
Alternatively, you could have 2 simple question on the dashboard that just lists all the contacts/customers. Clicking on the contact or customer would filter the whole dashboard including the lists.
Yes I know. Presently, it's really restrictive (one way) and it looks hard to make the system guess the way to filter element. Moreover when you use the public share of the dashboard, you lose the links feature you were speaking about.
It's not clear how the types should be declared in the model. In my case that's just PK and FK, and I don't think it's a good idea to move to 'category' type just to have a list of the possible values (by the way it's not useful in this use case).
I proposed a new feature here: Make linked filters easier · Issue #29203 · metabase/metabase · GitHub if ever other would be interested.
The only workaround I found in the meanwhile is to script a proxy that guess those two values and build the dashboard URL accordingly, and then move to the result.
For the PK/FK as categories, you can create a view that has the column in twice with different names. From a database perspective, the PK/FK shouldn't be meaningful to the user. You should have a separate customer/contact reference for that. Using the keys like this just stores up problems for future changes.