Which is standard of most systems with related tables.
Just a + sign, opening a modal view of the card type of the related table.
When setting the reference column, you select if it accepts new values or not (if not, you can only create new records directly accessing that table first).
Good point. There is a partial way that works already: if you type a new value into a Reference column, the dropdown listing existing records will have a “+” item to add the new value. It will create a new record in the related table with a single field set to the value you entered.
In cases when a card for the related table is included on the same page, this works very similarly to what you describe. But in general, yeah, I see the value of opening a modal to fill in more of the related record.
Hi Dmitry. The current solution requires a text field for the new record. And a unique value at that.
But just as an example, I am trying to create a Risk Management solution for ISO compliance. So, we have the Risk Directory.
And then we can do risk analysis, which will have an automatic code, a date, and then you select probability and impact (it calculates the Risk Degree) and how you want to deal with the risk, create an action plan if you want to mitigate it, etc.
There is not really a text to describe it, unlike the Risk itself (which has a title). The date can´t be used, because there are several departments and dates can repeat. Etc.
So yeah, having the button to open related form in a modal would be great because it would work for many situations where the current work-around does not.
It sounds like a perfect case for showing two linked widgets on a page, one where you select a Risk, and the second which shows all the subordinate records (the ones with date, code, probability and impact).
Creating such a layout is described in Create your own CRM - Grist Help Center and in Linking Widgets. This layout relies on having a Reference relationship that goes “the other way”: the subordinate records have a Reference columns that points to the main record.
In this layout, you’ll select a record in one table, and will see the related records in a second table on the same page. In this second table, you can also add new rows, which will be automatically linked to the selected record.
In the main record, if you need to write a formula that calculates something using the list of all the subordinate records, you can get those using the lookupRecords() function.
(The Reference Columns Guide is a good overview of all this.)
Apologies if I still misunderstood what you are looking for. If you knew all this already and were only proposing a different layout (a modal rather than a second widget on the same page), that request makes sense, and we actually have a similar idea on the roadmap here. Or if I am way off the mark, maybe you could create a document with some dummy data, turn on link-sharing, and share a link here to help explain.
Yes, that is something on those lines Dmitri. I like the “all widgets on a page” layout… sometimes. Sometimes you want a table occupying the whole page. (many columns and many records). Sometimes you want a form occupying the page (again, many fields). In those cases, a modal would be better (or collapsing/expanding widgets… or maybe even TABS.
With tabs, I can imagine a table and a form for new risk analyses on a single tab. While the Risk Directory tab and the risk single record widget are on the main tab.
Another “option” would be to create links between pages.
Example: have a page with a table with all the risks.
Another page with a form widget. And another page with the Risk Analysis Table and Form.
Then setting that when clicking on any risk of the Risk Tables page, it takes me to the page with the Risks Form (already showing that Risk record).
And when clicking the Risk Analisys field of the Risks Form, it takes me to the Risk Analysis Table and Form, showing only the Analysis linked to that risk.)
Speaking of multiple pages, I made a question yesterday about hiding pages from users, without blocking them from viewing or selecting data from that page.
Not sure if it’s possible now.
I suppose you would have to dissociate tables from pages somehow.
Example: I have a config page where I do have all the risks probabilities and risk impacts that a user can select.
I don´t want users to even see that page, so their menu is smaller. But I need them to select itens from that page when creating Risks and Risk Analysis.
Let’s say it would be analogous to HIDING sheets at Excel. If I have a cell with a list to select itens from a table on that hidden sheet, I can still do it.