Since this change is highly controversial from the opinion of the glorious Evan, I would like to propose to introduce a flag, like this one:

You can tag more than 3 projects using another method.

Maybe I can propose to control this new behavior by a new method:

For the records, Wikimedia has a downstream custom patch written by 20after4 in https://phabricator.wikimedia.org/rPHAB042685bdf63705ff527a04f4987bdb70209bbe69

Feel free to mark as resolved and thanks for this info

There's no difference between them - they use the same controller.

I will add a description

Don't try to steal this Task to Dylsss, who proposed a very nice patch for this.

FWIW even in the case the milestones are strictly ordered, it's incredibly inconvenient to sort out a situation where you need to add one to the middle of the list - forcing the user to rename a bunch of them to get things straightened out.

In T15082#2028, @golyalpha wrote:

epriestley was very much against this idea but wikimedia's users loved it.

Do we have epristley's reasoning as to why he was against this? Might help in deciding about including this patch in Phorge.

I mean, is this related to we.phorge.it?

@valerio.bozzolan Thanks for the feedback and sorry for the late response. I must admit that i forgot how we eventually fixed our issue, i only recall it was more about "avoid the issue" and less about "fix the issue". I also completely forgot about this Maniphest. Hence, it is OK for me that it is closed by now. sorry for not taking care about this earlier.

Thank you again for your question. Sorry if I start marking this as closed since currently this specific Task with this title is probably not implementable as-is. We have some approaches, but without much feedback from the original poster and from other users it's very difficult to do something concrete that do not impact other workflows.

This is the very same of T15147: Prefill tags when user opens new task form in new tab from workboard column but specifying also the Column PHID.

(I agree that internally, the Herald rule should be saved as a Global Task-based. And I agree that it should be easily added and edited from the Workboard. I think that, in the future, this still need the Project Tag to be saved internally - as a kind of Object rule - so that, in the future, it will allow a more efficient query to find all global Herald rules without a Tag + all global Herald rules that are assigned to a Tag where that Tag is IN the list of Task's Tags.)

@rraval Could you or someone else verify that a project that is made visible only to Administrators still shows up when a user opens the search selection list on the Subscribers field? And is this considered to be a bug or a feature? Of course i can set up a new Task for this if that makes sense.

Is this related to Phorge itself?

Please feel free to re-open, adding something in the description :)

Kind how?

If the users want to use milestones instead of subprojects, can they not change the language settings to Pirate English or something and go from there?

Also, this is fairly similar to T15082. Having Epics would probably also resolve that.

I feel like the idea behind milestones being strictly ordered is from the viewpoint that milestones are sequential "events" that happen in development one after another in a given order.

The original discussion in T12144 is kinda convincing to me, although it's mostly convinces me that the term "milestone" doesn't match these objects.

@avivey Thanks a lot for the hints. I will take a look at the Spaces. That sounds like it could be helpful for our purposes.
@rraval Could you or someone else verify that a project that is made visible only to Administrators still shows up when a user opens the search selection list on the Subscribers field? And is this considered to be a bug or a feature? Of course i can set up a new Task for this if that makes sense.

(Regarding the original task description:)

But still it is worrisome that we can configure visibility only by Administrators, yet everybody can assign the project as subscriber... Maybe that is a bug ?

@rraval Right, i overlooked this setting. I managed to hide most projects from the Subscribers Search panel. We also have reduced the number of Projects to keep things more tidy.

@Higgs You should be able to Project → Edit Details → Visible To → Project Members. Does that do what you expect?

We use Projects for grouping users into teams. But unfortunately every user can see all Projects and assign them as subscribers to Tasks, regardless if they are members or not. Normally (in our case) Tasks are only relevant for users in the same project. Having the other projects displayed in the subscribers selection is unfortunate in this case.

Our instance uses a ton of projects as "groups of people that need to be notified", so we use project subscribers a lot.

Reordering milestones is convenient when you want to treat milestones as workflow steps rather than sequential numerical versions.

In T15082#2028, @golyalpha wrote:

epriestley was very much against this idea but wikimedia's users loved it.

Do we have epristley's reasoning as to why he was against this? Might help in deciding about including this patch in Phorge.

epriestley was very much against this idea but wikimedia's users loved it.

In T15043#1618, @20after4 wrote:

I didn't know columns could be deleted... I thought they were only ever hidden.

I didn't know columns could be deleted... I thought they were only ever hidden.

Expressing the desired behavior here seems difficult to fit into Herald.

• Level: Global
• Trigger: When a task's status is changed
• Action: Move the task to a different column X on project Y

The Herald rule should be project specific. If X happens then move task to Project->Column

In T15043#1258, @CSharp wrote:

Maybe the "move to column" rule should only apply if the task is already assigned to the project, if it isn't, it gets ignored.

In T15043#1256, @speck wrote:

Making this an object rule is not possible as it has to be a Maniphest Task rule, which do not support object rules.
My main reason to explore this, is that without column types, we can only create rules like this "If task status changes to complete, then move task into column DONE in Project A.". Which means we have to create this rule for every project. In the rule builder UI we would also have to load a list of all project boards and their columns, which could be quite a few. The herald rule doesn't know with which project a task will be connected.

Ah okay - I was thinking this would be a Project rule rather than Maniphest, which would allow it to determine what possible columns can be used in the rule/action definitions.

In T15043#1256, @speck wrote:

I think this will work out technically but it feels a bit nebulous to me, in that the rule isn't really clear about what it's doing as it's very dependent on the project workboard that gets triggered. For example some workboards might be roadmaps/planning and want to have columns for e.g. inbox, backlog, next_version, etc. but other workboards might be categorical in nature rather than planning and there would be no overlap between what column types exist on those boards. I think a solution revolving around Project-based rules should be investigated - for example is it reasonable/possible to have a herald rule on a project that says, "when a task on this project board changes status to: x, then move to column y"?

Making this an object rule is not possible as it has to be a Maniphest Task rule, which do not support object rules.
My main reason to explore this, is that without column types, we can only create rules like this "If task status changes to complete, then move task into column DONE in Project A.". Which means we have to create this rule for every project. In the rule builder UI we would also have to load a list of all project boards and their columns, which could be quite a few. The herald rule doesn't know with which project a task will be connected.

Ah okay - I was thinking this would be a Project rule rather than Maniphest, which would allow it to determine what possible columns can be used in the rule/action definitions.