This change appears to have resolved the issue in PHI1954.

Leftover Raw Members

Repeatable read is required if statement based replication is used - if row replication is used - repeatable read is no longer a requirement for replication consistency...

Probably related: According to https://phabricator.wikimedia.org/T261642, it seems that when leaving a project, phabricator leaves behind some cruft in the form of materialized memberships for milestones of that project.

@epriestley As perhaps an example of another use case, in my workplace we needed, amongst others, the following lists of Maniphest tasks:

1. assigned to the viewer, regardless of the author,
2. authored by the viewer, without self-assigned,
3. subscribed by the viewer, without (1) and (2).

(1) is obviously trivial (there's already a built-in query), but the other two seemed to require custom "NOT" filtering. Of course, (2) can be solved to an extent by using "Group by assigned", but it's not very convenient. Because I tend to self-assign most of the tasks that I create, the ones that I have assigned to other people quickly get visually overwhelmed by the large group of "Assigned to kerberizer" (not to mention that with my username this huge group tends to get in the middle of the list).

See https://discourse.phabricator-community.org/t/herald-rule-not-adding-auditors-to-commits-following-upgrade/3505 for one bug with this.

Remaining work:

D20947 does not implement "Author's packages" as a "Commit Content" field, nor as a "Commit Content (Hook)" field. The reason for this is that getting the modern authorPHID in both cases is somewhat complicated.

See T13478 for followup.

I'm also still able to reproduce this specific variant of things, so it looks like I was too optimistic about T13462 covering this in at least some cases.

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.

Can confirm this is fixed. Yay!

I believe T13462 resolved this.

We materialize some members into the milestone? This causes no real problems, but we shouldn't materialize members into milestones.

We predict the wrong set of members for the milestone when testing policies: we predict "no members", but should predict "exactly the same as the members of the parent project"?

We check the wrong edit policy when testing if you can create a milestone: we check the default application policy, but should check the parent project policy?

See PHI1492. After this change, the parent/subproject modes of the script in T10350 can be brought upstream safely, since they would no longer be destructive operations on membership lists. This wouldn't cover the "convert a project into a milestone" mode, but that seems less important.