View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0021605 | mantisbt | customization | public | 2016-08-14 13:28 | 2016-08-19 08:41 |
Reporter | cproensa | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | new | Resolution | open | ||
Product Version | 1.3.1 | ||||
Summary | 0021605: user columns configuration precedence | ||||
Description | Currently seems like if these two configurations exists, for columns list: Configuration (1) takes precedence. If a system-wide column list is defined for a project (different from all-projects defaults), may mean that some specific columns are important, as the administrator judged to include them. These columns may be custom fields that only make sense in those projects. If a user has defined an all-projects configuration, may mean that the selected configuration is intended as a default for projects where there are not specific, relevant, columns. So, the user saved "all projects defaults" would replace the system provided "all projects defaults", but not replace the system provided "single project defaults" (unless the user sets a "single project column-list" I find this use case relevant, when creating project-specific custom fields, or plugin fields. | ||||
Tags | No tags attached. | ||||
I think the key here is that there are two concepts: 1) the settings i want to use when using view_all positioned at "all projects" These are not differentiated currently inthe application, as only (2) is managed. |
|
So you're saying we should have All U/All P > All U/P1 > U1/All P > U1/P1 instead of (currently) All U/All P > U1/All P > All U/P1 > U1/P1
I didn't look in detail, but I'm guessing this may be due to the standard config API behavior. Your suggestion make sense, but the implementation may be tricky |
|