I was wondering if the ChipInput had been considered for this field? It could accept Phab task ID or URL, and display the task ID in a chip. That'd be smaller than the full URL, and we'd not have to implement the add/remove logic. But perhaps this was all thought through before, in which case no worries and I'll carry on with the designs as they are, with URLs! :-)

Also, do we have a standard name for Phabricator tasks? In Phab they're called 'tasks', but we often talk about them as 'tickets' although that seems like a less common name on-wiki. The designs have "Include Phabricator task?" followed by "Ticket URL", and I wonder if the latter should say "Task URLs:" (also with the colon and plural)?

In T364616#9790057, @Samwilson wrote:

I was wondering if the ChipInput had been considered for this field? It could accept Phab task ID or URL, and display the task ID in a chip. That'd be smaller than the full URL, and we'd not have to implement the add/remove logic. But perhaps this was all thought through before, in which case no worries and I'll carry on with the designs as they are, with URLs! :-)

Also, do we have a standard name for Phabricator tasks? In Phab they're called 'tasks', but we often talk about them as 'tickets' although that seems like a less common name on-wiki. The designs have "Include Phabricator task?" followed by "Ticket URL", and I wonder if the latter should say "Task URLs:" (also with the colon and plural)?

I'd say yes to all of the above! The ChipInput didn't exist when this was designed, and I agree it makes a lot more sense in this case.

I would think the label "Tasks:" is sufficient, because whether they enter a URL or not we would display it as T12345.

samwilson opened https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/23

Add 'Phabricator tasks' field to intake form

tstarling merged https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/23

Add 'Phabricator tasks' field to intake form

samwilson opened https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/36

Add the tasks template param

musikanimal merged https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/36

Add the tasks template param

samwilson opened https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/54

Normalize Phabricator IDs when loading and saving

The last part here is to make sure that the T-numbers always end up with uppercase Ts and not duplicated (even if the template is edited manually with invalid data).

musikanimal merged https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/54

Normalize Phabricator IDs when loading and saving

I think this is ready for QA

current Patch Demo: https://patchdemo.wmflabs.org/wikis/780dec507c/wiki/Community_Requests/Intake

musikanimal opened https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/62

PhabricatorTasks: use Array prop type instead of string

Moving back to Needs Review since I added one more change at https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/62

tstarling merged https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/62

PhabricatorTasks: use Array prop type instead of String

Ready for QA :)

Acceptance criteria

• The field should be optional

When I don't enter any Phab tasks, I see two default tasks (T12345 and T54321). I assume we should show nothing instead.

• Users should be able to copy and paste a phab task number or the URL
• Users should be able to paste multiple urls into the field, and paste multiple URLs at once

It accepts forms like T364959,T365122,T365157, T364959 T365122 T365157 and https://phabricator.wikimedia.org/T363219 https://phabricator.wikimedia.org/T363221 https://phabricator.wikimedia.org/T363816.

It also removes duplicate tasks.

• Users should be able to tap "x" to remove a phab ticket

Yep.

• When the form is submitted, only valid phab tasks should populate in the wish page. All links should link to the relevant phab tasks.

The form removes any invalid input after the user submits. It might be nicer to do this before a user submits, letting them correct any mistakes they have made. Otherwise, they might lose data.

If I am editing an existing wish, if I make a change only to the "Phabricator tasks" the "Submit wish" button remains disabled, so I cannot save. I have to make a change to another field as well. A similar thing happens for the Projects checkbox.

Test environment: https://patchdemo.wmflabs.org/wikis/780dec507c

The form removes any invalid input after the user submits. It might be nicer to do this before a user submits, letting them correct any mistakes they have made. Otherwise, they might lose data.

I'm not seeing this. Anything other than a T-number is removed from the field immediately if you blur or hit enter, before you click submit (or anything else). Although maybe I'm misunderstanding.

If I am editing an existing wish, if I make a change only to the "Phabricator tasks" the "Submit wish" button remains disabled, so I cannot save. I have to make a change to another field as well. A similar thing happens for the Projects checkbox.

This also is not happening for me (so perhaps both these issues have been fixed in subsequent work since you tested). Not only does changing the 'Phabricator tasks' field make the submit button undisabled (to abuse the double negative) it even does it if I enter an invalid string, i.e. when there's nothing to save (that should perhaps be fixed, but it's less of a worry than not being able to submit at all because saving at this point wouldn't make any changes).

This also is not happening for me (so perhaps both these issues have been fixed in subsequent work since you tested).

Indeed, it was fixed with !71.