GH-124 Improve "Attach to Issue" function

[hectorgabucio]

Summary

• Feedback in mattermost channel when an issue comment is created.
• Permalink in issue comment.
• Showing org/owner, repo and issue number in the search list.
• Locked issues are shown but can't be selected.
• More precise feedback when the usser doesn't have enough permissions (maybe banned or blocked from org) or the repo has turned private.
• List issues in which the user is not the assignee.

Issue link

Fixes #124

[aaronrothschild]

@DHaussermann how can I get a spinwick to test out this contribution?

[DHaussermann]

@aaronrothschild I will deploy this to a test server and ping you credentials.

[mattermod]

This issue has been automatically labelled "stale" because it hasn't had recent activity.
A core team member will check in on the status of the PR to help with questions.
Thank you for your contribution!

/cc @jasonblais @hanzei

[jasonblais]

@aaronrothschild / @DHaussermann quick reminder to help with reviews after the holidays. Thank you!

[DHaussermann]

Hi @hector2, Sorry for the delay on this. Thanks for the round of improvements. The feedback that the comment has been added really makes this nicer to use!

I've done some testing on this and have a couple questions:

1. Was there previously any type of restriction on which repos I could search in for issues or, did it just seem that way because I could only search for issues where I was the assignee? Currently, it seems like you can search across any public repo. Is that correct?

2. Would you be able to make two small improvements to the post menu. The option reads Github instead of GitHub and the text seems to be top justified instead of middle justified. This is not directly related to your PR so, if not, I'd be happy to create a separate issue.

[hectorgabucio]

Hey @DHaussermann !

1 - Yes, before these changes you could only list the issues in which the user it's the asignee. I did that because I though that was desired, but maybe I'm wrong, let me know! :D

-> his design is limited to adding comments where the user is the assignee. There would also be value in adding comments to other issues as well. Would we need a more complex design to handle cases where you select an issue and don't have permissions to comment?

2 - What do you mean by "the text seems top justified"? I looked at the post menu but it seemed fine. The options are aligned to the left.

And yes I can make those improvements of course!

[DHaussermann]

1. @aaronrothschild do you have any thoughts on this? The current design certainly offers the most functionality but, the draw back is that it's a bit confusing since your search can return issues from countless repositories.

2. @hector2 This is a bit easier to notice when compared to other plugins like Jira. The text is not vertically centered to line up with the middle of the icon. It sits a bit high such that the top of the text lines up with the top of the icon.
   

[hectorgabucio]

@DHaussermann hey, I think the alignment problem is related to mattermost/mattermost-plugin-jira#407 . Let me check if I can do the same in this case.

EDIT: I did a change and now it should be aligned like in the jira plugin.

[DHaussermann]

@hector2 Thanks for fixing the alignment issues! I had a couple follow up questions about error cases...

A. When the user does not have permission to make the comment, it's great that we return allot of info but, the error looks a bit cryptic.

Can we trim off the beginning and about id and message and loose the braces? Or is there limited control over what goes up to the UI?
Edit: Actually disregard A. I'm sure there would be cases where there is data to return in those empty fields.

B. When a conversation becomes locked in GitHub I noticed that the issue becomes non-selectable in the UI. The user's pointer changes to a crossed out circle. Just curious if there is a reason this is different rather than have the user select the option and see an error in the modal

@aaronrothschild to clarify my comment from above, the UX of opening the search and seeing issues from countless different projects to search for would only be the case if the plugin is not locked to an organization or a users' work space. When locked it only returns issues from within these repos in the issue search results. Please confirm you're okay with this design.
Also, both of the issues above a very minor, maybe I should simply create a follow-up issue for the Error UX and not hold up this PR.

[aaronrothschild]

Edit: This comment isn't relevant anymore, ignore it.

@asaadmahmood Any thoughts on this?

I think ideally we can "scope" the search to only include repositories they own or belong to at first. It becomes pretty unwieldy. Perhaps a radio button select: [ ] My/MyOrg's Repositories [ ] All Public Github Repos. OR alternatively should we break the search into two parts: ask for the repo keywords first, then allow search by keywords through issues in that repo.

You start to realize how commonly used some words are in issues and it becomes almost impossible to find the relevant issue unless you add the keyword of the gituhub repo name, then it becomes more manageable. I think the UI should encourage that behavior perhaps - by splitting the search box into two fields, one for the repo name and one for the keywords being searched within that repo. I'm 2/5 though.

cc @DHaussermann ?

I'm not suggesting we make a heavy interface like this, but I like how Gitbook's Github Repo selection allows me to choose based on which repos are related to me:

Just an example when you use some words that are unusual it reduces the results set, but I had a hard time finding some of the issues I was expecting to be able to find easily.

[aaronrothschild]

@aaronrothschild to clarify my comment from above, the UX of opening the search and seeing issues from countless different projects to search for would only be the case if the plugin is not locked to an organization or a users' work space. When locked it only returns issues from within these repos in the issue search results. Please confirm you're okay with this design.
Also, both of the issues above a very minor, maybe I should simply create a follow-up issue for the Error UX and not hold up this PR.

@DHaussermann @hector2 OK, that's great and ideal then. Ignore my comment above, I had half-written it earlier today and just finished typing it when I saw Dylan's note.

[DHaussermann]

Okay Thanks @aaronrothschild I'd be curious how common it is for people to use the plugin not locked to an organization. There may be a worthwhile story in the future IF we get feedback that it would be valuable to restrict attachment functionality.

[DHaussermann]

Tested and passed

• Tested to ensure post is created with link to github issue
• Tested various error cases for attach (User permission, thread locked, issues disabled)
• Tested to ensure that when locked the attach search only returns issue from that Organization or Wrokspace
• Ensured issues are hidden for appropriate users if repo is made private
• Post menu option has been fixed
  Added necessary steps to release testing.
  LGTM! Thanks @hector2 for the work on this!

Will follow up with Aaron to see if future changes are needed for error UX

[mickmister]

Great work @hector2! Just one request about style

[mickmister]

LGTM, thanks @hector2!!