I thought this was some kind of complicated mess with the regex on line 420, but it's actually an issue with this:

• Also move the Porter stemmer.
• Ran some search queries.

(Since a full implementation here will imply that removing a custom field from configuration may "unmention" an arbitrarily large number of relationships, and we can't easily do that inline or at display time, the ultimately implementation would likely include a more robust version of this script.)

In PHI1602, I proposed a script to "reset" mentions on an object. The use case this serves is:

If systems with no binary named python are reasonable to expect, and it sounds like they are, this is fine as-is. I've added you to Blessed Committers so you should be able to land this change yourself (check the project description for some guidance), or let me know if you run into issues. After this lands, I'll land a followup in arc anoid to test for a python3 and emit a friendlier error if it isn't present.

In jira 8.6.1 settings are now in:

• Administration → Applications → Application links

It's possible (and common) to write code that is both valid Python 2 and 3, like in this case.

This page intentionally has a no-Javascript, no-drag-and-drop upload form for users who use obscure Linux window managers that don't support drag and drop.

This is almost certainly fine, but I don't actually have this bleeding-edge far-future version of Python installed on my stock Macbook (macOS Mojave):

If you believe you've found a bug in Phabricator, please report it by creating a new thread on Discourse.

Last follow-up -- no, it was not a custom policy. The log of changes to the Project configuration show that the original setting for the edit policy was indeed "Project Members", which seems to indicate that Phabricator was incorrectly preventing new members from editing the Project.

I was unable to reproduce this with a new Project, which makes me suspect the problem isn't a bug in Phabricator. I suspect the Project that was not editable *actually* had a Custom policy with specific users added to it, rather than a "Project Members" policy.

I ran into this issue today as well. The context was a Project created by a regular user a few months back. He added himself and one other user to the Project. He also set the edit policy for the Project to be "Project Members." A few months later, a couple of other users were added to the Project, but neither of them could edit the Project (all links in the "Manage" UI were disabled, can't create milestones, etc.). The users who were in the group when the edit policy was set were still able to manage the group. One of them had to change the edit policy because the newer members of the group could not.

See also PHI1594, which wants:

See also PHI1579.

After 2.5 years of not upgrading because I didn't want to lose phabot, we finally have (went fairly smoothly yay). Is there a slightly less terse explanation for how I can do as @joshuaspence said? Or at least a pointer to the right documentation for such a project?

We use the bot quite heavily at my company. Is there anything stopping me from just copying the deleted code into a libphutil extension and continuing to use it? Really, PhabricatorBotLogHandler is what we care about most.

Can confirm this is fixed. Yay!

I believe T13462 resolved this.

there is no way to bin/host query against the set of instances using a particular repository shard service

In D20927, I implemented a policy rule like this:

Update Almanac definitions for all instances not on the paired db023 shard.

PHI1566 is resolved narrowly. These cleanup steps still need to happen.

(Updating addresses with bin/host query leaves the service address cache dirty (the "mutable structure cache" via PhabricatorRepository->getAlmanacServiceRefs()) so it should be followed with bin/cache purge --caches general.)

I'll flesh this out more later, but the move away from db123 = repo123 shard pairing, plus bin/host query using mysql makes it difficult to directly query instances using a particular repository service.

Minor issue that should be looked at during service sync arising from improved validation elsewhere:

I'm deploying the new host now. We just crossed a release so I'm going to manually restore it to 72f82abe07 once it comes up (see also T13359). Then, I'll resynchronize instance services for active instances.