Skip to main content ↑ ↓
Topic: Better field lookup for Master - Detail (List Page) (Read 1501 times) previous topic - next topic

Better field lookup for Master - Detail (List Page)

In current version, the JOIN interface on List page for the field having master - detail relation with other table allows selecting of table and defining the JOIN over field, to be selected by User. This further imports all fields to the List page field-list. This becomes difficult to handle when tables have too many fields.

I wish the JOIN interface allows me to select the field I want there itself or allows me to edit the SQL statement so only the required fields are selected from master table.

See the screenshot below for illustration of what I mean to say here...

Re: Better field lookup for Master - Detail (List Page)

Reply #1 –
I second that suggestion. It gets super complex when importing 3/4 tables with many fields. So, either selecting what fields to import or allowing some fields to be removed in the "Page Fields" would be a nice addition.

Having said that, I also have to admit that having all fields there at the same time, allowed me to add some more to the list without having to go back to the Join screen.

Probably a good addition would also be to use the notation :  table.field  so at least you know where the field comes from

Re: Better field lookup for Master - Detail (List Page)

Reply #2 –
Thanks for the suggestions. But after you finish setting the Master Detail table join, the list page contain all the fields which you can select on the fields you want.

On the table.field that's a great idea but that is also implemented on the SQL query back end.

Best regards
 

Re: Better field lookup for Master - Detail (List Page)

Reply #3 –
I know that table.field concept is in the SQL backend, but my point was to display the field reference in the User Interface using that same notation, so at least you know where it comes from and also prevents mistakes. Example, if someone is joining lots of tables, you might end with several fields that share the same name (id, name, etc) and you don't really know where they come from. Something like this products.id , customer.name would make it more readable when building using the graphic interface (table.field)