Page MenuHomePhabricator

Change the dropdown in security ticket dropdown to not include WMF Product and WMF Technology as two separate departments
Closed, DeclinedPublic

Description

Since the WMF reorg, there are no separate Product and Technology departments. Instead, there is only one Product & Technology department. This is not reflected in the author affiliation dropdown:

image.png (406×350 px, 56 KB)

which still offers Product and Technology as separate options.

Event Timeline

If the drop down is changing, perhaps miraheze should be added. Miraheze affiliated people report a lot of security bugs.

I can neither find the dropdown config in https://gitlab.wikimedia.org/repos/phabricator/deployment/-/blob/wmf/stable/scap/templates/phabricator/conf/local/local.json.j2 nor older https://phabricator.wikimedia.org/source/operations-puppet/browse/production/modules/phabricator/data/fixed_settings.yaml (who knows if that is still used at all, see T239355) which makes me wonder if T240999: Create 'Author Affiliation' custom drop down field for forms implemented this only live and not in any deployable settings (no clues provided in T252778 either)?

As an admin, I can see requestor.affiliation and its values listed in https://phabricator.wikimedia.org/config/edit/maniphest.custom-field-definitions/
I don't know how to "disable" some dropdown value, apart from removing it and having to update all existing tasks with that value set, which I'm not keen on.
Plus I do not know how/for what security task author affiliation data is actually used and by whom.

sbassett subscribed.

The Security-Team would consider this nice, but fairly low-priority, especially if it's a complex or impossible config change.

How/for what is the security task author affiliation data actually gathered and used, and by whom?

How/for what is the security task author affiliation data actually gathered and used, and by whom?

I think the answer is "nobody", at least for now. It's something that we could theoretically report on one day, to any curious parties or WMF leadership, but is not something that is being actively used at this time AFAIK.

If this data is not being used, then I propose to decline this task, not to collect this data by removing the Affiliation dropdown from all Phabricator Forms, and remove this custom field (though not sure about the implications, need to test how Phab reacts when the config of a Form refers to a non-existing custom field).

Note to myself: SELECT CONCAT("https://phabricator.wikimedia.org/maniphest/task/edit/form/",id), engineKey, builtinKey, name FROM phabricator_search.search_editengineconfiguration WHERE properties LIKE "%requestor.affiliation%" AND properties NOT LIKE "%requestor.affiliation\":\"hidden%"; shows that this custom field is used in 7 task Forms (among them form 105 belonging to RelEng).

I don't mind declining this task. I'm not sure about entirely removing the field. The Security-Team has been setting that when we can. So there already exists a lot of data there that we might not want to lose. And it would be a good thing to track if we were to more thoroughly report on these bugs at some point in the future. But if the desire to de-clutter Phabricator forms outweighs all this, then I suppose it should be removed.

I checked again that aliases in the codebase are only supported for Priority field values but not for any other field values.
I also checked how renaming and deleting such a custom field value behave.

It seems that I could rename one of the two existing Tech or Product field values to something like WMF Product & Tech,
mass-edit a good number of tasks to update that value to the new one,
and delete the other field value (so it cannot be set anymore on tasks).

Is that wanted?

It seems that I could rename one of the two existing Tech or Product field values to something like WMF Product & Tech,
mass-edit a good number of tasks to update that value to the new one,
and delete the other field value (so it cannot be set anymore on tasks).

Is that wanted?

This sounds like a reasonable path forward IMO if it isn't incredibly burdensome.

Aklapper moved this task from To Triage to Administration (UI) on the Phabricator board.

Turns out I was wrong: Removing any option in that dropdown would just display the raw key if an entry were not to exist anymore.
In practice, I see no gain here. If task authors want to identify as WMF Technology, they can. If task authors want to identify as Product, they can.
Especially as data is collected but not used, which in itself is already bad.


<tl;dr>:
In theory, I could

FYI, tasks which either have tech or product set for author affiliation:
SELECT CONCAT("https://phabricator.wikimedia.org/T", t.id) AS taskId, cfs.* FROM phabricator_maniphest.maniphest_task t INNER JOIN phabricator_maniphest.maniphest_customfieldstorage cfs ON cfs.objectPHID = t.phid WHERE cfs.fieldIndex = "jaG2dE6cwsvx" AND (fieldValue = "tech" OR fieldValue = "product");