Page MenuHomePhabricator

Avoid the need to update Herald exclusion rules everytime a new team sprint project is created
Closed, ResolvedPublicFeature

Description

Current situation

We have numerous team backlog funneling Herald rules like this:

  • When all of these conditions are met:
    • Project tags include any of { #some_code_project1 | #some_code_project2 }
    • Project tags include none of { #team_parent_project | #team_sprint1_milestone | #team_sprint2_milestone }
  • Take these actions first|every time this rule matches:
    • Add projects: { #team_parent_project }

Currently, after creating #team_sprint3_milestone (as a direct milestone of the #team_parent_project) and not manually adding #team_sprint3_milestone to the "none" Herald rule and creating a task tagged with both #some_code_project1 && #team_sprint3_milestone, Herald will immediately remove #team_sprint3_milestone from the task and add #team_parent_project. Which is unwanted.

So in one sentence, we'd like to eliminate the need to define/edit none: #team_sprintX_milestone

Examples of the problem:

  • https://phabricator.wikimedia.org/T366388#9852123
  • https://phabricator.wikimedia.org/T367355#9887098

Original task title

"Develop a custom herald condition for maniphest tasks: "projects include any subprojects of ___ ""

Original task description

This would allow us to have herald rules that automatically add the parent project when any sub-project is added to a task.

The main benefit is that we wouldn't need to manually update herald every time a new subproject gets created.

Details

Related Changes in GitLab:
TitleReferenceAuthorSource BranchDest Branch
Create Herald task condition to have Projects include their subprojectsrepos/phabricator/phabricator!62aklapperT144041heraldSubprojectsNonewmf/stable
Customize query in GitLab

Event Timeline

mmodell triaged this task as Medium priority.
mmodell moved this task from To Triage to Misc on the Phabricator board.

Reviving this as the apps teams have reminded me that this would be far easier than asking me (or other authorized users) to update their Heralds every few weeks as they create sprint/release boards. :)

I took a shot at implementing this last night and it turns out to be a lot more difficult than it should be. It would require loading of all sub-projects for all projects on all tasks which is difficult to accomplish and inefficient. This would lead to significantly more processing time every time a task is submitted or edited.

At this point I am not sure if it's worth it, though admittedly, it would eliminate a significant annoyance.

Thanks for taking a stab at it! Bummer that it's difficult. To clarify, this is a suggested approach to a core issue of "it's annoying to manually update Herald rules all the time." Using subprojects seems like an elegant solution, but others (albeit less elegant) could include

  • Granting Herald access more liberally (obviously has its own problems, which might beget subtasks if this were pursued, e.g. "separate Herald access from admin access" or "lessen impact of Herald on server load" etc)
  • Targeting projects by naming convention/wildcard (e.g. iOS starts all projects with "iOS-app-")
  • Something else?

An approach that leverages an existing nesting feature like subprojects is probably still best despite the challenges, but I just wanted to draw attention to the distinction between "problem" and "solution." :)

Bumping to give this some love again, after spending a few weeks with @Aklapper on the Phab Help talk page: https://www.mediawiki.org/w/index.php?title=Topic:Viio4deewlasrmp2

I imagine this is still difficult, but if @mmodell 's recent request to "keep the feature requests coming" can give fuel to this, you've got a fan in me. :-D

Annual revisit to this thread! I don't suppose anything has changed, but this is something a team requested again today. The use case was that they make a sprint Milestone every two weeks, and forget to update Herald.

Fanning the feature request flames... :)

Aklapper lowered the priority of this task from Medium to Low.Nov 11 2023, 12:58 PM
Aklapper changed the subtype of this task from "Task" to "Feature Request".
Aklapper edited projects, added Phabricator (Upstream), Upstream; removed Phabricator.
Aklapper renamed this task from Develop a custom herald condition for maniphest tasks: "projects include any subprojects of ___ " to Develop a Herald condition for tasks to have Projects also include their Subprojects.Jun 15 2024, 1:06 PM

I believe this is way too complexwrong to implement via an "include any subprojects of..." second-dropdown option for "Project tags" - it would imply creating another CONDITION_INCLUDE_* in the codebase which is not supposed to be generic (means: should apply only to project tags).

For anyone not having access to Herald: Screenshot at https://commons.wikimedia.org/wiki/File:Phabricator_Herald_Rules_for_Maniphest.png

