In T6502#187499, @dpaola2 wrote:

We have no precedents of abuse in Phabricator so far, but looking at our history with Bugzilla I will not be surprised the morning we find a first precedent.

^ I am incredibly jealous of your perspective and am really, really surprised you haven't had this problem yet!

For what its worth, the biggest violators at my company tend to be company executives who (sometimes) rightfully wish to skirt our process. But, when they see how trivial it is to skirt our process, they're tempted to do it more often. And then they do it more often.

Any estimation how long can this be fixed? If it takes long, I will break the parent/subproject relationship. Otherwise I can just wait for the fix.

This is on EditEngine + Modular Transactions now. There are probably still some remaining issues I didn't catch.

One problem with updating this is that recurring events currently work like this:

Ah sorry for the confusion. I was trying to keep up to date on the weekly updates and didn't realize this flow had changed. I'll look at upgrading in the following week or two.

There are two completely different flows. At HEAD, the flow is entirely different and uses none of the same code.

there's no way to change "Edit Policy" from the initial form page

Is that not the same thing as "Editable By" during repository creation?

This would work now, except that there's no way to change "Edit Policy" from the initial form page.

Nevermind I am wrong. Anyways, @epriestley can explain policies better. I think this is correct on our side.

If I set "Can Edit" to Noone and "Can Create" to Admins, I can create repositories. But this is current Phabricator.

Yea I'm really sorry about March 4th. I'll probably look at upgrading in the following weeks. I slowed down updating because of the new UI layout to differential revisions which I thought would upset some people, needed to wait for warmer weather, etc. :x)

Anyways... this sounds correct. Why should a user be able to create something they can't edit?

March 4th?

I think there were some bugs in the past that have now been resolved, but I'm not planning to fix the root of this, which is that you can not create repositories if the default "Edit Policy" excludes you, even if you have permission to create them according to "Can Create Repositories".

Just to add: in a big organizations Spaces can be used to divide different legal entities in a group (or big departments).
With this use most probably the majority of the users will belong just to one space, and they will just see the (default) "public" space and their own one. That means that in this case the majority of the users will not even need the switch, but just the possibility to configure the default space for new objects to their own one (not the default "public" space).
The user configurable parameter for the default space for the new objects creation can be anyway a first step in implementing then the full functionality of Space switching.

Right now, the main concern is trained employees moving cards on the workboard and accidentally changing priorities (due to sorting by priority), so I agree that improving the UI would be the higher priority. In the meantime, perhaps we'll patch our instance with https://secure.phabricator.com/T8135#130563 to prevent the surprise priority changes.

Why are users who shouldn't be changing priorities doing it?

The concern that @magcius mentions is that we (Endless Computers) only want team leads to have permission to triage priority. We set that up by restricting who has access to forms that allow editing priority. But the priority-sorted workboard defeats that form-based protection. Is there some other way to configure who has the ability to triage priority?

See T10333 for plans to make dragging cards in sorted workboards more clear (and T8135 for additional discussion). Those UIs aren't as clear as they should be and we'd like them to be more clear.

We might still need this. We use priority aggressively for feature planning, and make sure only team leads can triage and adjust priorities.

Interesting. I just went and tried it again and different times its failing in different ways. I'm going to give up and assume this is something wonky in my browser until I prove otherwise.

1. Go to a project, e.g., https://secure.phabricator.com/project/view/1408/
2. Click manage - see https://secure.phabricator.com/project/manage/1408/
3. Click "edit details"
4. Select "visible too"
5. [ note that the current policy is "custom policy" ]
6. Select "custom policy"

Yeah, persistent details would be helpful. My best guess at repro steps from the screenshot is:

If you don't mind, can you provide specific steps to reproduce and attach actual photos to the task? External links can change/etc and we'd prefer to have a complete record. Thanks!

I suppose that'll work for maniphest/paste/projects/etc., but the most recent case I had in mind involved dashboard panel edit policies... :/

I don't anticipate ever building this. It would take months and only partially address a very narrow range of primarily operational use cases.

There's also mode=recurring... all these seem to do is change different default options on the form. Should I try to implement form edit engine support for this @epriestley? Would you be prepared to review it?

I did some digging through the source code and found PhabricatorCalendarEvent::initializeNewCalendarEvent which does this:

if ($mode == 'public') {
  $view_policy = PhabricatorPolicies::getMostOpenPolicy();
}

@epriestley: thanks for the thorough consideration.

I believe we generally have an acceptable way forward here, at least in broad strokes, now so I'm going to close this out since I think it has served its purpose, but feel free to file a followup if things stall or you run into trouble.

Given the feedback from @Krenair / @MZMcBride, I'm going to shelve this for the time being since WMF is the major driver for it but it looks like some mixture of contentious/low-priority/hypothetical, and even if consensus/priority does develop from WMF I'd like to wait for EditEngine and make sure the problems survive the new capabilities it introduced.

(Oh, the WMF task got a similar token so it's presumably an objection to the control.)

I'm not sure if that thumbs-down is an objection to introducing this policy control or an objection to my hesitance to introduce this policy control.

On the Wikimedia side, looking at https://phabricator.wikimedia.org/T1178, I see almost no support or consensus for this feature. Restricting open editing is in some ways antithetical to Wikimedia's values (we try to be as open as possible) and there are a lot of other issues with Phabricator that are higher priority for us.

Looking deeper, I'm sort of wondering if we actually need this. Are you seeing (or still seeing) issues with this?

In T6502#157400, @epriestley wrote:

This is probably happening tomorrow, unless I am just toying with everyone's emotions.

This is probably happening tomorrow, unless I am just toying with everyone's emotions.

In T8434#151667, @Krenair wrote:

I think one of the issues was people making a public task, and then deciding they should change it to security, but not having the permissions to do so?

You can now customize "Create" forms and prefill (and, optionally, lock) their policies. See:

T5046 has a specific case of this causing particularly questionable behavior when doing HTTP clones -- since the object is totally hidden, you don't get prompted for credentials.