• Type: Suggestion
• Resolution: Won't Do
• Fix Version/s: None
• Component/s: None
• Labels:

  • API
  • affects-cloud

[JRASERVER-61618] API call to check status of backup jobs and a post to indicate it has completed with or without errors.

Collapse comment: Gosia Kowalska added a comment - 30/Mar/2018 9:19 AM

Gosia Kowalska added a comment - 30/Mar/2018 9:19 AM

Atlassian Update – 30 March 2018

Hi,

Thank you for raising this suggestion. We regret to inform you that due to limited demand, we have no plans to implement it in the foreseeable future. In order to set expectations, we're closing this request now. Sometimes potentially valuable tickets do get closed where the Summary or Description has not caught the attention of the community. If you feel that this suggestion is valuable, consider describing in more detail or outlining how this request will help you achieve your goals. We may then be able to provide better guidance.

For more context, check out our Community blog on our renewed approach to highly voted Server suggestions for Jira and Confluence.

Thanks again.
Regards,
Jira Product Management

Expand comment: Gosia Kowalska added a comment - 30/Mar/2018 9:19 AM

Gosia Kowalska added a comment - 30/Mar/2018 9:19 AM Atlassian Update – 30 March 2018 Hi, Thank you for raising this suggestion. We regret to inform you that due to limited demand, we have no plans to implement it in the foreseeable future. In order to set expectations, we're closing this request now. Sometimes potentially valuable tickets do get closed where the Summary or Description has not caught the attention of the community. If you feel that this suggestion is valuable, consider describing in more detail or outlining how this request will help you achieve your goals. We may then be able to provide better guidance. For more context, check out our Community blog on our renewed approach to highly voted Server suggestions for Jira and Confluence . Thanks again. Regards, Jira Product Management

Collapse comment: Charles McLaughlin added a comment - 22/Jun/2016 9:28 PM

Charles McLaughlin added a comment - 22/Jun/2016 9:28 PM

Thanks for opening this issue Ramiro.

The idea here is /rest/obm/1.0/runbackup should return a Job ID. Another API method should be available to check the Job status. Perhaps something like /rest/obm/1.0/status/<JOB_ID>.

That, in my opinion, is bare minimum functionality. Compare that to the current state - 'runback' returns nothing useful, except if you call it repeatedly you'll get a message that a backup is in progress or that you're throttled for calling it too often. You have to poll the webdav directory waiting for the backup file to show up... and if there's an error, there's no explanation why.

I'm also suggesting that when calling 'runback', it would be nice to provide a callback URL where customers can be notified that backup jobs are done - upon success or failure we'd be notified. For instance, that could trigger a job to download the backup file... much more efficient than polling.

Expand comment: Charles McLaughlin added a comment - 22/Jun/2016 9:28 PM

Charles McLaughlin added a comment - 22/Jun/2016 9:28 PM Thanks for opening this issue Ramiro. The idea here is /rest/obm/1.0/runbackup should return a Job ID. Another API method should be available to check the Job status. Perhaps something like /rest/obm/1.0/status/<JOB_ID>. That, in my opinion, is bare minimum functionality. Compare that to the current state - 'runback' returns nothing useful, except if you call it repeatedly you'll get a message that a backup is in progress or that you're throttled for calling it too often. You have to poll the webdav directory waiting for the backup file to show up... and if there's an error, there's no explanation why. I'm also suggesting that when calling 'runback', it would be nice to provide a callback URL where customers can be notified that backup jobs are done - upon success or failure we'd be notified. For instance, that could trigger a job to download the backup file... much more efficient than polling.