Openbravo Issue Tracking System - Openbravo ERP | |||||
| View Issue Details | |||||
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0021425 | Openbravo ERP | A. Platform | public | 2012-08-23 09:10 | 2022-02-01 08:08 |
| Reporter | rgoris | ||||
| Assigned To | Triage Platform Base | ||||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | new | Resolution | open | ||
| Platform | OS | 5 | OS Version | ||
| Product Version | |||||
| 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 | 0021425: Are Search Keys still needed? | ||||
| Description | As I started using the product more and more, I am increasingly annoyed by the need to specify "Search Key" for every record. I really do not know what to put in this field and in most cases it ends up being the same value that I enter in another field, typically the name. As a user, I perceive this as just being useless extra work and after a while I start resenting the product for not respecting my time. The "Search Key" is the code that is used to identify a record. For example, on product, search key is the product code, while name is the user friendly name; referring to my phone, the search key is "I9250XXLF1", while the name is "Samsung Galaxy Nexus". In Openbravo, we have search keys for everything: product, business partner, assets, projects, business partner categories, product categories, accounts, client, organization, etc. In Openbravo 2.50 and earlier versions, the search key was used as a shortcut in the selector; for example, to choose a product you could type a partial product search key and press ENTER; the system would attempt to autocomplete the entry and if only one record was found matching that criteria, it was returned to the field. This was very handy to avoid having to open many pop-up windows to use selectors. In Openbravo 3, with the new behavior of selectors, which auto-complete based on any matching criteria in the name, this need is no longer there. However, the product continues to require search keys to be specified on every master record. In some cases that is fully legitimate. For example, on products, users expect to be able to enter both product code and name. Eeven then, there are some gaps: Why call it search key, if it is a product code? If my business uses product codes, why do I see product names on documents (invoices, orders, etc.)? That behavior (refer to products by name or by code) should be configurable more easily than it is and probably it should be configurable by document (on sales orders I probably want to enter product codes but on expense reports I want to enter product names) and whether the document is internal or external (I might want to use product codes internally but when I print an invoice and send it to the customer it should have product names). The current selector does not autocomplete on product codes. What is the purpose of having product codes, then, if using them is slower than using the product name? In other cases, it is partially legitimate. For example, on business partners I can use the search key to enter the customer number, the supplier number or the employee number. In that case, however, I would like the system to propose the next number and not having to enter it manually. I would also like the system to have different numbering schemes based on the class of business partners, because for example employees have a different number scheme than suppliers. Points 2 and 3 above also apply here. Finally there are too many cases where search key is just not needed and having to enter it is only an annoyance that does not provide any value. For example: business partner category - what is the difference between search key, name and description? I know that this is a legacy thing. However, it is in my opinion creating a usability issue in our current product. Any idea of what to do about it? | ||||
| Steps To Reproduce | na | ||||
| Proposed Solution | |||||
| Additional Information | |||||
| Tags | No tags attached. | ||||
| Relationships | |||||
| Attached Files | |||||
| Issue History | |||||
| Date Modified | Username | Field | Change | ||
| 2012-08-23 09:10 | rgoris | New Issue | |||
| 2012-08-23 09:10 | rgoris | Assigned To | => rgoris | ||
| 2012-08-23 09:10 | rgoris | Modules | => Core | ||
| 2012-08-29 04:30 | eintelau | Issue Monitored: eintelau | |||
| 2013-01-10 15:16 | rgoris | Note Added: 0055460 | |||
| 2013-01-10 15:16 | rgoris | Note Edited: 0055460 | bug_revision_view_page.php?bugnote_id=0055460#r4260 | ||
| 2013-01-10 15:16 | rgoris | Assigned To | rgoris => alostale | ||
| 2017-04-10 14:37 | alostale | Assigned To | alostale => platform | ||
| 2022-02-01 08:08 | alostale | Assigned To | platform => Triage Platform Base | ||
| Notes | |||||
|
|
|||||
|
|
||||