mattermost-plugin-jira icon indicating copy to clipboard operation
mattermost-plugin-jira copied to clipboard

Save user's last used field values from Create Issue modal, to be used for future issue creations

Open mickmister opened this issue 2 years ago • 7 comments

At the moment, the plugin saves a given user's last selected Jira project in the Create Issue modal. However other fields, such as issue type and labels, are not saved.

The task here is to make it so when a user submits the Create Issue modal, the field values in the submission can be used for creating another ticket in the future. A more advanced version of this feature allow for custom configurations of field values, but the scope of this task is just to support the last used form submission.

Relevant thread https://community-daily.mattermost.com/core/pl/pxdo44fnk7rkxf1tmqge65g9rw

mickmister avatar May 09 '22 03:05 mickmister

@matthewbirtch How do you see this working, in regards to when we should use these values? Should we simply assume that the user wants to use the previously entered values, and provide a way to clear the fields?

mickmister avatar May 09 '22 03:05 mickmister

@mickmister I think it depends on the fields. I would suggest, we pre-fill the issue type, but maybe not the labels. Could you provide all the fields that are possible in the form?

matthewbirtch avatar May 09 '22 14:05 matthewbirtch

@matthewbirtch Although pre-selecting the Issue Type is helpful, I think if we are visiting this feature, we should try and make it as convenient as possible for power users. A strong use case this is scanning posts to triage for your team, so you would want to have the same Mattermost Team and Fix Version, and possibly things like Labels and Epic Link.

A customer has requested we support Issue Types and Components. If we were to support Components, I think it makes sense to support arbitrary select fields as well.

I was thinking we would mimic Jira's "Create another" feature, where all fields remain filled in besides "Summary" and "Description".

mickmister avatar May 09 '22 14:05 mickmister

Ya, I can get behind that. We may want to massage which fields we prefill as we go, but I think your proposal could work.

Prefilling fields can help, but we'll want to make sure we haven't taken it too far where users end up having to remove a lot of the prefilled fields anyway.

Project, Team, Issue Type, Components make more sense to me to prefill, but I don't know if Fix Version, Labels or Epic make as much sense to me.

The one concern I would have is that tickets could get filed mistakenly because of the prefilled fields

matthewbirtch avatar May 09 '22 14:05 matthewbirtch

Prefilling fields can help, but we'll want to make sure we haven't taken it too far where users end up having to remove a lot of the prefilled fields anyway.

@matthewbirtch Right, this is why I suggested having a "Clear All" option, to start from scratch. Maybe we should get more feedback on this before sticking to an extreme one way or another (small subset of fields or large)

mickmister avatar May 09 '22 14:05 mickmister

I think it would help to understand some of the user cases better, but I don't have a huge problem with determining a sensible set of prefilled fields and getting feedback on that

matthewbirtch avatar May 09 '22 15:05 matthewbirtch

+1 for Team, Issue Type, Components and potentially Labels, primarily for bug triage like @mickmister mentioned.

Phrynobatrachus avatar May 09 '22 17:05 Phrynobatrachus