Track parent story

[tiagotex]

Hi,

I'm using this plugin with Polarion and when we are creating a PR for the task we would like to be able to tag both the story and the task.

I looked into it but we currently only support one id and url for Ticket type https://github.com/bitcrowd/tickety-tick/blob/main/src/types.ts#L1

Would you be open to adding parentId and parentUrl to Ticket type?

[klappradla]

Hey @tiagotex 🤗

We were discussing something like this in the past already - #372 - but then did not end up implementing it. From my understanding, parent ID and URL would translate to for instance Jira's "epic" and its URL and ID, right?

Let me and the other bitcrowdies have another thought on that.

[tiagotex]

Yep, that is correct. It could be the mapping of Jira task to story or story to epic.

This is important to us because tasks are used only by devs to split work, but the unit of work that product cares about is story level. So being able to set the parent when working on a task would solve our communication issues.

[klappradla]

I see! Would you (and your team) generally be up for implementing this feature or joining forces with bitcrowd to do it?

We - at least right now - do not have enough capacity to just implement this on the side on our own, as the changes are a bit more involving then just adding an adapter or fixing a bug. So for us, it would be a proper "project", but we would of course be happy to do it.

If you take a look at #372, you'll see that we already discussed a similar feature in the past. Back then it was mainly targeting Jira, but the idea and the arising questions and difficulties are the same (PS: @pmeinhardt feel free to always join the discussion, since you also put a lot of 🧠 into this back then 💜).

Problem 🤔

If we introduce parentId and parentUrl as new template variables and the Polarion adapter supports them and fills them with actual content, the templates themselves aren't reusable any more. If you use the new variables in your template, your templates only work with the Polarion adapter and whenever you are on a project which is on Jira, GitHub, you name it, your templates don't work and don't produce usable branch names and commit messages.

Quick solutions 🐇

Support all trackers

One quick "solution" would be, that all adapters expose a parentId and parentUrl. But I doubt that this makes sense for all trackers. I for instance would not know what this could be for a normal GitHub issue or a Notion page.

Template language

Another option would be to switch to a new and more complex templating language which would support conditions, as explored in #383... But this raises the question of how existing templates and configurations can be migrated and if all users really benefit from the more complex templates...

Bigger solution 🪨

An alternative would be: have separate templates per adapter. Doing so, they would expose different variables which make sense for their domain. Implementing this would involve:

• change the settings to have general default and per adapter overrides
• update adapters to support parent URL and ID

Just as a first brain dump @tiagotex. What do you think?

[pmeinhardt]

Thanks for digging up the old discussion @klappradla and summarizing it here. I think the points still apply.

I don't think that "supporting [parent ID] for all trackers" is a (quick) solution to this problem. Even if all adapters added a parent ID to issues, not all issues always have a parent – even for those trackers (i.e., the top-most, root issues). You'd still have to deal with no parent being present in some cases.

So, if templates should be usable across different issue trackers, then something like conditional template sections (if …) are needed.

Alternatively, allowing templates to be configured per tracker (by domain/base URL or some other identifiable property?) could be another approach which would not require new template constructs, and could be desirable when you work on projects with different commit message or branch name requirements. (Note this is somewhat similar to the "bigger solution" outlined above, but subtly different)

Just my 2 cents. ✌️