Openbravo Issue Tracking System - Openbravo ERP | |||||||||||||||||||
| View Issue Details | |||||||||||||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||||||||
| 0041881 | Openbravo ERP | B. User interface | public | 2019-09-25 09:56 | 2022-02-01 08:07 | ||||||||||||||
| Reporter | alostale | ||||||||||||||||||
| 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 | 0041881: weird field position when different modules define fields in the same tab | ||||||||||||||||||
| Description | Having the following module tree, where B and C depend on module A:
B C
\ /
A
Module A defines a tab with some fields, let's say: * A1 -> seqno 10 * A2 -> seqno 20 If both, B and C, define fields for that tab, as B and C are independent the position of those fields can be weird when installing all together. | ||||||||||||||||||
| Steps To Reproduce | For example, defining the following fields: * B1 -> seqno 12 * B2 -> seqno 15 * C1 -> seqno 13 * C2 -> seqno 30 Would result in * A1 -> seqno 10 * B1 -> seqno 12 * C1 -> seqno 13 * B2 -> seqno 15 * A2 -> seqno 20 * C2 -> seqno 30 Where field C1 is between B1 and B2. As B1 and B2 are defined by module B which does not know about C, it would be expected them to be together. | ||||||||||||||||||
| Proposed Solution | In those cases, it would make more sense to use sequence numbers in B and C to define between which fields from A are going to be set and also a relative position among other fields definted in the same module. For example: * B1 -> seqno 12 * B2 -> seqno 15 * C1 -> seqno 13 * C2 -> seqno 30 Would result in * A1 -> seqno 10 * B1 -> seqno 12 * B2 -> seqno 15 * C1 -> seqno 13 * A2 -> seqno 20 * C2 -> seqno 30 Because: * B1, B2 and C1 are all inserted between A1 (10) and A2 (20) because their sequence numbers are all 10<seqno>20 * Module B has precedence over C (this is something arbitrary, ie. sorting by their UUID), so fields between A1 and A2 are first sorted by module and then by seqno * C2 (30) is after A2 (20) because it's sequence number is greater | ||||||||||||||||||
| Additional Information | |||||||||||||||||||
| Tags | No tags attached. | ||||||||||||||||||
| Relationships |
| ||||||||||||||||||
| Attached Files | |||||||||||||||||||
| Issue History | |||||||||||||||||||
| Date Modified | Username | Field | Change | ||||||||||||||||
| 2019-09-25 09:56 | alostale | New Issue | |||||||||||||||||
| 2019-09-25 09:56 | alostale | Assigned To | => platform | ||||||||||||||||
| 2019-09-25 09:56 | alostale | Modules | => Core | ||||||||||||||||
| 2019-09-25 09:56 | alostale | Triggers an Emergency Pack | => No | ||||||||||||||||
| 2019-09-25 09:57 | alostale | Relationship added | related to 0041652 | ||||||||||||||||
| 2019-09-25 09:58 | alostale | Relationship added | related to 0041654 | ||||||||||||||||
| 2022-02-01 08:07 | alostale | Assigned To | platform => Triage Platform Base | ||||||||||||||||
| There are no notes attached to this issue. |