search

n0v1c3 / vira

Create and update your Jira issues while inside Vim!
MIT License
94 stars 12 forks source link

Handle missing assignee and guess current user correctly #66

Closed ghost closed 3 years ago

ghost commented 3 years ago

In few places the implementation assumed that the assignee field is present in every Jira issue returned which is not necessarily true and in fact seen otherwise in a fairly big production Jira instance. This is fixed uniformly by checking field's presence.

The current user was also ambiguously determined which in some cases returned incorrect result: if the 'assignee or reporter' query returned the current user as the reporter first, the implementation still checked the assignee first and assumed it to be the current user (which could be different that the reporter being the current user). The fix is to query the assignee and reporter separately to determine the current user.

n0v1c3 commented 3 years ago

@kkonopko welcome to the team!

VIRA-280 is yours for now on random pushes real problems we can add new issue numbers to. I am moving my at home jira to the cloud jira when I am confident.

Generally I create a branch off dev for ie VIRA-280 do my work then merge back to dev all labeled like "VIRA-280: ..." just to make GitHub look even nicer with Jira.

When we are all happy and dev is stable I usually do the master pushes from there with the version updates in the push ie "VIRA 0.4.10 ..."

I will probably start sending invites out on the cloud Jira side and then work on transferring my project over, with some fear.

ghost commented 3 years ago

@kkonopko welcome to the team!

VIRA-280 is yours for now on random pushes real problems we can add new issue numbers to. I am moving my at home jira to the cloud jira when I am confident.

So IIUC, I should be labelling any commits from now on with VIRA-280.

Generally I create a branch off dev for ie VIRA-280 do my work then merge back to dev all labeled like "VIRA-280: ..." just to make GitHub look even nicer with Jira.

So PRs should be targeted at dev branch?

When we are all happy and dev is stable I usually do the master pushes from there with the version updates in the push ie "VIRA 0.4.10 ..."

I will probably start sending invites out on the cloud Jira side and then work on transferring my project over, with some fear.

Yeah, I accepted some invite but no longer sure what it was for (due to my zero-inbox I no longer have tha email nor can find any reference anywhere in my GitHub account).

ghost commented 3 years ago

Also you're happy to close PRs or do you want me to do that when I see them being merged with your workflow?

n0v1c3 commented 3 years ago

👍

n0v1c3 commented 3 years ago

As for my server at home I do not believe it was me that has sent any emails yet. I want to transfer that to the Atlassian site first and stop relying on my server at home. Apparently I am allowed to transfer over for free as an offer from them.

Do not worry too much about simply merging to dev without the request. My own goal is to truly make this Open Source code and find a way to make this process safe as it grows by itself.

Don't worry too much about master pushes as that is usually a planed release or the minor bugs that come up.

I do not have a perfect bug plan all the time and it usually is done the same way unless dev is simply too far ahead of master. Then I will meet it into master and pull master back into the development branches to keep them up to date.