Content
View differences
Updated by Oliver Günther 1 day ago
A work package type such as Bug defines which fields appear on its form. With sub-types (like "Bug: Hardware"), each variation can define its own set of fields. So sub-types already give us a way to say "this kind of Bug shows these fields."
Separately, today OpenProject lets a project turn individual fields on or off. This is useful: not every project cares about every field.
However, <mention class="mention" data-id="76548" data-type="work_package" data-text="##FND-106" data-display-id="FND-106">##FND-106</mention>already deals with sub-types in a project
**❓** **How does the existing project-based custom field activation relate to sub-types?**
## Option A: Keep a project switch but simpler
* A project can turn a field on or off for the whole project. project.
* When it's on, it appears on every type in that project that uses it
* When it's off, it's hidden everywhere in that project.
* **Pros**: The project's field list only shows fields that its active (sub-)types actually use, so it's not cluttered. Nothing new to learn as the place is the same as before
* **Cons**: You can't have the same field visible for one type but hidden for another within the same project using the switch alone. alone.
* That case would require creating a sub-type, which is possible
* With it, we still need to decide how we deal with new fields ##OP-17168
<br>
## Option B: Let the project differentiate fields per type
A project could turn a field on for one type and off for another, in the same project, without creating a sub-type.
* In "Bug: Hardware", show "Hardware component" on Bugs but hide it on Task
* **Pros**: Maximum flexibility for local tweaks without defining a sub-type.
* **Cons**: Significantly more complex to configure and to reason about. about.
* It largely duplicates what a sub-type is for, so we'd have two overlapping ways to do the same thing,
<br>
## Option C: Sub-types all the way
* Projects can no longer deactivate specific fields of a (sub-)type
* If you want to use a type, you need to use it all or nothing
* **Pros:** Easy to communicate and explain in a project. The active fields are simply the UNION of all sub-types
* **Cons:**
* We need to migrate all current project specific configuration into a cost-type. Worse case: One sub-type per project
* This recreates the exact problem the whole epic exists to avoid. Real instances have many projects with slightly different field selections. Turning every distinct combination into its own sub-type can produce dozens or hundreds of near-identical "Bug" variants.
* It's a breaking change for every existing customer, not only the ones who adopt sub-types. The per-project field switch is something probably all instances rely on today
* After migration, hiding a single field in one project always means creating or picking a sub-type, rather than flipping a switch.
Separately, today OpenProject lets a project turn individual fields on or off. This is useful: not every project cares about every field.
However, <mention class="mention" data-id="76548" data-type="work_package" data-text="##FND-106" data-display-id="FND-106">##FND-106</mention>already deals with sub-types in a project
**❓** **How does the existing project-based custom field activation relate to sub-types?**
## Option A: Keep a project switch but simpler
* A project can turn a field on or off for the whole project.
* When it's on, it appears on every type in that project that uses it
* When it's off, it's hidden everywhere in that project.
* **Pros**: The project's field list only shows fields that its active (sub-)types actually use, so it's not cluttered. Nothing new to learn as the place is the same as before
* **Cons**: You can't have the same field visible for one type but hidden for another within the same project using the switch alone.
* That case would require creating a sub-type, which is possible
* With it, we still need to decide how we deal with new fields ##OP-17168
<br>
## Option B: Let the project differentiate fields per type
A project could turn a field on for one type and off for another, in the same project, without creating a sub-type.
* In "Bug: Hardware", show "Hardware component" on Bugs but hide it on Task
* **Pros**: Maximum flexibility for local tweaks without defining a sub-type.
* **Cons**: Significantly more complex to configure and to reason about.
* It largely duplicates what a sub-type is for, so we'd have two overlapping ways to do the same thing,
<br>
## Option C: Sub-types all the way
* Projects can no longer deactivate specific fields of a (sub-)type
* If you want to use a type, you need to use it all or nothing
* **Pros:** Easy to communicate and explain in a project. The active fields are simply the UNION of all sub-types
* **Cons:**
* We need to migrate all current project specific configuration into a cost-type. Worse case: One sub-type per project
* This recreates the exact problem the whole epic exists to avoid. Real instances have many projects with slightly different field selections. Turning every distinct combination into its own sub-type can produce dozens or hundreds of near-identical "Bug" variants.
* It's a breaking change for every existing customer, not only the ones who adopt sub-types. The per-project field switch is something probably all instances rely on today
* After migration, hiding a single field in one project always means creating or picking a sub-type, rather than flipping a switch.