-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[GH-862] Added issue status field in subscription modal #976
Conversation
* [MI-3483] Added the status field in subscription modal * [MI-3483] Code refactoring * [MI-3483] Fix testcases * [MI-3483] Added error handling and code refactoring * [MI-3483] Review fixes * [MI-3483] Review fixes * [MI-3483] Review fixes
@raghavaggarwal2308 I'm thinking this should go in the field filters part of the modal, rather than have its own place under the issue type selector. This way you can selectively include/exclude certain statuses. What are the pros and cons of this approach versus the current one? |
@mickmister There are four options in the filters section i.e. include, exclude, include all, and empty. If we add the status field in the filters section then the "include all" and "empty" options will be useless as I think the status field can't have multiple values at a time and it can't be empty as well.
The advantage we will have by moving the field to the filters section is that the user will be able to use the "exclude" option. |
This seems like the right solution to me The field "filters" are meant for "what state is the ticket currently in", which the status certainly applies to that. Thoughts on moving it to the filters? |
@mickmister Sounds good, will make the change and update the PR. |
…72) * [MI-3597] Moved the issue status field into filters section of modal * [MI-3597] FIxed a minor issue * [MI-3597] Review fix
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #976 +/- ##
==========================================
- Coverage 33.27% 33.18% -0.09%
==========================================
Files 53 53
Lines 7950 7977 +27
==========================================
+ Hits 2645 2647 +2
- Misses 5078 5103 +25
Partials 227 227 ☔ View full report in Codecov by Sentry. |
@mickmister Updated:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome work on this @raghavaggarwal2308 👍 I have a few suggestions, one being that we include the status information in the create-issue-metadata
call to cut down on the frontend code needed to fetch the statuses separately. Please let me know your thoughts thanks
webapp/src/components/modals/channel_subscriptions/edit_channel_subscription.tsx
Outdated
Show resolved
Hide resolved
webapp/src/components/modals/channel_subscriptions/edit_channel_subscription.tsx
Outdated
Show resolved
Hide resolved
webapp/src/components/modals/channel_subscriptions/edit_channel_subscription.tsx
Outdated
Show resolved
Hide resolved
webapp/src/components/modals/channel_subscriptions/edit_channel_subscription.tsx
Outdated
Show resolved
Hide resolved
…ata API (#74) * [MI-3628] Updated the code to return the status details in the meta data API instead of making a separate API call. * [MI-3628] Review fixes: Small code optimization
@mickmister Fixed the review comments mentioned by you. We are now returning the status data from the create meta data API. |
@raghavaggarwal2308 Can you please update the screenshot in the PR description to match the current code? Edit: I moved the one from the comment above into the PR description |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few more comments for discussion
client, _, _, err := p.getClient(instanceID, mattermostUserID) | ||
if err != nil { | ||
return nil, err | ||
} | ||
|
||
return client.GetCreateMetaInfo(p.API, &jira.GetQueryOptions{ | ||
projectStatuses, err := client.ListProjectStatuses(projectKeys) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have we tested this feature on Jira Cloud and Jira Server?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mickmister Tested and made the necessary changes
webapp/src/types/model.ts
Outdated
export type IssueMetadata = { | ||
projects: Project[]; | ||
issue_types: IssueTypeWithStatuses[]; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the sole purpose of having a separate issue_types
here to have the statuses? Any way we can just have the backend update project.issuetypes
to include the statuses? It seems like we may be returning twice the data in this code by duplicating the issue types. If we keep them separate then I think we should at least remove everything from IssueTypeWithStatuses
that doesn't have to do with statuses before sending back to the client, if statuses is all it's being used for.
Edit: I think I understood this wrong. The ListProjectStatuses
backend JiraClient
function doesn't return all of the issue type data. I'll trust your judgment how this should be organized. I think we should be more specific with this name though like issue_types_with_statuses
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mickmister Yes, ListProjectStatuses
returns only the fields that we need in our implementation. It would be very complex to move this inside the project.issueTypes
as we have to manually iterate over both the array multiple times and add the field. Also, the type used for issueTypes
inside the project data does not have the "statuses" field. So, we have to create a new custom type instead of using the type provided by the package.
- Added testcases for status field. - Fixed issue: create meta info API not working for Jira server instance
@mickmister Fixed the review comments mentioned by you |
@raghavaggarwal2308 heads up that there is a merge conflict to resolve |
… into fix_issue_862
@hanzei Resolved conflicts |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just a few comments for discussion
@@ -211,7 +211,7 @@ func (client jiraServerClient) GetIssueTypes(projectID string) ([]jira.IssueType | |||
|
|||
func (client jiraServerClient) ListProjectStatuses(projectID string) ([]*IssueTypeWithStatuses, error) { | |||
var result []*IssueTypeWithStatuses | |||
if err := client.RESTGet(fmt.Sprintf("3/project/%s/statuses", projectID), nil, &result); err != nil { | |||
if err := client.RESTGet(fmt.Sprintf("2/project/%s/statuses", projectID), nil, &result); err != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A little concerning to me, what causes this to change from 3 to 2?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mickmister It was a mistake on my side, the latest API version for the Jira server is 2
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay we definitely want to test any changes made to Jira Server code, with Jira Server. And mention in the test steps of the PR to test both Jira Cloud/Server depending on the changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mickmister Yes, we always test the changes on both instances and it's also mentioned in the description. We missed it initially in this PR, apologies for that.
for (const issueType of issueTypesWithStatuses) { | ||
if (issueTypes.includes(issueType.id) || !issueTypes.length) { | ||
for (const status of issueType.statuses) { | ||
if (!keys.has(status.id)) { | ||
keys.add(status.id); | ||
statuses.push(status); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will issueTypes
ever have length 0? (looking at !issueTypes.length
)
Also it's a bit hard to read will all of the variations of:
- issueTypes
- issueTypesWithStatuses
- issueType
- issueType.statuses
Not sure there is a better way though. I was going to suggest renaming the function parameter issueTypes
to issueTypesWithoutStatuses
, but that sounds like "these issue types have no statuses associated with them". Current code seems fine, just a lot of redundancy causing a bit of confusion for me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to clarify, issueTypes
are the values that are selected in the modal, and issueTypesWithStatuses
contains the data for all the issue types in that project. I will rename issueTypes
to selectedIssueTypes
for more clarity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will issueTypes ever have length 0? (looking at !issueTypes.length)
@mickmister Yes, when we have not selected any value in the modal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can change the name to selectedIssueTypes
to convey they are user set values
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will rename issueTypes to selectedIssueTypes for more clarity.
@mickmister Already changed
projects: [ | ||
{ | ||
key: 'TEST', | ||
issuetypes: [], | ||
}, | ||
], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it realistic to have a blank array for issuetypes
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mickmister No, I don't think this will ever be blank. This particular field is not useful in the function we are testing here, so we kept it empty. I you want we can add some mock data or maybe just add a comment above it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should try to have realistic test data I suppose. I recommend using the saved test data when possible. Or generate new ones / edit existing ones if we need to update them, which I think we do need to update them in this case since we changed the API associated with the testdata files
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mickmister Updated the test files
@mickmister Fixed the review comments mentioned by you. |
… into fix_issue_862
Tested the PR and is working fine for the following events,
Nonetheless in the event |
@arush-vashishtha The issue is fixed now. @mickmister The issue was caused because of an invalid payload being sent from the Jira side in case of issue created event. The status field was always sending the data of a specific status ("Backlog" in our case) irrespective of the status selected on Jira. I have updated the logic to fetch the proper data of the issue in case of this event. Also added a TODO to update the logic in case we get proper data from Jira in the future. |
The reported issue is fixed and tested now, working fine for this one and all the events which are already mentioned before. Approved. |
Heads up that there are conflicts to resolve here |
… into fix_issue_862
@mickmister Resolved |
@arush-vashishtha Were you able to test this with both Jira Cloud and Jira Server? |
Yes I have tested this on both Jira Cloud and Jira Server. |
Summary
Added issue status field in the subscription modal and created an API to fetch the possible statuses of a project.
Screenshots
What to test?
Note: The below things should be tested for both cloud and server instances of Jira.
Steps to reproduce
/jira subscribe
command and create/edit a subscription.Environment:
MM version: v7.8.2
Node version: 14.18.0
Go version: 1.19.0
Ticket Link
Fixes #862