Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

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
Powered by Mantis Bugtracker