-
Notifications
You must be signed in to change notification settings - Fork 127
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-855] Save user's last used field values #969
Conversation
…values (#67) * [MI-3466] Fix Jira issue mattermost#955: Save user's last used field values * [MI-3466] Code refactoring * [MI-3466] Fixed issue: not able to select prject while creating subscriptions * [MI-3466] Review fixes
@@ -33,8 +33,14 @@ type Connection struct { | |||
Oauth1AccessSecret string `json:",omitempty"` | |||
OAuth2Token *oauth2.Token `json:",omitempty"` | |||
Settings *ConnectionSettings | |||
DefaultProjectKey string `json:"default_project_key,omitempty"` | |||
MattermostUserID types.ID `json:"mattermost_user_id"` | |||
SavedFieldValues *SavedFieldValues `json:"saved_field_values,omitempty"` |
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 are technically losing data here by changing its shape, but the "old" value of DefaultProjectKey
is not too important. Just something to think about when changing persistent data structures
}; | ||
} | ||
|
||
fields = {...fields}; |
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.
Does this need to be 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 Fixed
So the one field we save is the "component" type. I'm thinking the point of the feature is to fill in more fields than just the components. From the discussion at #855, we didn't land on a definitive requirement to fulfill here. @matthewbirtch Any thoughts on how exactly this feature should work? Personally I think we should save everything that's not the summary nor a textarea (description or custom textarea), which seems to be what Jira does with their "Create another issue" checkbox feature |
One thing I suggested in that discussion is having a "Clear All" button that allows you to start from scratch if the filled out fields don't apply to the second ticket you're creating |
I'm not sure we should prefill that much. I think we should prefill only the following based on the previous selection:
I don't imagine Fix Version, Epic, Assignee, Labels, etc would be repeated as much from one ticket to the next |
@matthewbirtch "Team" is not a built-in Jira field. Instead, it's a custom field we have on our Jira instance. Unfortunately we don't have a way to give precedence of that field over other custom fields, unless we make it so this can be explicitly configured somewhere. The plugin already supports the last selected "project", and this feature is currently adding functionality for "issue type" and "components". I personally don't use components that often (though I know they are commonly used), and I think auto-selecting "issue type" wouldn't save me much time when creating an issue. This feature request came up for use during a bug bash, where many of the fields would be the same for each ticket. That's where I see it being most useful, and saving the most clicks in the form. |
@mickmister I'm not sure the bug bash use case is ubiquitous enough to save all fields from previous issue created with the plugin. Maybe we could assume you want that if you're creating issues in quick succession, but if I create an issue today and then create the next issue tomorrow, I would find it confusing why all the fields were prefilled and I would likely have to clear most of them which actually makes it take longer. |
@matthewbirtch This is where the "Clear all" button would be useful, though it's really just a bandaid on the issue Thinking about this some more, I think the pre-populating of form fields should be a bit more explicit. Any "implicit" approach (pre-filling Component without explicitly telling the user this is happening) can cause issues where the value was unknowingly and accidentally assigned a value, when it should have been blank. We could have a button for the user to click when they open the modal that says "prefill fields with values from my last submission". This way the user has full control over the automation happening, and can decide on the spot what they want to happen in the form. |
@mickmister I'm hesitant to add either of the 'clear all' or the 'prefill fields' buttons since they are not common, expected elements in a form. Reset buttons are not recommended as a UX best practice. I'd be a bigger proponent of prefilling a few key fields as sensible defaults and just leaving the rest out. |
@matthewbirtch I'm thinking the functionality of "autofill Component" could provide more trouble than good. Making the "issue type" autofilled does make sense as it's an obvious step in the form that's being filled out, but the I'm thinking we should decrease the scope of this task to only include |
I'm good with that for now @mickmister |
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #969 +/- ##
==========================================
+ Coverage 29.65% 29.68% +0.02%
==========================================
Files 52 52
Lines 7792 7805 +13
==========================================
+ Hits 2311 2317 +6
- Misses 5285 5292 +7
Partials 196 196
☔ View full report in Codecov by Sentry. |
@mickmister @matthewbirtch Removed the logic to store the component field. |
Tested and working fine for the following conditions:
Tested for both Jira Cloud and Jira Server. Approved, LGTM. |
@mickmister Gentle reminder for re-review |
1 similar comment
@mickmister Gentle reminder for re-review |
@raghavaggarwal2308 Heads up that the PR broke |
Summary
Updated logic to store the last used issue type value while creating the issue and prefill the modal with those values the next time the user creates an issue.
What should be tested?
Ticket Link
Fixes #855