Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005078Openbravo ERPA. Platformpublic2008-09-17 13:422008-09-24 17:54
Reportergalderromo 
Assigned Tocromero 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOS20OS VersionGentoo 2.6.24
Product Version2.35MP5 
Target VersionFixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customer
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0005078: VALUE columns do not include C_IGNORE_ACCENT function if column reference is 10/14/34 on search popups
DescriptionWhen WAD generates the windows, also generates the code for the massive search popups. This pop up shows the "ISSELECTIONCOLUMN='Y'"

If the columns reference is 10, 14 or 34 and the name of the column is VALUE or DOCUMENTNO the C_IGNORE_ACCENT function is not included on the generated code. Therefore, the searching is case sensitive. Take into account C_IGNORE_ACCENT function includes also an "ignore case" translation.

For example, if I have a project with value="AEB" and I search for "Aeb" no results will be back.
Steps To ReproduceChoose a window containing a VALUE column.
Set up the column as isselectioncolumn and reference=10 or 14 or 34
Go to that window and register a value like AEB
Search values "Aeb"
No results

Proposed SolutionWad.java line 982:
=================
          if (WadUtility.isLikeType(selCol[i].reference) && !WadUtility.isSearchValueColumn(selCol[i].realcolumnname)) {
            selCol[i].xmltext += "C_IGNORE_ACCENT";
          }
          selCol[i].xmltext += "(" + tableName + "." + selCol[i].realcolumnname + ")";



WadUtility.java line
====================
  public static boolean isLikeType (String reference) {
    if (reference==null || reference.equals("")) return false;
    switch (Integer.valueOf(reference).intValue()) {
    case 10:
    case 14:
    case 34: return true;
    }
    return false;
  }

   public static boolean isSearchValueColumn(String name) {
     if (name==null || name.equals("")) return false;
     return (name.equalsIgnoreCase("Value") || name.equalsIgnoreCase("DocumentNo"));
   }

I will take out the Value columns. AEB and aeb and Aeb and aeB should be considered the same value. In my opinion it does not make sense a differente behaviour for "value" columns
Additional Information
TagsGPS-Top20
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2008-09-17 13:42galderromoNew Issue
2008-09-17 13:42galderromoAssigned To => cromero
2008-09-17 13:42galderromosf_bug_id0 => 2116012
2008-09-17 17:50psarobeNote Added: 0009052
2008-09-17 17:50psarobeSeveritycritical => minor
2008-09-17 17:50psarobeIssue Monitored: psarobe
2008-09-24 17:54cromeroRegression testing => No
2008-09-24 17:54cromeroStatusnew => closed
2008-09-24 17:54cromeroNote Added: 0009176
2008-09-24 17:54cromeroResolutionopen => no change required
2008-09-30 12:44pjuvaraTag Attached: GPS-Top20

Notes
(0009052)
psarobe   
2008-09-17 17:50   
This might not be even a bug. This behavior is on purpose and it happens since 2.20 or 2.3x (I don't remember when it changed) and that's the reason why it only applies to this two kind of columns. Said this we could discuss about it and try to see in which cases have sense to be case sensitive and in which ones don't.
In any case this is not a critical or major bug
(0009176)
cromero   
2008-09-24 17:54   
This is not a bug.

Currently the "Search Key" (value column) is used as a kind of alias in order to differentiate and locate records, so we think it is useful to have it case sensitive. Many of customers use the case sensitive to differentiate similar records.