Skip to content
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

MM-17818 Adding automatic registration of autolinks for JIRA projects. #453

Merged
merged 5 commits into from
Feb 3, 2020

Conversation

crspeller
Copy link
Member

Adds automatic registration of autolinks of JIRA projects converting JIRA tags like MM-1234 to clickable links and pasted links to clickable tags. These are the same links used on community.

This PR requires: mattermost-community/mattermost-plugin-autolink#85

Some notes to be fixed before merge or in follow up PRs:

  • It won't build publicly until the autolink PR is merged
  • Only works for cloud instances. @mickmister @levb Looking for advice on how to enable this for server instances.
  • Needs to act when all plugins are initialized or when the autolink plugin is enabled for the first time. Currently misses the second case and uses a sleep for the first. This will be fixed by: https://mattermost.atlassian.net/browse/MM-21763
  • Autolinks won't be updated when projects are created on the JIRA server. Workaround is to disable and re-enable the jira plugin to cause the re-registration to happen. @aaronrothschild follow up ticket?
  • Tests.

@crspeller crspeller added 1: PM Review Requires review by a product manager 2: Dev Review Requires review by a core committer 3: QA Review Requires review by a QA tester labels Jan 23, 2020
Copy link
Contributor

@levb levb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the biggest 2 changes I request are:

  1. move the link (struct) creation to the Instance interface
  2. consider adding Jira server link support (@DHaussermann or @jfrerich can provide the info on the URL structure)

and naming nits, as usual

server/plugin.go Show resolved Hide resolved
server/plugin.go Show resolved Hide resolved
server/plugin.go Outdated Show resolved Hide resolved
server/plugin.go Outdated
continue
}

if err := p.InstallAutolinkForCloudInstance(jci); err != nil {
Copy link
Contributor

@levb levb Jan 23, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1/5 s/Install/Configure/; 0/5 s/InstallAutolinkForCloudInstance/configureCloud/

OT: IMO reading a function name, one should need to switch to a "parsing" mode, names should read naturally, with the emphasis on the client (caller). I started thinking using this pattern more, to keep the names cleaner. Also helps keepinf the vocabulary consistent. 1/5 we should rename Link to Autolink in the autolink plugin itself before too long.

type autolinkAPI struct {}

func (*autolink) Configure(...link.Link) {...}

...
autolink := NewAutolinkAPI()
err = autolink.Configure(ji.Autolinks()...)

(OT: I recently learned that it's ok to use a _ or even nothing for the receiver! )

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like an "Install" to me since we are sending data to a separate system?

reading a function name, one should need to switch to a "parsing" mode, names should read naturally, with the emphasis on the client (caller)

+1000 You read code way more then you write it.

1/5 we should rename Link to Autolink

Ya I struggled with the name there. I think you are right it should be Autolink. Will change.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

autolink.Install(...*autolink.Autolink) wfm

Copy link
Contributor

@levb levb Jan 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

0/5 To me, install has the connotation of "install and enable the plugin as needed" which is not true, but I can see your POV as well. Maybe autolink.Add(links)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@levb Switched to using a new autolink client to address this feedback.

server/plugin.go Outdated Show resolved Hide resolved
@levb
Copy link
Contributor

levb commented Jan 23, 2020

RE: It won't build publicly until the autolink PR is merged - gomod to the rescue? Got import github.com/mattermost/mattermost-plugin-autolink/v2? :) -- not for this PR, but want to point out the upcoming dependency hell, and circular dependencies appearing.

Consider starting a separate versioned package for all P2P types? Or each plugin having to declare a sub-package with no dependencies that others can depend on?

@crspeller
Copy link
Member Author

@levb How will gomod help? Nothing can be picked up until it's merged.

Yes. Circular dependencies will have to be avoided. In this case it's fine because autolink should know nothing about any other plugin. But I did factor out the link stuff into a separate package anyway.
When building this inter-plugin stuff, we should be sure to define our interfaces well and include them in separate packages as necessary.

Separate versioned package is probably overkill in this situation, but I could see it being useful in the future.

@hanzei
Copy link
Collaborator

hanzei commented Jan 25, 2020

@levb How will gomod help? Nothing can be picked up until it's merged.

You can use the commit on the feature branch as a dependency, e.g. with go get github.com/mattermost/mattermost-plugin-autolink@383545a0f9abbc17ad99f1271ce93ef7b296c7af to use mattermost-community/mattermost-plugin-autolink@383545a

Sure, if there are following commits that break the API there is an problem.

@crspeller crspeller requested a review from levb January 27, 2020 18:03
Copy link
Contributor

@mickmister mickmister left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome job @crspeller! Just some nits on error messages

server/plugin.go Outdated Show resolved Hide resolved
server/plugin.go Outdated Show resolved Hide resolved
server/plugin.go Outdated Show resolved Hide resolved
Co-Authored-By: Michael Kochell <mjkochell@gmail.com>
go.mod Outdated
@@ -8,9 +8,12 @@ require (
github.com/dghubble/oauth1 v0.5.0
github.com/dgrijalva/jwt-go v3.2.0+incompatible
github.com/google/uuid v1.1.1
github.com/mattermost/mattermost-plugin-autolink v0.0.0-00010101000000-000000000000
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should start defining proper versions in our go.mod's?

@levb levb removed the 2: Dev Review Requires review by a core committer label Jan 30, 2020
@levb
Copy link
Contributor

levb commented Jan 30, 2020

Ready to un-draft this, or wait for the other PRs? @crspeller

I guess CI is failing...

@crspeller
Copy link
Member Author

Will un-draft when the other PR is merged and I have updated this one.

Copy link

@DHaussermann DHaussermann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am having issues building this locally even after getting the branch for the corresponding functionality in the other repo.

Please merge and I will test from master and create follow-up issues as needed.

@DHaussermann DHaussermann removed the 3: QA Review Requires review by a QA tester label Feb 3, 2020
@crspeller crspeller marked this pull request as ready for review February 3, 2020 18:44
@crspeller crspeller merged commit 879250a into master Feb 3, 2020
@crspeller crspeller deleted the mm-17818 branch February 3, 2020 18:48
@aaronrothschild
Copy link
Contributor

Just for tracking - I created a follow up ticket for registering automatically: #472

@hanzei hanzei added the 4: Reviews Complete All reviewers have approved the pull request label Mar 7, 2020
@jfrerich jfrerich mentioned this pull request Mar 31, 2020
11 tasks
@jfrerich jfrerich mentioned this pull request Apr 28, 2020
}

client := autolinkclient.NewClientPlugin(p.API)
if err := client.Add(installList...); err != nil {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@crspeller Is the code checking anywhere if the autolink plugin is enabled and running? Or does this line just fail if autolink is not running?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup it just fails. No need to check as checking is probably just as expensive as just trying and failing.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/giphy fire and forget :)

Copy link
Collaborator

@hanzei hanzei May 14, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if it's about cost. This code is only executed once on startup.

My concerns are mostly that admins might be confused on the log warning.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @hanzei. Maybe we can add something to the error that says "Make sure the autolink plugin is installed in order to auto-create links to your Jira issues."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
4: Reviews Complete All reviewers have approved the pull request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants