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.

See PHI119. PHI1128 is probably another copy of this, which suggests it's still a real bug.

Simply adding two position rows on the same board doesn't reproduce the exact same error, we get this instead: [Unable to find...]

Make drops when a column position already exists go through.

See PHI119. This may describe a race fixed by chaos reduction in T13054. PHI1128 is probably another copy of this, which suggests it's still a real bug.
See PHI208. This describes a performance issue on workboards with very large numbers of tasks.

Currently, expected behavior.

More or less resolved previously in D14918.

D19549 added Spaces support to projects.

Mooted by D20263, which removes the rarely-used drag functionality from global lists.

To summarize the state of the world here:

In the future, when a board can be ordered/grouped by author or assignee (or maybe custom fields), what should dragging a card within a column do?

I'm going to start here, and implement this proposed rule, which I think is the simpler and more intuitive of the proposals:

This isn't an actionable task. It covers too much ground, describes too many features, and most of it lacks compelling use cases.

No plan to continue on this?

Thanks, I wasn't able to puzzle out the reproduction instructions on the original report since they didn't mention actually making any policy changes.

Okay. For the sake of 100% clarity it would be nice if the timeline story did show why the action was taken as it isn't immediately clear (unless you've read the documentation of course) why it was removed.

I'll make a note on T12455, but we might be able to render this timeline story more clearly, e.g. "X added project Y (which automatically removed Z, a subproject)" but I think this is likely fairly natural/obvious in most cases and I'm not sure if it's trivial to completely explain in the timeline.

Ah, that would certainly explain it. Sorry for the noise - when entering this I did wonder if I had missed something as it didn't make sense that a name collision would be able to cause this.

"Plasma on Wayland" is a subproject of "Plasma".

I don't plan to support this because it makes improvements to milestones which depend on them being ordered ("move to next milestone", automatic date ranges, etc., per above) more complex to implement or use. All use cases here seem to be addressed by "use subprojects instead of milestones", especially after T11036. I'll make the ordering adjustment described above.

This task is a giant mess with pretty much no remaining actionable use cases. See T13074 for plans. If you want some use case here included in that, file a description of your problem via support pact.

See also PHI347.