Project:
View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
ID | ||||||||
0007923 | ||||||||
Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
defect | [Openbravo ERP] 03. Procurement management | minor | always | 2009-03-03 18:10 | 2009-03-18 11:03 | |||
Reporter | networkb | View Status | public | |||||
Assigned To | alostale | |||||||
Priority | immediate | Resolution | no change required | Fixed in Version | ||||
Status | closed | Fix in branch | pi | Fixed in SCM revision | ||||
Projection | none | ETA | none | Target Version | 2.40 | |||
OS | Any | Database | Oracle | Java version | ||||
OS Version | Database version | Ant version | ||||||
Product Version | 2.40 | SCM revision | r13675 | |||||
Review Assigned To | ||||||||
Web browser | ||||||||
Modules | Core | |||||||
Regression level | ||||||||
Regression date | ||||||||
Regression introduced in release | ||||||||
Regression introduced by commit | ||||||||
Triggers an Emergency Pack | No | |||||||
Summary | 0007923: Error applaying validation on c_tax_id field from Invoice line tab in Purchase Invoice window | |||||||
Description | The c_tax_id column in the c_invoiceLine table has a validation from a check box. When the check box is not checked (by default), the tax combo shows the taxes checked in c_tax as ISTAXUNDEDUCTABLE = 'Y' (as it is indicated in the validation). When the check is checked, the tax combo shows the taxes checked in c_tax as ISTAXUNDEDUCTABLE = 'N' (as it is indicated in the validation too). The problem comes when the check box is uncheked again because the tax combo shows not taxes at all. However when the check box is rechecked the tax combo shows correctly the c_tax marked as ISTAXUNDEDUCTABLE = 'N'. So, the problem appears when the check box is not checked and it has been checked before | |||||||
Steps To Reproduce | To create a column in c_invoiceline as char (1byte), as not nullable and 'N' as default value. To define the column and the field in Openbravo. To insert a validation (or modify the table validation of the table reference) in the c_tax_id field of the c_invoiceline table. I have tried different equivalent validations but the result is always the same. I write some of the examples: Ej 1.- c_tax.ISTAXUNDEDUCTABLE <> @cus_isdeductible@ Ej 2.- (c_tax.c_tax_id in (select c_tax_id from c_tax where c_tax.ISTAXUNDEDUCTABLE <> @cus_isdeductible@)) Ej 3.- ((c_tax.ISTAXUNDEDUCTABLE ='N' and @cus_isdeductible@ = 'Y') OR (c_tax.ISTAXUNDEDUCTABLE = 'Y' and @cus_isdeductible@<>'Y')) | |||||||
Tags | No tags attached. | |||||||
Attached Files | ||||||||
Relationships [ Relation Graph ] [ Dependency Graph ] | ||||||||
|
Notes | |
(0014426) alostale (manager) 2009-03-05 10:42 edited on: 2009-03-05 10:43 |
Here there's a HTML limitation, let me explain briefly where it is. Checkboxes are defined as HTML <input type="checkbox" value="Y">, this means that when the checkbox is selected the value it takes is "Y" other case blank, the problem is that afaic is not possible to set the non-checked value as "N". The validation works fine when the check is set as "N" and it is saved, but not when changing its value dynamically because the record is not saved, and the value the backend receives is "Y" in case the check is selected and blank instead of "N" when it is not selected. The solution for this requires a big refactorization in the checkboxes implementation, anyway I've reported a bug for this: 0007964. Anyway there's an easy workarrond which is to treat the blank value of the checkbox as "N" when defining the validation, in this case this validation would work fine: (COALESCE(@cus_isdeductible@,'N')='Y' and c_tax.ISTAXUNDEDUCTABLE ='N') OR (COALESCE(@cus_isdeductible@,'N')='N' AND c_tax.ISTAXUNDEDUCTABLE ='Y') Is this solution enough for your problem? |
(0014429) networkb (developer) 2009-03-05 11:09 |
Thank you, both the sotltion and the explication are perfects |
(0014487) alostale (manager) 2009-03-06 16:42 |
As the workarround is enough no additional changes required in this issue. |
Issue History | |||
Date Modified | Username | Field | Change |
2009-03-03 18:10 | networkb | New Issue | |
2009-03-03 18:10 | networkb | Assigned To | => rafaroda |
2009-03-03 18:10 | networkb | Regression testing | => No |
2009-03-03 18:19 | rafaroda | Priority | normal => immediate |
2009-03-04 09:26 | rafaroda | Type | backport => defect |
2009-03-04 16:43 | rafaroda | Assigned To | rafaroda => alostale |
2009-03-04 16:43 | rafaroda | Status | new => acknowledged |
2009-03-05 10:42 | alostale | Note Added: 0014426 | |
2009-03-05 10:43 | alostale | Note Edited: 0014426 | |
2009-03-05 10:43 | alostale | Relationship added | related to 0007964 |
2009-03-05 10:44 | alostale | Status | acknowledged => scheduled |
2009-03-05 10:44 | alostale | fix_in_branch | => pi |
2009-03-05 10:44 | alostale | Status | scheduled => feedback |
2009-03-05 11:09 | networkb | Note Added: 0014429 | |
2009-03-06 16:42 | alostale | Status | feedback => closed |
2009-03-06 16:42 | alostale | Note Added: 0014487 | |
2009-03-06 16:42 | alostale | Resolution | open => no change required |
2009-03-18 11:03 | anonymous | sf_bug_id | 0 => 2691456 |
Copyright © 2000 - 2009 MantisBT Group |