Project:
View Revisions: Issue #30944 | [ All Revisions ] [ Back to Issue ] | ||
Summary | 0030944: some auxiliary inputs might be useless | ||
Revision | 2015-09-28 10:16 by alostale | ||
Description | Auxiliary inputs can be used to define different default values for a field in a tab than the one defined in its associated column. This is done by naming the auxiliary input with the same name that column has. There are some occurrences of this case in the distribution [1]. From them there are 4 cases for C_BPartner_ID in lines for these windows, they are present in the code since the beginning of the mercurial repository: Goods Shipment Goods Receipt Purchase Invoice Sales Invoice They all look similar, having the code as, initially they were @C_BPartner_ID@ but they were changed to fix 0030495: @SQL=SELECT COALESCE(C_InvoiceLine.C_BPartner_ID, C_Invoice.C_BPartner_ID) AS C_BPartner_ID FROM C_Invoice JOIN C_InvoiceLine ON (C_Invoice.C_Invoice_ID = C_InvoiceLine.C_Invoice_ID) WHERE C_InvoiceLine_ID=@C_InvoiceLine_ID@ There are 2 cases: 1. When in NEW mode (creating a new record in lines): they are always NULL because C_InvoiceLine_ID is not set yet. In this case the auxiliary input has no effect other than setting BP as null when which is the case if the column has no default. 2. When in EDIT mode: they take a value. After fixing issue 0030927, the auxiliary input value shouldn't overwrite the current column value. As there is no way to distinguish column and auxiliary input value (nor in display/readonly logic nor in callouts), actual value should be always preserved. Furthermore, none of them are used in display/readonly logic [2]. Because of this, these auxiliary inputs looks not to have any usage. --- [1] Use this query to obtain auxiliary inputs named as a column in the tab they are defined in: select i.name, w.name, t.name, f.name, i.code from ad_auxiliarinput i, ad_field f, ad_column c, ad_window w, ad_tab t where f.ad_tab_id = i.ad_tab_id and f.ad_column_id = c.ad_column_id and c.columnname ilike i.name and t.ad_tab_id = f.ad_tab_id and w.ad_window_id = t.ad_window_id [2] Query to check if these auxiliary inputs are used in display/readonly logic, which returns no rows: select i.name, w.name, t.name, f.name, i.code from ad_auxiliarinput i, ad_field f, ad_column c, ad_window w, ad_tab t where f.ad_tab_id = i.ad_tab_id and f.ad_column_id = c.ad_column_id and c.columnname ilike i.name and t.ad_tab_id = f.ad_tab_id and w.ad_window_id = t.ad_window_id and (f.displaylogic ilike '%'||i.name||'%' or c.readonlylogic ilike '%'||i.name||'%' ) |
||
Revision | 2015-09-28 09:58 by alostale | ||
Description | Auxiliary inputs can be used to define different default values for a field in a tab than the one defined in its associated column. This is done by naming the auxiliary input with the same name that column has. There are some occurrences of this case in the distribution [1]. From them there are 4 cases for C_BPartner_ID in lines for these windows, they are present in the code since the beginning of the mercurial repository: Goods Shipment Goods Receipt Purchase Invoice Sales Invoice They all look similar, having the code as: @SQL=SELECT COALESCE(C_InvoiceLine.C_BPartner_ID, C_Invoice.C_BPartner_ID) AS C_BPartner_ID FROM C_Invoice JOIN C_InvoiceLine ON (C_Invoice.C_Invoice_ID = C_InvoiceLine.C_Invoice_ID) WHERE C_InvoiceLine_ID=@C_InvoiceLine_ID@ There are 2 cases: 1. When in NEW mode (creating a new record in lines): they are always NULL because C_InvoiceLine_ID is not set yet. In this case the auxiliary input has no effect other than setting BP as null when which is the case if the column has no default. 2. When in EDIT mode: they take a value. After fixing issue 0030927, the auxiliary input value shouldn't overwrite the current column value. As there is no way to distinguish column and auxiliary input value (nor in display/readonly logic nor in callouts), actual value should be always preserved. Furthermore, none of them are used in display/readonly logic [2]. Because of this, these auxiliary inputs looks not to have any usage. --- [1] Use this query to obtain auxiliary inputs named as a column in the tab they are defined in: select i.name, w.name, t.name, f.name, i.code from ad_auxiliarinput i, ad_field f, ad_column c, ad_window w, ad_tab t where f.ad_tab_id = i.ad_tab_id and f.ad_column_id = c.ad_column_id and c.columnname ilike i.name and t.ad_tab_id = f.ad_tab_id and w.ad_window_id = t.ad_window_id [2] Query to check if these auxiliary inputs are used in display/readonly logic, which returns no rows: select i.name, w.name, t.name, f.name, i.code from ad_auxiliarinput i, ad_field f, ad_column c, ad_window w, ad_tab t where f.ad_tab_id = i.ad_tab_id and f.ad_column_id = c.ad_column_id and c.columnname ilike i.name and t.ad_tab_id = f.ad_tab_id and w.ad_window_id = t.ad_window_id and (f.displaylogic ilike '%'||i.name||'%' or c.readonlylogic ilike '%'||i.name||'%' ) |
||
Revision | 2015-09-28 09:55 by alostale | ||
Description | Auxiliary inputs can be used to define different default values for a field in a tab than the one defined in its associated column. This is done by naming the auxiliary input with the same name that column has. There are some occurrences of this case in the distribution [1]. From them there are 4 cases for C_BPartner_ID in lines for these windows: Goods Shipment Goods Receipt Purchase Invoice Sales Invoice They all look similar, having the code as: @SQL=SELECT COALESCE(C_InvoiceLine.C_BPartner_ID, C_Invoice.C_BPartner_ID) AS C_BPartner_ID FROM C_Invoice JOIN C_InvoiceLine ON (C_Invoice.C_Invoice_ID = C_InvoiceLine.C_Invoice_ID) WHERE C_InvoiceLine_ID=@C_InvoiceLine_ID@ There are 2 cases: 1. When in NEW mode (creating a new record in lines): they are always NULL because C_InvoiceLine_ID is not set yet. In this case the auxiliary input has no effect other than setting BP as null when which is the case if the column has no default. 2. When in EDIT mode: they take a value. After fixing issue 0030927, the auxiliary input value shouldn't overwrite the current column value. As there is no way to distinguish column and auxiliary input value (nor in display/readonly logic nor in callouts), actual value should be always preserved. Furthermore, none of them are used in display/readonly logic [2]. Because of this, these auxiliary inputs looks not to have any usage. --- [1] Use this query to obtain auxiliary inputs named as a column in the tab they are defined in: select i.name, w.name, t.name, f.name, i.code from ad_auxiliarinput i, ad_field f, ad_column c, ad_window w, ad_tab t where f.ad_tab_id = i.ad_tab_id and f.ad_column_id = c.ad_column_id and c.columnname ilike i.name and t.ad_tab_id = f.ad_tab_id and w.ad_window_id = t.ad_window_id [2] Query to check if these auxiliary inputs are used in display/readonly logic, which returns no rows: select i.name, w.name, t.name, f.name, i.code from ad_auxiliarinput i, ad_field f, ad_column c, ad_window w, ad_tab t where f.ad_tab_id = i.ad_tab_id and f.ad_column_id = c.ad_column_id and c.columnname ilike i.name and t.ad_tab_id = f.ad_tab_id and w.ad_window_id = t.ad_window_id and (f.displaylogic ilike '%'||i.name||'%' or c.readonlylogic ilike '%'||i.name||'%' ) |
Copyright © 2000 - 2009 MantisBT Group |