Forum Discussion
how to flag tasks in a plan which have a relationship with a specific section
I'm surprised that your filter method "seems to work most of the time." It would certainly bog down in any complex project, where pure "waterfall" logic is rare. For other tricks or techniques, here are three views generated using the free edition of BPC Logic Filter. (Disclosure - I developed the tool for my own use; others license it from my company. Reference to commercial add-ins is discouraged here, and I show it only because this functionality is free and available to non-registered users after the trial expires.) The first view is a highlight filter - using John's example - to highlight the predecessors and successors of the selected tasks (IDs 9-12). The second is a grouped arrangement of predecessors, selected tasks, and successors. The third ties the selected tasks individually to their predecessors and successors. Good luck. tom
I tried re-starting my machine and still have the same issue (filtered for <=12 and >=9
https://imgur.com/mLJZmUf
This is really odd.
How would you use the Marked or Numbered field? Would you have a test in there to see if the dependency contains items in a hardcoded range?
I'm not sure why it isn't working for you, perhaps there is some subtle artifacts of your more complex plan than the simple example I used.
I would simply use the Marked field in a highlight filter, nothing more. It looks like Tom has taken the process much further and If that gets more of the information you want, I'd go with Tom's app.
- There are a couple issues for the OP.
1. The filter is based on the "Predecessors" field, which is itself a string of characters summarizing an indefinite number of dependency objects. With only one number (i.e. no commas) in the field, Project easily identifies the sole dependency with a Predecessor task ID to be evaluated. With commas, a filter seems to see only the first element in the list, i.e. the 10 in "10,2." (A flag formula using the same criteria won't even see that, instead just seeing a text string.). The result therefore depends on the order of entry of the predecessors. I.e. "10,2" and "2,10" are logically identical, but they will be evaluated differently by both filter and flag.
2. Modifying the pedecessors string directly can be a little flakey. As a rule, it's better to delete, recalculate, and reenter the string, IMO. (Even better to do the same thing in the predecessors table.) I'd suspect the apparent flakiness of the highlighter update is related to this.