The Project tool allows revisions and tasks to be organized.
Tue, Jul 21
Feb 28 2020
@epriestley As perhaps an example of another use case, in my workplace we needed, amongst others, the following lists of Maniphest tasks:
- assigned to the viewer, regardless of the author,
- authored by the viewer, without self-assigned,
- 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).
Feb 3 2020
Jan 29 2020
Jan 24 2020
Jan 23 2020
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.
Jan 21 2020
Jan 17 2020
Jan 16 2020
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.
Jan 13 2020
If you believe you've found a bug in Phabricator, please report it by creating a new thread on Discourse.
Jan 8 2020
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.
Nov 26 2019
Can confirm this is fixed. Yay!
I believe T13462 resolved this.
Nov 19 2019
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?
Oct 31 2019
Oct 25 2019
Oct 22 2019
Oct 10 2019
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.