Found an oddity that I would like to know if ...

[Marc_Dillon]

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.

[Aleksi_Alkio]

I tested this with an existing app and for me it’s still adding the correct parent record.

[Marc_Dillon]

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?

[Aleksi_Alkio]

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.

[Steven_Coile]

@Aleksi_Alkio How do you set the inline view to something other than table?

[Aleksi_Alkio]

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.

[Marc_Dillon]

@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?

[Aleksi_Alkio]

It’s not a bug, it’s by design.

[Marc_Dillon]

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.

[Aleksi_Alkio]

Add one “empty” virtual column and then attach those actions to that column so they won’t hide that real column.

[Marc_Dillon]

How do you attach the action to a column?

[Aleksi_Alkio]

When you set the action’s Prominence to “Display Inline”, you will see an option “Attach to column”.

[Marc_Dillon]

@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.

[Steven_Coile]

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.

[Aleksi_Alkio]

@Marc_Dillon sure. I will discuss about this.

[Marc_Dillon]

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?

[Steven_Coile]

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.

[Steven_Coile]

What do you mean by, “changing the child’s view type from table to deck”?

[Marc_Dillon]

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.

[Steven_Coile]

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.

[Marc_Dillon]

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.

[Steven_Coile]

FYI, sometimes a Save & verify data helps fix some app behavior oddities.