Content
View differences
Updated by Klaus Zanders 1 day ago
A work package type such as Bug defines which fields appear on its form. With variants (like "Bug: Hardware"), each variation can define its own set of fields. So variants 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, ##FND-106already deals with variants in a project
**❓** **How does the existing project-based custom field activation relate to variants?**
## **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 types or variants 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 variant, which is possible
* With it, we still need to decide how we deal with new fields ##OP-17168
fields ##OP-17168
## **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 variant.
* In "Bug: Hardware", show "Hardware component" on Bugs but hide it on Task
* **Pros**: Maximum flexibility for local tweaks without defining a variant.
* **Cons**: Significantly more complex to configure and to reason about.
* It largely duplicates what a variant is for, so we'd have two overlapping ways to do the same thing,
## **Option C: Variants all the way**
* Projects can no longer deactivate specific fields of a type or variant
* 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 variants
* **Cons:**
* We need to migrate all current project specific configuration into a type variant. cost-type. Worse case: One variant 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 distinct combination into its own variant 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 variants. 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 variant, 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, ##FND-106already deals with variants in a project
**❓** **How does the existing project-based custom field activation relate to variants?**
## **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 types or variants 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 variant, which is possible
* With it, we still need to decide how we deal with new fields ##OP-17168
A project could turn a field on for one type and off for another, in the same project, without creating a variant.
* In "Bug: Hardware", show "Hardware component" on Bugs but hide it on Task
* **Pros**: Maximum flexibility for local tweaks without defining a variant.
* **Cons**: Significantly more complex to configure and to reason about.
* It largely duplicates what a variant is for, so we'd have two overlapping ways to do the same thing,
* Projects can no longer deactivate specific fields of a type or variant
* 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 variants
* **Cons:**
* We need to migrate all current project specific configuration into a type variant.
* This recreates the exact problem the whole epic exists to avoid. Real instances have many projects with slightly different field selections. Turning every distinct
* It's a breaking change for every existing customer, not only the ones who adopt variants. 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 variant, rather than flipping a switch.