As I know, in here you are trying to filter the list by typing in a drop down. In that case it is always case insensitive. You don’t have an option to change it. But in search you may get a little icon to enable or disable case sensitivity - see below.

But again this will not affect the sample values in the same drop down, but it will affect after you hit enter in the search field

It should honor the IEE setting for default value, but that will affect IEE as well. At least if you have Update 4 or later

@Rusiru , thanks! We are aware that we can control this in search, it was the drop downs we wanted to be case insensitive. Especially for project selections, that may cause problems if our users don’t get any warning on this, and don’t get any results. 

@Joakim Stolt , we have this setting set to OFF already, but it doesn’t have any effect in Aurena (we are on UPD5). 

Works here, same problem on a new users? Maybe it has remember the other setting 

@Joakim Stolt , It works on some pages, but not when selecting projects on My Time Registration.

Could you check this specific drop drown in your version?

Ok, we only have number based project numbers, but it’s likely same for us

I don’t know if this can be controlled by the user yet, but I have a general comment about case sensitivity in searches, and it is about performance. Unfortunately, case INsensitivity can have negative performance impacts on searches, especially on large amounts of data. So depending on what data is in the list of values (the drop down) it might not even be a viable option to turn such a feature on. Ideally this should be configurable per drop down such that it can be enabled where it works well.

You can also try to request this to be changed by R&D. I believe it is possible to set a field to transform the input to uppercase also in Aurena. 

I’m a Linux/UNIX nerd, so I expect systems to be case sensitive. Most users, however, are looking for case-insensitive searches. It’s an understandable expectation because capitalization doesn’t change the essential meaning of English text. A fish and a FISH are both wet things that swim.

Microsoft SQL Server and MySQL are both case insensitive, so it’s also an understandable expectation from power users familiar with other systems.

We use function based indexes in Oracle to avoid the performance penalty of accommodating this business need. It would be great if indexes like these could find their way into the core product, particularly on customer and supplier names. (Some of my examples are more specialized than others.)

CREATE INDEX c_customer_info_1_ix
          ON customer_info_tab (UPPER(name))
  TABLESPACE ifsapp_index;

CREATE INDEX c_customer_order_2_ix
          ON customer_order_tab (UPPER(order_no))
  TABLESPACE ifsapp_index;

CREATE INDEX c_iso_lang_upper_co1_ix
          ON iso_language_tab (UPPER(language_code), used_in_appl, description)
  TABLESPACE ifsapp_index;

CREATE INDEX c_iso_lang_upper_co2_ix
          ON iso_language_tab (UPPER(language_code), description, used_in_appl)
  TABLESPACE ifsapp_index;

CREATE INDEX c_iso_lang_upper_des1_ix
          ON iso_language_tab (UPPER(description), language_code, used_in_appl)
  TABLESPACE ifsapp_index;

CREATE INDEX c_iso_lang_upper_des2_ix
          ON iso_language_tab (UPPER(description), used_in_appl, language_code)
  TABLESPACE ifsapp_index;