Found an oddity that I would like to know if it is intentional behavior, or a bug?
When you have a parent and child table, with the child ref-ing back to the parent and ispartof=true. Then you go and edit the parent record, and it shows a list of child records. If you select โnewโ from that inline view, it automatically links the new child record to the parent record. However if you first select โviewโ from the inline view, and then hit the โaddโ button, it does NOT automatically link the parent records.
I imagine this is so because technically you are viewing a filtered set of ALL records of the entire child table, and so the โaddโ button will add any record to the child table, not just one associated with the parent.
My feedback, if this is intentional behavior, is that this is not very intuitive. Since the user is viewing all child records associated with the parent, it would make sense that adding a record here would also automatically associate it with the parent. In my specific case, the parent ref column is marked as required, but also hidden (since it is a uniqueid() nonsense string), but even though it is required, it will allow a child record to be created without any reference.
I tested this with an existing app and for me itโs still adding the correct parent record.
Hmm, thatโs odd. Youโre right it works as expected with another parent-child set that I have in the same app.
I am investigating further, but not sure where to look. Everything seems to be as it should be. Any suggestions?
When you use the inline view as a table view, it will add the Ref value. If the view type is something else, it wonโt add it.
@Aleksi_Alkio How do you set the inline view to something other than table?
If you create an additional view and you set the position to Ref, it uses this view for your inline view instead of the system generated inline view.
@Aleksi_Alkio Yes that is what we seem to have discovered here. But why does it act like that? I guess thatโs back to my original question; is it intended behavior, or a bug? Why canโt we change an inline view to a deck?
Itโs not a bug, itโs by design.
So the reason I made the inline view a deck in the first place was to see a set of action icons, that I created, more easily. Now that Iโve switched it back a table view, Iโm having some trouble getting those actions to display properly. Two of them act on one column, and the third acts on a second column. All three are set to โdisplay inlineโ. Iโve set the column order for the table view to what I want, but the values arenโt being displayed in the two mentioned columns, they have been replaced by the action icons. And the column headers are also not there. If I switch to action off of โdisplay inlineโ, then I canโt see them anymore in the table, but I do see the values.
Add one โemptyโ virtual column and then attach those actions to that column so they wonโt hide that real column.
How do you attach the action to a column?
When you set the actionโs Prominence to โDisplay Inlineโ, you will see an option โAttach to columnโ.
@Aleksi_Alkio I would suggest that you pass on to the dev team that this area needs a bit of cleaning up. I saw no indication, and no obvious documentation, that I should not have changed an inline view from table to deck, and since it seemed to work in all other ways except this one small thing, then I also feel like it should be a possible option. I definitely donโt feel like one could say that there is not a โbugโ here. Maybe there should be an option for setting a certain view to be the inline view? Iโll go ahead and put a feature request up for this.
+Steve Coile Thanks for sticking with me here.
Adds from an inline table generated with REF_ROWS() will include the backref automatically; adds from an inline generated by any other means (e.g., FILTER() or SELECT()) will not.
@Marc_Dillon sure. I will discuss about this.
That makes sense. The inline in the parent record is definitely ref_rows generated.
But once you click the view button, do you still call that an โinlineโ view. Could it have something to do with changing the childโs view type from table to deck?
The view shown by clicking view from an inline table is governed by the ref-position table view configuration, as is the inline view, so I consider them the same view. The inline one, though, is limited to a number of rows configured by UX > Options > DETAIL VIEW > Inline row limit.
What do you mean by, โchanging the childโs view type from table to deckโ?
Sorry, mispoke. I changed the _Inline system view from table to deck. I donโt think that should matter at all, just donโt know where else to look.
The view used is determined by the view type, not the view name. If you changed the view type from table, that view configuration no longer governs the inline table view.
Oh wow. I just changed it back to a table view, and now the backrefs are automatically there in both cases. Thatโs interesting. Everything else looked and seemed to work fine with the inline view as a deck.
I have another inline view that I had set to a deck, and just checked, it has the same problem, it just never made itself known, I guess because the backref was visible and required at the top of the child record so my users had always selected it if they tried to add a child that way.
You say
that the inline table view it no longer governed by it, but that did not seem to be true, the inline view in the parent record was definitely a deck view, so was when I clicked โviewโ. I definitely prefer to remain using the inline deck view in at least one of these cases.
FYI, sometimes a Save & verify data helps fix some app behavior oddities.
User | Count |
---|---|
39 | |
35 | |
29 | |
23 | |
18 |