Page MenuHomePhabricator

TemplateData: Add a way to express dependencies between parameters
Open, LowPublicFeature

Description

Add a way to mark a parameter to be dependent on an other paramter. For example :
We have following parameters:
"foo1_bar", "foo1_baz", "foo1_quux"
...
"fooN_bar", "fooN_baz", "fooN_quux"

fooX_bar required fooX_baz to be used as well, it doesn't require fooX_quux to be used, but if fooX_quux is used, then fooX_bar must have been defined as well


Version: unspecified
Severity: enhancement

Details

Reference
bz50407

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:49 AM
bzimport added a project: TemplateData.
bzimport set Reference to bz50407.

See also [[User:קיפודנחש/TemplateParamWizard#Depends on]].

Change 73708 had a related patch set uploaded by AzaToth:
Add depends and conflicts parameters

https://gerrit.wikimedia.org/r/73708

Note that as for a parameter "going together with" other parameters, this is what a "Set" is for.

Though Sets are merely suggestive and allow for overlap, it us a lot easier to work with from a user interface perspective.

Though TemplateData is generic and should not be tailored specific for VisualEditor, right now I'd recommend we hold off on this change until we find out and/or verify that this can be properly represented in a user interface without making it too complex.

(In reply to comment #3)

Note that as for a parameter "going together with" other parameters, this is
what a "Set" is for.

Though Sets are merely suggestive and allow for overlap, it us a lot easier
to
work with from a user interface perspective.

Set doesn't make any sense for parameters like "author1, author2, ..., authorN"

Though TemplateData is generic and should not be tailored specific for
VisualEditor, right now I'd recommend we hold off on this change until we
find

"depends" and "conflicts" are pretty much not tailored for VE at all (Though I could agree, sets are).

out and/or verify that this can be properly represented in a user interface
without making it too complex.

The most important thing is that common templates can be modeled correctly without ending up with too many false choices, or hiding true choices because they couldn't be modeled correctly.

at en.wp a user has given the example of [[template:for]] where parameter 3 is optional unless parameter 4 is specified, when it becomes mandatory.

They expected that VisualEditor would give them a warning about using parameter 4 without parameter 3. Obviously this is not possible until TemplateData can define such relationships.

Change 73708 abandoned by Krinkle:
Add depends and conflicts parameters

Reason:
Closing for now to clear review backlog. Can be re-activated when the feature request is accepted.

https://gerrit.wikimedia.org/r/73708

[Moved from bug 60358 discussion.]

(In reply to Helder from bug 60358 comment #10)

(In reply to James Forrester from bug 60358 comment #9)

(In reply to Helder from bug 60358 comment #8)

(In reply to James Forrester from bug 60358 comment #6)

(In reply to Ricordisamoa from bug 60358 comment #5)

or a set of fields may be mutually exclusive (and yet one of them would
be required).

That doesn't make sense. "Required" means "the template will die horribly if
you don't include this". It is *not* a "we'd like you to fill this in" –
that's what "suggested" is for. Most templates will have no 'required'
fields.

It seems perfectly valid for a template to require that "either A or B be
provided" and the user should be able to delete one of them if it is not
needed.

This feels like a pretty edge case (and suggests that we should consider
whether the template should be re-written to be less anti-human); maybe file
a TemplateData bug to ask for a way to express this relationship?

This kind of relationship between parameters was requested on bug 50407.

Well, as I see it, this bug only asks for param-level relationships – if A also B; if C not D; etc.

Should we extend it for shared-param relationships (exactly one of A, B and C are required; D is an alias for E if F is set but is an alias for G if F is not set; …), or should we create a new bug? (BTW, this feels like a potentially ever-expanding system could be created, and we'd probably say this adds too much complexity for the value.)

Well, I have another case: In German Wikipedia we have Template:Charteintrag, where not only such dependencies are required (eg if “POS_xy” then also “WO_xy”), but even the parameter names depend heavily on earlier added parameters. If I enter 1=x and 2=y, the possible parameters following are POS_x (with WO_x) and POS_y (with WO_y), but of course not eg POS_z! At the moment TemplateData is totally useless with this template, I fear.

Whatamidoing-WMF changed the task status from Open to Stalled.Nov 16 2015, 6:28 PM
Aklapper changed the task status from Stalled to Open.Nov 1 2020, 10:43 PM

The previous comments don't explain who or what (task?) exactly this task is stalled on ("If a report is waiting for further input (e.g. from its reporter or a third party) and can currently not be acted on"). Hence resetting task status, as tasks should not be stalled (and then potentially forgotten) for years for unclear reasons.

(Smallprint, as general orientation for task management:
If you wanted to express that nobody is currently working on this task, then the assignee should be removed and/or priority could be lowered instead.
If work on this task is blocked by another task, then that other task should be added via Edit Related Tasks...Edit Subtasks.
If this task is stalled on an upstream project, then the Upstream tag should be added.
If this task requires info from the task reporter, then there should be instructions which info is needed.
If this task needs retesting, then the TestMe tag should be added.
If this task is out of scope and nobody should ever work on this, or nobody else managed to reproduce the situation described here, then it should have the "Declined" status.
If the task is valid but should not appear on some team's workboard, then the team project tag should be removed while the task has another active project tag.)

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:13 AM
Aklapper removed a subscriber: TrevorParscal.