I'm making it an UBN only because we do have people reporting sensitive things in this manner and they more than likely will not understand the intended (or conversion) confidential nature of their filing (isn't sticking.
Played with a bit on T101665 and saw no ACL affects. I did see Mediawiki Security Bug setting activate appropriately, but not OCI. This is most likely since last upgrade, although I didn't test / don't know if it was tested on the one prior to that.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • mmodell | T101715 'other confidential issues' security setting is not activating on existing task | |||
| Resolved | • mmodell | T101929 Next Phabricator Upgrade: 2015-06-10 |
@chasemp: I'm pretty sure this hasn't ever worked with anything other than Mediawiki Security Bug and changing the value of the security dropdown only half-works with Mediawiki Security Bug ...
//if it's not a security bug, do nothing...
if ($security_setting != 'security-bug') {
return new HeraldApplyTranscript($effect,$applied);
}It definitely used to work but how long ago I couldn't say at this point. the only thing I'm sure of is it worked when I wrote http://www.mediawiki.org/wiki/Phabricator/Security as I ran through it all at that time
then again, now I'm doubting myself on the conversion case....
We should probably fix this either way if we can since the two cases should be consistent?
I'm going to un-UBN it then as I'm not entirely sure if this is a regression or a missed feature.
@chasemp: I believe I excluded other values because you didn't think that operations wanted/needed the magic behavior on ops-access-request tasks. I think this was hard-coded from before we even had the other confidential issue option.
ahhh...so 'other confidential issue' is just 'sensitive' retitled but according to T76564: The options of the Security dropdown in Phabricator need to be clear and documented it did behave as I'm thinking at that time