An issue I'm running into is that labels that are useful on one board are not necessarily useful on another board.
e.g. on our "bug & feature requests" backlog board, we use t-shirt sizes and priorities as labels. These are:
However, once these cards are sent to our "Sprint Tracking" board, those labels aren't really relevant anymore, and we'd like to be able to have a different set of labels that can be quickly implemented on that board.
Initially, I thought I'd set up a rule that would convert each label to a custom field (so we could still see the t-shirt size & priority, but once they are on our "Sprint Tracking" board, those values won't change, so a custom field is fine); however, this doesn't really address the issue, as the labels are removed *after* the card is imported to the board, and so the label is still saved on the board. i.e. even though we won't ever use a "Sm / Med / Lrg" label on the Sprint Tracking board, because we *will* import cards that (initially) have these labels (which are then converted to custom fields), the label is still saved to the "Sprint Tracking" board's list of labels.
Does anyone have a good work-around for implementing board-specific labels?
I may have just come up with an idea that would address the issue: instead of implementing the "label to custom field" rule on the destination board, we could implement it on the source board.
As such, we could use the keyboard shortcut to assign a label, but assigning the label would trigger a rule that would replace the label with the equivalent custom field. That way, when the card is shared to another board, there is no label, but the info is preserved.
Haven't tested this yet, but I don't see any reason, a priori, why this wouldn't work.
If anyone has another suggestion, always interested to hear.
ps. I will only mark this answer as "correct" after having tested the above solution.
N.B. the above works well; however, the order of custom fields is not customizable: they appear on the card in the order you create them (which is unfortunate), so if you want them to appear in a particular order on the card front, be sure to create them in that order, from the outset.
Also, you may want to create one sample of each custom field, to ensure you're satisfied with they way they will be arranged on the card front (e.g. using "Priority" and "T-Size" was too long for my taste, as it frequently resulted in the t-size getting pushed to the next line, on the card front; by shortening them to "P" and "T" they always display next to each other. You want to figure this out *before* setting up all your rules, as the rules are tied to the specific *strings* used for the field name and options (e.g. it is associated with "T-size" not "Custom Field #1" and it is associated with "Sm" not "Custom Field #1, Option #1" which would make for more flexible programming).
Hello friends! From the community that brought you Welcome Wednesday, Throwback Thursday and Friday Fun, welcome to Taco Tuesday, a weekly discussion about all things Trello. The best part? One Tac...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events