I've implemented the sudo approach at some point - P2016 - and I think it worked alright.

We would also like this behaviour, and currently use a workaround to accomplish it (which is why we never came here looking for a fix). We created a custom Create Task form that sets the default view policy to include subscribers.

This is now better tracked in followups:

In my personal opinion adding a CC that cannot see the task is an error and like this should be treated, meaning ux should just report as error when try to save it. It is important that ux reports it since it can be overlooked by the person changing the task.

Changes for T9365 might cause some API changes (Moving lint/unit excuses from diff properties to harbormaster.sendmessage), so might be worth doing them around the same time.

@oujesky thanks for the git link. I was able to get the arc patch command working in the meanwhile with these changes.

We managed to solve this on our server setup using Linux ACL (I had help from someone in IT). Here are roughly the steps we took

Oh, I see I already made that suggestion! I am nothing if not consistent.

In the meantime, we could maybe do the following:

Daemons now do both reads and writes, and may need to do reads and writes which are nonlocal in cluster configurations. So I think the pathway forward here must be to expose local disk storage over HTTP with S3-like raw APIs (read, write, delete).

For completeness, T9953 / D14735 cleaned up an obscure rough edge on a narrow range of Git versions.

Broadly, if comments have the new "stacked action" UI (an "Add Action..." dropdown, allowing you to take multiple actions at once), the expectation is that they support the new drafts too. This includes Maniphest at HEAD.

I've marked D14637 as fixing this.

This is fairly straightforward but blocked on T9132, which is prioritized elsewhere. This is likely to be completed adjacently with T9132 anyway.

In T5554#134045, @jbeta wrote:

To make it still work out of the box with most potential users of insteadOf, we could use either command depending on git version if you think that's worth the hassle.

Implemented this approach in D13998.

In T5554#133958, @chandru wrote:

D13983 breaks on users running RHEL6. There git version is 1.7.1 and git 1.7.1 does not support --get-url option for ls-remote.

In those rare cases when I have to deal with "old version causes headaches, nev version is not avail everywhere", I put handlers for old and new in place, with handler of old way spilling out warnings that "old version causes headache and I don't care anymore about it, use new".

Thanks @epriestley. RHEL6 is still widely used, and even the latest update on that line carries only git 1.7.1. So if we need a new version of git, its installation becomes a messy business with either custom / rpmforge-extras repo or do compile/install. Would prefer if we can keep the 1.7.1 support around.

no one has ever reported an issue with an old version which we could not trivially resolve

It looks like --get-url was added in early 2011:

D13983 breaks on users running RHEL6. There git version is 1.7.1 and git 1.7.1 does not support --get-url option for ls-remote.

Those were all the cases of parsing git environment-dependent output I could find in arc (unless built-in formats like git log --format=medium are susceptible to git-config/localization/future change, which I doubt).

In T5554#133477, @epriestley wrote:

I think this tactic (re-run the command to figure out the error) is a really fragile one and would be very hesitant to pursue it over requiring users to install locales, but agree on this otherwise.

Yes, it would be a desperate measure with a lot of problems of its own.

A lot of the practical cases here are resolved, but the root problem still exists. Basically, the core issue is that an object can say:

the command has potential side effects, or the time of execution is important, and cannot be simply re-run under LC_ALL=C.

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

(Sorry I hadn't seen T7339, certainly makes my last comment mostly redundant. Perhaps the tasks can be merged?)

system default locale

Also not mentioned here is cases where we phutil_passthru() some command like git push. These would be best run in the system default locale, since we echo the output to the user -- unless we also parse it. I think we never do this right now, but I'm not 100% sure.

See also T7339, which is somewhat related.

I think the current Phabricator/Arcanist handling of locales, at least on Linux, is wrong. The LANG environment variable has lower priority than the family of LC_* variables, as per POSIX §8.2:

T9132 has a tangential interaction here: Differential saves action state, as well as comment state, and it would be nice to do this generally. After T9132, any generalization here can reasonably also persist action state in a general way.

(This is a bulk edit test.)

@epriestley: this task being fixed might be an easier solution than writing our own Doorkeeper integration (as discussed on Conpherence today). I already have an application that receives feed data via POST; can I help test this change so we can get it merged?

I have this working functionally, but the UI is still an atrocious mess. Probably have something ready tomorrow.

After mulling this over for a bit while dealing with other stuff, I'm pretty convinced that the general purpose infrastructure in T5166 is the way forward here, so my plan is to move forward with that.

This appears to work to undo a status change batch edit:

I think fixing this is basically removing the unique constraint on the "slugs" table in Phriction, and then using application logic to make sure that there can be only one active page with a given slug at any time.