Yep, that worked. Thanks.

So this actually in Phurl (not clear from the link) and not valid itself because Phurl is a prototype?

Sure, so it's not the idea of consistency here that's the issue, it's which existing implementation to actually go with, and you're not convinced Maniphest's one is the way forward?

We generally don't want to be in the business of spending time debating design opinions

This is particularly problematic in the UI when you need to revert the first change to a task since creation - there doesn't appear to be any way to find the initial assignee of https://phabricator.wikimedia.org/T129128#2105237 for example

Also, view the edit history: https://phabricator.wikimedia.org/T128679

It's mainly the projects that I want to see as well. Although there has been talk of priorities etc. as well

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

The link is to "RobH changed Tabs from codfw206eqiad207 to codfw206eqiad207esams208ulsfo209." specifically

"RobH set Tabs to ." is also a bit weird

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();
}

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?

User (or project) based policies produce useful error messages if you can't view an object:

I can't examine any of those either, but I can reproduce the bug on what I think is a relatively up-to-date production installation.
If it helps, this URL was linked from https://phabricator.wikimedia.org/project/profile/1090/#17189 (edit policy entry)

In T9869#146119, @chad wrote:

Please file bugs with more information, specifically steps to reproduce. See Contributing Bug Reports.

this may be covered by the spaces system?

In T8434#121407, @20after4 wrote:

Regarding editing policy on a task: I'm not sure how to do it but I think what might be desirable is that the task author has some sort of limited ability to comment on a 'security' task but not really edit it in any significant way after submission.

In T8376#120442, @epriestley wrote:

I think that there should be a separate visibility policy for the description page of a space.

Can you walk me through this a little more? I'm hesitant to add complexity, and it seems like having "Can See Space" and "Can See Objects in Space" as separate policies may be confusing. Why is it important/desirable that users be able to see, e.g., a "Procurement" space if they don't have access to it?

I think that there should be a separate visibility policy for the description page of a space. I think that the text shown for visibility policies at the tops of objects should be clarified when in spaces. I can't think of any other tweaks right now other than the things discussed in T8434, which are more major. I think here's already some consideration about how objects in spaces should look style-wise somewhere?

Noticed that S2 did not get linked in the email for @epriestley's above comment, is that a bug?

Edit: Ignore this. Your quote formatted strangely in my email client and I thought you were saying that Spaces do allow that. Never mind.

In T8493#119801, @qgil wrote:

the intention is that Spaces will allow us to deprecate our own local remedies, one step at a time.

In T8493#119789, @epriestley wrote:

I think the difference with the Wikimedia Procurement use case is that tasks with files are created via email (i.e. a provider sends an offer to an email address).

I hadn't thought about this yet, but I think we'll probably just let you assign a Space to each application email address, so everything to procurement-bugs@ would default into the procurement space and everything to normal-bugs@ would go into the default space.

(We can implement a !space mail command, too, if there are automated or more complex cases here where the same address might receive mail destined for multiple spaces.)

And the ability to actually see custom policy details such as the one for our "Can Edit Task Projects" Maniphest application policy please.

In T8434#118741, @aklapper wrote:

In T8434#118719, @Krenair wrote:

In T8434#118707, @epriestley wrote:

• The original reporter can not see the task or any work done on the task, only the separate discussion on their original report. This allows security response to be separated from communication with the reporter.

That does not sound desirable to me in our context

It can be desirable. Being able to exclude reporters/ commenters on certain tasks from certain updates is very useful for handling procurement requests (such an RT feature was used at least by Wikimedia's Operations team).

In T8434#118738, @epriestley wrote:

How would you like the flow where you give permission to new users to work? In T4411, @chasemp expressed some concerns about using CC/Subscribers for this (particularly, that users can add other users to CC). Do you share those concerns, or is adding users to CC to give them rights satisfactory for you?

Fine with me personally, that was the system in BZ. I do wonder what Chris thinks about this now though.

In T8434#118721, @qgil wrote:

In general I also like the concept of "hard spaces", simpler to understand
and to protect.

There is this "misuse" case that hard spaces would about: Security team
member leaves the team for some reason while staying as a regular
contributor.... but keeps access to old tasks that he authored. It is
simpler if you are either in our out.

In T8434#118707, @epriestley wrote:

• The original reporter can not see the task or any work done on the task, only the separate discussion on their original report. This allows security response to be separated from communication with the reporter.

That does not sound desirable to me in our context (unless the Nuance entry was basically just a special task, where we could have to option to continue as normal while including the reporter), what do you think @csteipp?

Objects which support spaces get a new "Space:" control on their edit forms.

I don't think I know enough about Git and Phabricator's internals to do this.

I checked the email quickly, but clearly not well enough.

Just fix the caller in PhabricatorSubscriptionsUIEventListener.

Creating restricted-join projects (or perhaps duplicate projects so one can be used for ACL, and the other for grouping objects) on Wikimedia will have to get a lot harder unless this can be fixed.

Google Chrome, Ubuntu, trackpad.

Also if you press 'Custom Policy' for visibility below the title of things like Pastes, it doesn't provide a very useful message.

Yeah I wasn't sure whether to generalise this or open a new task. In BZ we'd have to open new bugs, but here we can just add extra projects... :)

We ( Wikimedia ) see this problem (lack of conflict detection) often in Maniphest, but it probably applies to more than just these two projects... See https://phabricator.wikimedia.org/T78236

Yep, that's what I meant. Thanks @epriestley

Nope, that's right. I can reproduce the issue here.

Ah, it was edited in after the initial comment. Sorry about that.

Those show up fine in my gmail actually. I saw this on https://phabricator.wikimedia.org/T86160#962778

This got fixed in rP2dea110 it seems.

In T4968#87010, @epriestley wrote:

• Change the prototypes on PhabricatorEdgeType for getTransactionAddString(), getTransactionRemoveString(), getTransactionEditString(), getFeedAddString(), getFeedRemoveString(), and getFeedEditString() to take $object as the first parameter. Change callsites in PhabricatorApplicationTransaction to pass $this->getObject().

In T4968#87010, @epriestley wrote:

• Convert PhabricatorEdgeConfig::TYPE_OBJECT_HAS_SUBSCRIBER and PhabricatorEdgeConfig::TYPE_SUBSCRIBED_TO_OBJECT to Phabricator...EdgeType classes. D9839 has an example of how to apply this modernization.

Looks like this was done in rP7c2a7

Shouldn't DiffusionCommitHasRevisionEdgeType and DifferentialReviewerForRevisionEdgeType have get*String functions? Is this what is causing the Herald entries on https://secure.phabricator.com/project/edit/1308/ ?