Feature Request: Don't check Jira when all issues are closed

[shukuyen]

Hi there,

thanks for Jira Mobile Connect, it's a great tool with great potential!

One thing that is bothering me is that once a user contacted support every app start a connection to Jira is established. I would like that only to happen when there are open tickets, or in other words you should be able to set an issue to "Closed" which causes JMC to think of that ticket as done and not try to fetch updates for it.

Also there is still some room for improvement on the UI/usability side of things :-) Have a look at the Google Currents iOS app, they are doing a good job iMHO.

Thanks!

[ChrisA · Accepted solution]

Hi Shukuyen,

This is actually one of the problems that Rob and I tried to solve with a ShipIt project a while back. Unfortunately I never got around to cleaning it up and handing it over to Nick for putting out there.

Essentially, it would use the Apple Push Notification System and fall back to the polling if APNS was not available (if a user did not want to receive push alerts for example). This means not only that there was no polling on every launch (only launches after a push notification was recieved) but also that you could recieve a notification whilst the app was already running.

I'm currently going through and cleaning it up a bit in my spare time, but I was wondering if you'd be interested in trying out a beta of it soon?

Regards,

Chris

[shukuyen]

Hi Chris,

that's good news as this is probably the best solution! Of course I am interested in trying out a beta :-)

Best regards,
Cornelius

[ChrisA]

Awesome - I should have something ready next week - if you could shoot me an email at clepetit at atlassian dot com, then I can get it touch with you about trialing this :)

[shukuyen]

Hi Chris, are you still around? Couldn't reach you via email and the apns fork didn't work for me sadly :-S

[Nick]

Hi Shukuyen,

You do raise an interesting point, however as Nic has pointed out, it does add quite bit of complexity to both the SDK code and the UX for the developer (what is a closed state, exactly ? what if I re-open the ticket?).

We have optimized the poll-request to JIRA very much:

* all data is compressed to and from the server

* the query is backed by JQL, that has been finely tuned

* a date updated flag is passed from the client to JIRA and an empty response is returned if there were no updates since that time for that user in that project

I wonder if this could relate to a similar feature-request we have: allowing users to delete issues from their inbox they no longer care about? If an end-user has marked all issues as deleted, then the SDK would not poll for updates ?

Cheers,

Nick

[shukuyen]

Hi Nick,

I had a deeper look at the JMC code and think I now better understand the problem. I think you are spot on with the last paragraph, giving the user an option to decide to check for updates or not is a good idea. This combined with Chris' push notification approach and the system would be perfect in my opinion.

Bye,

Cornelius

[Nic Brough -Adaptavist-]

There's a slight problem with your idea - how does your mobile device know that there are no open tickets until it's made the connection and asked Jira?

Of course, you are correct about JMC not scanning issues it knows are closed - no point in re-downloading stuff it already has. But how does it know the issue is closed unless it asks?

I think at the very least, JMC absolutely MUST scan for "issues updated since I last connected", otherwise it won't actuall work at all.

[shukuyen]

Hi Nic,

I don't mind JMC checking with Jira while a ticket is not resolved. Once I set the ticket to "Closed" or a similar status in Jira JMC will see that update and know it doesn't need to check that issue again. If no issue with a status lower than closed is in the JMCIssueStore no connection should be made to the Jira instance.

I know this could cause problems if a closed issue is reopened or commented or something like that, but in my opinion that can be solved by only setting an issue to closed if you are sure it is really done. I think it's more important to prevent massive loads of requests (possible for popular apps) ... What do you think?

Maybe if added as an option or as a custom status (Perma Closed or something like that ;))

[Nic Brough -Adaptavist-]

Mmm, you've got two options. Either

1. the application MUST read the issues - even if it's just to check the "last updated" date

2. you have to explain to your users that "if you put an issue in this status, your mobile device will ignore it forever", and then come up with some mechanism to stop the phone ignoring updates (i.e. change the application so it allows the users to force a re-scan, and then think of some way to tell them that they need to do it outside the application)

Having a permanent close feels like a complete kludge, as you've suddenly got to do a load of override coding, and think of a way to talk to your users outside the standard way of doing it. I guess I'm saying it's complex and ugly, just to reduce the load on a machine a bit. I don't know how the application works, I'd hope it makes minimal checks on the server (i.e. last updated vs last time it checked), and if it does more than that, it probably needs optimising. But it still needs to check.