I'm not exactly sure why this is happening. I looked through the security plugin code and I don't see anything that would be causing this.

+1

No need to "+1" when you can "Award Token". :)

happy? :)

apparently this is not just a problem at initial filing time. T109#10883:

jeremyb-phone set Security to none.

In T479#10885, @jeremyb-phone wrote:

apparently this is not just a problem at initial filing time.

Yes, it also affects tickets that were imported or created before setting up the specific Security field values.

Do we have any idea whether the Bugzilla and RT migrated tasks will inherit this problem as well?

Can this be tested on the bugzilla preview?

Imported BZ tasks didn't get "changed Security from none to none", thankfully. But the first time you use "Edit Task", Phabricator thinks that you "set Security to none", which is equally annoying. See T58091 for an example.

Is it worth to ask for a second pair of eyes upstream? It is just a detail but it is indeed annoying.

In T479#777578, @Qgil wrote:

Is it worth to ask for a second pair of eyes upstream? It is just a detail but it is indeed annoying.

Yes.

As an intermediate solution, could we have a bot go through and null edit every task to mark all the tasks that are currently public as Security = none.

This currently feels like death by a thousand cuts. If Phabricator/Maniphest insists that every task have a security policy, can we just do a single pass with a bot and get this over with?

Please let us fix T493 (should be done one of these days) and see what happens with this problem.

I finally got to the bottom of the "none" to "none" issue:

The field configuration has "default": "none"
And the options also has "default": "none"

however, the value of "default" is supposed to point to the key of the entry in options, so
we need to change it to "default": "default" as in the following field config:

 "security_topic" : {
   "default" : "default",
   "description" : "Used for security oriented custom extensions",
   "instructions" : "Security settings will override permissions and projects as needed.",
   "name" : "Security",
   "options" : {
     "default" : "none",
     "sensitive" : "Private Issue",
     "security-bug" : "Security Bug"
   },
   "search" : true,
   "type" : "select"
}

Change 179407 had a related patch set uploaded (by 20after4):
change "default: none" to "default: default" for phabricator's security_topic field to fix the "changed none to none" bug. This fixes T479

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

Patch-For-Review

This is extra confusing when a task has a non-public view policy. Security is none but also it's not visible to a typcial user. (maybe off-topic for this task. feel free to point me somewhere else)

@jeremyb, can you post here the number of the task you are referring to?

non-public tasks should have the Security field set to something other than "none", as it is the case reported in T76008 (a blocked task that I hope is solved by the same patch under review for this one).

look at almost any ops-core task

@Qgil & @jeremyb-phone: The patch linked above will resolve the issue of confusing entries in the task transaction log. It will not prevent you from setting a custom policy yet leaving the security field set to none. You shouldn't need to use the custom policy interface, just set the security field and let phabricator take care of generating the custom policy for you.

Change 179407 merged by Rush:
phabricator: Change security_topic from "default: none" to "default: default"

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

The "USERNAME set Security to none" action is still happening for tasks imported from bugzilla, and is confusing some users. See T20871#983927

In T479#840405, @MZMcBride wrote:

As an intermediate solution, could we have a bot go through and null edit every task to mark all the tasks that are currently public as Security = none.

This currently feels like death by a thousand cuts. If Phabricator/Maniphest insists that every task have a security policy, can we just do a single pass with a bot and get this over with?

There's a plan to do this or has it been declined?

Nemo, I don't understand why you insist on keeping two tasks about one issue open.

No. There were two errors triggered (likely) by different code paths:

1. "Qgil changed Security from none to None." in the initial task creation (like in the timeline of this task). This has been fixed, and thus this task should be closed.
2. "scfc set Security to None." in subsequent uses of "Edit Task" (like in the timelines of T87135 or T89398). This has not been fixed, and is covered by T87135.

Mixing this up in one task is not aiding fixing them as then energy is lost in deciphering what already has been resolved and what still needs to be fixed.

Accidental clash. Known issue. Sorry for the noise.