Splitting from T385850#10555033. Likely in misc/src/policy/WMFLockTaskController.php. I believe it's never read again.
Description
Description
Details
Details
Related Changes in GitLab:
| Title | Reference | Author | Source Branch | Dest Branch | |
|---|---|---|---|---|---|
| Draft: Stop setting std:maniphest:security_topic | repos/phabricator/extensions!51 | aklapper | T388590secTopic | wmf/stable |
Related Objects
Related Objects
- Mentioned In
- T430410: Replace deprecated Phabricator Conduit API call with stable equivalent (CodeReviewBot)
- Mentioned Here
- T239355: Deprecate phabricator's fixed_settings.yaml (in puppet) and just use phabricator's built in configuration tools
T398460: Phab Scap template vs actual value out of sync for numerous values
T385850: Dead code and non-existing classes mentioned in WMFSecurityPolicy.php
Event Timeline
Comment Actions
aklapper opened https://gitlab.wikimedia.org/repos/phabricator/extensions/-/merge_requests/51
Draft: Stop setting std:maniphest:security_topic
Comment Actions
misc/src/policy/WMFLockTaskController.php only handles the custom "Protect as Security issue" menu item in the task sidebar.
The actual issue is that we have a Custom (dropdown) Field called "Security" in every task, and its value is written for every new task into our DB.
Comment Actions
SELECT * FROM phabricator_search.search_editengineconfiguration WHERE properties LIKE "%security_topic%" AND (properties NOT LIKE "%security_topic\":\"hidden%" AND properties NOT LIKE "%security_topic\":\"default%"); shows that three Forms exposed this field:
- https://phabricator.wikimedia.org/transactions/editengine/maniphest.task/view/8/
- https://phabricator.wikimedia.org/transactions/editengine/maniphest.task/view/104/ (disabled)
- https://phabricator.wikimedia.org/transactions/editengine/maniphest.task/view/117/
All of those set the value of the Security dropdown to "Access Request", and all three lock that value so it cannot be edited by a user.
Two of those forms set the task subtype "Administrative Request", one of those forms sets the default task subtype "Task".
In all three Forms, under "Lock / Hide Fields", I changed "Security" from "Locked" to "Hidden".
Comment Actions
For example, we do not store the "Author Affiliation" custom dropdown field (exists for Security tasks) in the DB when it keeps its default value "N/A".
Wondering how can we do the same for that Security field dropdown, as an initial step to get rid of that in the long term.
Looking at https://phabricator.wikimedia.org/config/edit/maniphest.custom-field-definitions/ , it says that
- in our Database we set "default": "default" for "security_topic"
- in our Local Config we set "default": "default" for "security_topic" and "risk.rating"
The latter likely comes from https://gitlab.wikimedia.org/repos/phabricator/deployment/-/blob/wmf/stable/scap/templates/phabricator/conf/local/local.json.j2 which also defines "default": "default" for "risk.rating".
That difference is yet again T398460: Phab Scap template vs actual value out of sync for numerous values (plus a bit of T239355 as its predecessor to create more entropy).
https://we.phorge.it/book/phorge/article/custom_fields/ only says "default: Default field value." That might welcome upstream clarification when it comes to database writing behavior.
I should probably test this behavior locally first.
Comment Actions
Note that external code depends on this, for example in https://gitlab.wikimedia.org/repos/releng/gitlab-webhooks/-/blob/main/src/glwebhooks/phab.py and https://gitlab.wikimedia.org/repos/releng/gitlab-webhooks/-/blob/main/tests/test_sinks_phabricator.py