Openbravo Issue Tracking System - Openbravo ERP |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0010884 | Openbravo ERP | A. Platform | public | 2009-10-06 17:09 | 2009-10-21 00:00 |
|
| Reporter | shuehner | |
| Assigned To | shuehner | |
| Priority | urgent | Severity | major | Reproducibility | have not tried |
| Status | closed | Resolution | no change required | |
| Platform | | OS | 5 | OS Version | |
| Product Version | 2.40 | |
| Target Version | | Fixed in Version | | |
| Merge Request Status | |
| Review Assigned To | |
| OBNetwork customer | |
| Web browser | |
| Modules | Core |
| Support ticket | |
| Regression level | |
| Regression date | |
| Regression introduced in release | |
| Regression introduced by commit | |
| Triggers an Emergency Pack | No |
|
| Summary | 0010884: Audit all queries using LIKE with respect to _ character which is a wildcard and not a normal char |
| Description | In Sql (both oracle and postgres) the _ in a LIKE expression is a wildcard for a any single character.
Example:
select * from m_product where name like 'Product_%';
does also match on the name 'Product 12345'...
All queries (i.e. triggers,functions) should be audited and fixed as many assume that '_' matches just the normal '_' character.
|
| Steps To Reproduce | |
| Proposed Solution | |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | | related to | defect | 0010708 | 2.50MP7 | closed | marvintm | Trigger dissapear in module with dependency, in Postgre |
|
| Attached Files | |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 2009-10-06 17:09 | shuehner | New Issue | |
| 2009-10-06 17:09 | shuehner | Assigned To | => rafaroda |
| 2009-10-06 17:10 | shuehner | Relationship added | related to 0010708 |
| 2009-10-06 17:10 | shuehner | Note Added: 0020792 | |
| 2009-10-09 13:22 | psarobe | Assigned To | rafaroda => shuehner |
| 2009-10-09 13:22 | psarobe | Priority | normal => low |
| 2009-10-09 13:22 | psarobe | Severity | major => minor |
| 2009-10-09 13:22 | psarobe | Status | new => scheduled |
| 2009-10-14 12:28 | shuehner | Note Added: 0021002 | |
| 2009-10-14 12:28 | shuehner | Priority | low => urgent |
| 2009-10-14 12:28 | shuehner | Severity | minor => major |
| 2009-10-20 15:15 | shuehner | Note Added: 0021211 | |
| 2009-10-20 15:17 | shuehner | Status | scheduled => closed |
| 2009-10-20 15:17 | shuehner | Note Added: 0021212 | |
| 2009-10-20 15:17 | shuehner | Resolution | open => no change required |
| 2009-10-21 00:00 | anonymous | sf_bug_id | 0 => 2882769 |
|
Notes |
|
|
|
|
Added relation as issue 10708 is one specified instance of this problem. |
|
|
|
|
|
Changing to major/urgent as this issue already manifested in one obn issue which might lead to data loss. So check for others is more important. |
|
|
|
|
Three groups of issues were found checking this topic, all issues are present from at least 2.3x on until now:
AD_WINDOW_TRG2.xml and AD_TAG_TRG2.xml
When a window or tab is renamed its ad_model_object_mapping entries are renamed as well. They are found using i.e. the broken LIKE '%_Relation.html' which would also match on '%Relation.html'. However these only for system generated/maintained mapping names so in practice this is never a problem.
AD_TAB_IMPORT.xml
When copying ad_column entries into a tab and a column is named UPDATEDBY and the next columnname matches '%_ID' it will be marked as read only. Again this would also match '%ID' but the rule to mark a column a readonly here is arbitrary and undocumented so not worth fixing it.
AD_TABLE_IMPORT.xml
Used by the 'Create column from db process'. This function does make several matches again '%_something' which also match '%something' but again the special rules for changing a columns attributes are arbitrary and completely undocumented. |
|
|
|
|
As stated in last note:
ad_window/ad_tab trigger: will not happen in practice -> no change required
ad_tab_import/ad_table_import only in arbitrary/undocumented special cases -> wontfix |
|