JIRA API messed up by another plugin vendor. Should this be allowed?

Dear fellow developers, I really need your support and thoughts on this.

We spent time and money developing a JIRA plugin only to find out that another plugin vendor messes up with the worklogs and is not updating them properly.

Our plugin is based on worklog data and this renders our plugin useless.

JIRA support claims that it is up to the timetracking vendor to alter the worklogs as they wish or not update them at all. I really find it disturbing to provide an API that can be compromised by other plugin vendors.

Am I right or wrong ?
Your thoughts and support on this issue will be appreciated.

I guess that stuff happens. I’ve recently also worked together with an Atlassian Partner and another add-on vendor to fix an issue that occurred because of the inner workings of our add-ons. The best thing to do is to get in touch with the vendor and try to make sure that the issue is resolved. In my experience, vendors are open to at least discuss these issues and try to find a solution that satisfies both.

2 Likes

Hello @ktsour, I know you’re seeking other developer feedback here but I also want to offer up the Nov 2016 blog post introducing the time-tracking provider module, https://developer.atlassian.com/blog/2016/11/time-tracking-provider-module/ and offer up the JIRA documentation for this newer module, where a third-party can become the time-tracking provider instead of JIRA work logs, https://developer.atlassian.com/static/connect/docs/beta/modules/jira/time-tracking-provider.html

JIRA also provides an API for you to check the current/selected time-tracking provider, https://docs.atlassian.com/jira/REST/cloud/#api/2/configuration/timetracking-getSelectedTimeTrackingImplementation. In the case where it is a third party add-on, our recommendation is for you to work with the third party to access time-tracking data.

1 Like

@remie - I second this.

@ktsour ,
We have to be good ecosystem citizens and take care of each other. In most cases things like this are developer/vendors that don’t realize that they’ve done something that has downstream effects.

Atlassian can build a very robust API, but there will always be a way to come up with an imaginative workaround for something since that’s where the “fun” is at. It’s a bit of a game of cat and mouse. It’s also a game I’d rather Atlassian not play since it will mean that the API will end up having less flexibility and we’ll then start complaining about not being able to do innovative things using it.

My suggestion would be to contact the other vendor and see what’s going on and show them the impact of what they’re doing and suggest to them an alternate approach. We’re all in this together. :wink:

3 Likes