@epriestley: The main motivation was that we had been maintaining these as cherry-picked patches on top of phabricator core, which required constant rebasing. It was ridiculous and not even necessary. Eventually I figured out that phabricator doesn't care if the auth providers live in an external library. I sure wish I'd figured that out in the beginning, it would have made things a lot easier ;)

@epriestley: FWIW I don't mind doing the work, and I would love to throw away all the hacky stuff we have right now.

In T9860#146391, @epriestley wrote:

I believe if you include a transaction which sets the CCs to the current CCs, it is guaranteed to run after any personal rules and will entirely undo the effects of any sneaky rules anyone might write.

The problem is, we add a rule that includes "subscribers can view" to the policy - so even if it prevents mail from being sent, by the end of the herald processing, the user has gained 'can view' on the private task (by way of being CC'd) even though they should have never been able to CC themself in the first place.

In T9860#146319, @epriestley wrote:

What are you doing which can't be covered by Herald?

→ →

The same behavior happens here as well. Typing watch causes the suggestion to be hidden, then adding d to make watchd results in the suggestion reappearing.

I guess having it exist on github is good enough.

Isn't this one resolved now, thanks to object policies?

Superseded by D13939

@epriestley: Sounds good to me. Agreed that object policies are working well, I've already replaced the hacked-up policy rule with your Subscribers rule and it's working as expected.

Since projects are the go-to for labeling tasks, showing projects in workboards sounds like a high value, however, it could look pretty noisy if all projects are shown.

remove my debugging call to phlog().

Very good suggestions, and I will look into running diviner on our codebase, to see how that looks. It might be as good or better than what I was imagining in my previous comment. And phabricator code search is definitely a nice and desirable feature. That is probably a lot more valuable than search-engine-friendly diffusion.

I think the situation is simply that source is preferable to nothing, and is mainly useful when there is a lack of documentation, which is the case with a large portion of source code. The wikimedia task covering this topic is referring to our own code, which doesn't use diviner and is documented on-wiki but only sporadically. Obviously this isn't anything we expect the upstream to be concerned with, I was simply cleaning up one of our workboards and it sparked a few thoughts on the subject.

I'm not sure if this is a good idea or if I'm just talking out my ass here, and it certainly isn't high priority by any means. But with that said:

At wikimedia we would prefer to allow search engines to index our code (https://phabricator.wikimedia.org/T76992), however, it does seem like it might not be that useful if the spiders can't make sense of it. Is it really likely to generate a ton of load without generating useful search results?

The biggest challenge for 3rd party apps, from my perspective, is the rapid rate of development in the upstream. Keeping up with the unstable api changes is definitely a challenge for anyone who isn't closely following Z1336: General Chat and watching the upstream commit log regularly.

A keyboard shortcut to focus the comment box in maniphest would also be useful.

phabricator search shortcuts are brilliant, however, maniphest lacking keyboard shortcuts is a real shortcoming, IMO.

@epriestley: thanks for the heads up

The form templating stuff sounds really cool.

Reduce PolicyRule Hackiness + Support Templating Custom Fields would probably serve our needs well and it would also be useful, I'd imagine, for other installs to implement their own custom access controls.

When I scale the text size up a bit, I get a weird left margin of blank space next to the page content:

Although I like the name Phabricator, and I am not so fond of the logo, I don't think anyone should fault the upstream for their priorities, and the fact that you need to keep your options open, to maintain design flexibility, that is totally reasonable.

@chad: No, we just want a way to nuke the "eye" logo.

So the current behavior is exactly the opposite of what I expected - changing the "logo" changes the "PHABRICATOR" wordmark in the header but leaves the eye image. Hmmm... I would think it better to keep phabricator but replace the eye.

In case it's helpful: Here's a real-world use case: custom policy rule I wrote to allow "Subscribers of this task" WMFSubscribersPolicyRule

In T8434#118779, @epriestley wrote:

I'd ideally like to do this via T4411, but we could also meet halfway via T5681: that would let you write a "subscribers to this object" rule instead of needing to write a "subscribers to [explicitly, type in this object with your keyboard]" rule, which might simplify things a little bit, at least. (I assume the "type in this object" part is sort-of-automated via secret magic right now, at least some of the time, so maybe this is only very slightly nice-to-have.)

I would personally pony up a couple of hundred at least, just for all the times that @epriestley has helped me out with responses that were detailed and incredibly helpful, without any visible signs of annoyance. :)

@epriestley: Ok, thanks for clarification. I will refer people here if it comes up again :)

I can confirm that it does not work, at least with "select" fields.

@epriestley: What do you think we should do, abandon the diffs or keep'em? If you don't want them it's ok, really! (also no rush to respond, this is no longer an urgent priority for me so don't spend too much time thinking about it, I know you're busy)

@epriestley: This seems entirely reasonable and as usual you've gone out of your way to be helpful. Thanks! Sorry for beating the dead horse on this one. I will look into doing the config with php instead of yml -> puppet (ruby hash) -> json

@epriestley: as a form of bribery, I offer this random meme I googled for just now. it took a lot of effort, obviously.

In phabricator.wikimedia.org/T548#1222093, @matmarex wrote:

In phabricator.wikimedia.org/T548#1221432, @20after4 wrote:

How can it be considered upstream bug exactly? Sounds like an upstream feature request to support ordering by some other method. Or we just fix our puppet setup to somehow force the correct ordering.

I consider it a bug that the configuration relies on the order of a JSON object, while JSON objects are explicitly unordered. http://json.org/

So some code is written assuming that the linked accounts will be unique per provider because the configuration ui implies that there is only one linked account per provider. This isn't enforced by the database, however, and it's not really well enforced anywhere.

How about using tab completion to trigger the popup so that it doesn't have to be intelligent about when to pop up the list of names.

@epriestley: This is now tested against mediawiki.org and both patches should be ready for review. I believe I have addressed all of your concerns and suggestions; everything should be good to go as soon as you have a chance to review.

FYI: I'm still working on this. I've addressed all of the feedback in D9202 but now there is a bug somewhere.

woot! Thanks @epriestley, you've been incredibly helpful as always.

project.create method merged.

@epriestley: I might be able to implement this or at least take a stab at it.

@epriestley: this sounds like pretty solid solution to me.

Code published on github: https://github.com/wikimedia/phabricator-extensions/blob/T95/ProjectPolicyEnforcerAction.php

Ported to a custom herald action: P1204

see @epriestley's exceedingly helpful reply to T5571 for a starting point. I will try to expand on that and make it into something a bit more general for documentation purposes.

Thanks Evan for the thorough response.

@epriestley Can you take a look at P1195 for sanity checking purposes and let me know if this is a valid way to do it?

@epriestley How much is really remaining to do here? Assuming we don't care about audit (we'll only be using maniphest initially) is there any way to make maniphest attachments private without waiting for T4896? Is this something we could contribute patches towards? It looks like this is the last remaining blocker for Wikimedia to go live with Maniphest replacing Bugzilla and RT.

@aklapper why did you mark this as "needs triage" ?

So is this one fixed now?

D9321 resolved this

I've updated both D9202 and D9203 to be much more robust and configurable. This task should be nearly finished, just pending code review.