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 | No | ||||||||||||||||||
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 | OBNetwork customer | => No | ||||||||||||||||
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. |