Looking at usage via SELECT fieldName, fieldCondition FROM phabricator_herald.herald_condition WHERE fieldName LIKE "projects%" ORDER BY fieldName;, 92% use Project tags. Also, SELECT CONCAT("https://phabricator.wikimedia.org/H", c.ruleID), c.fieldName, c.fieldCondition FROM phabricator_herald.herald_condition c JOIN phabricator_herald.herald_rule r ON r.id = c.ruleID WHERE r.isDisabled = 0 AND c.fieldName LIKE "projects%" AND c.fieldCondition != "none" AND c.ruleID IN (SELECT ruleID FROM phabricator_herald.herald_condition WHERE fieldCondition = "none"); shows that apart from one rule using Project tags added, all rules setting at least two conditions (one of these conditions being none) use the Project tags option.

Thus I'd rather not change the existing implementations for Project tags, Project tags added, Project tags removed (also for performance reasons) but implement a separate and dedicated dropdown option instead.

Proof of Concept code:

1<?php
2
3final class PhabricatorProjectTagsIncludingMilestonesField
4 extends PhabricatorProjectTagsField {
5
6 const FIELDCONST = 'projects.milestones';
7
8 public function getHeraldFieldName() {
9 return pht('Project tags (incl. their milestones)');
10 }
11
12 // If some project PHIDs are milestones, also return their resp parent PHIDs
13 public function getHeraldFieldValue($object) {
14 // get project PHIDs which currently have an edge with our task $object
15 $project_phids = PhabricatorEdgeQuery::loadDestinationPHIDs(
16 $object->getPHID(),
17 PhabricatorProjectObjectHasProjectEdgeType::EDGECONST);
18 // get only those of our current projects which are milestones
19 $current_milestones = id(new PhabricatorProjectQuery())
20 ->setViewer(PhabricatorUser::getOmnipotentUser())
21 ->withIsMilestone(true)
22 ->withPHIDs($project_phids)
23 ->execute();
24 // pull the parent projects of our milestones
25 $parent_project_phids = mpull($current_milestones, 'getParentProjectPHID');
26 // fake return that our task has _all_ those projects set as edges
27 return array_merge($project_phids, $parent_project_phids);
28 }
29}

WARNING: Obviously this very concept only makes sense in connection with "include none of $parentproject+itssubprojects". Using it not with "none" may have unintended effects...


Note to my phuture self: To find Herald rules using the current/previous conditions construction, use SELECT CONCAT("https://phabricator.wikimedia.org/H", c.ruleID), c.fieldName, c.fieldCondition FROM phabricator_herald.herald_condition c JOIN phabricator_herald.herald_rule r ON r.id = c.ruleID WHERE r.isDisabled = 0 AND c.fieldName LIKE "projects%" AND c.fieldCondition != "none" AND c.ruleID IN (SELECT ruleID FROM phabricator_herald.herald_condition WHERE fieldCondition = "none");

Aklapper updated the task description. (Show Details)
Aklapper renamed this task from Develop a Herald condition for tasks to have Projects also include their Subprojects to Avoid the need to update Herald exclusion rules everytime a new team sprint project is created.Jun 27 2024, 7:32 AM
Aklapper edited projects, added Phabricator; removed Upstream, Phabricator (Upstream).

brennen merged https://gitlab.wikimedia.org/repos/phabricator/phabricator/-/merge_requests/62

Create Herald task condition to have Projects include their subprojects

Deployed by brennen on 2024-08-20, thus resolving.

Followup note to myself: Now try with a first team that wants to be a guinea pig

@MusikAnimal: Would your team be interested in trying this? :) (Basically: create a Herald rule which is a copy of H260 and replace the whole "Project tags include none of" with the new "Project tags incl their milestones (use with None only): Community-Tech", and disable H260)

@MusikAnimal: Would your team be interested in trying this? :) (Basically: create a Herald rule which is a copy of H260 and replace the whole "Project tags include none of" with the new "Project tags incl their milestones (use with None only): Community-Tech", and disable H260)

Absolutely! Do I need to create a new Herald rule though? Why can't I change the existing one to use "Project tags incl their milestones (use with None only)"?

Absolutely! Do I need to create a new Herald rule though? Why can't I change the existing one to use "Project tags incl their milestones (use with None only)"?

@MusikAnimal: Heh, nah, it's just me not being totally convinced of my programming skills. :D
Alright, I have edited H260.
Screenshot in case I need to restore the previous setup (restore the second condition, which I removed after adding the third condition):

Screenshot from 2024-08-31 12-13-23.png (637×1 px, 171 KB)

New H260 looks like this:
Screenshot from 2024-08-31 12-15-17.png (387×1 px, 88 KB)

Crossing fingers...

@MusikAnimal: A few months later, based on your experience, would you say that this all works as expected? Asking as you most recently edited H260, and I wonder whether to also use this Herald "incl milestones" condition in other teams' similar Herald rule setups.

Note to myself, probably transfer this to a separate ticket with T144041 as its subtask: