[pve-devel] [PATCH manager] api: backup: auto-inject job id where expected by the API

[Fiona Ebner <f.ebner@proxmox.com>]

for backwards compatibility. Otherwise, e.g. listing backup jobs with
pvesh get /cluster/backup is broken. And suddenly not having the
property anymore would be a breaking API change.

Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
---

I didn't see any other places that rely on the $job->{id} to be set.
The other backup-related API calls and Jobs.pm iterate or check the
ids from the section config's $parsed->{ids}. Scheduler doesn't need
either AFAICT.

@Dominik: I guess you need to adapt the (not-yet-applied) realm sync
jobs API too now that the id is not auto-injected.

 PVE/API2/Backup.pm | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/PVE/API2/Backup.pm b/PVE/API2/Backup.pm
index b6f5916d..3a079874 100644
--- a/PVE/API2/Backup.pm
+++ b/PVE/API2/Backup.pm
@@ -130,6 +130,10 @@ __PACKAGE__->register_method({
 		$job->{'next-run'} = $next_run if defined($next_run);
 	    }
 
+	    # FIXME remove in PVE 8.0?
+	    # backwards compat: before moving the job registry to pve-common, id was auto-injected
+	    $job->{id} = $jobid;
+
 	    push @$res, $job;
 	}
 
@@ -273,7 +277,12 @@ __PACKAGE__->register_method({
 
 	my $jobs_data = cfs_read_file('jobs.cfg');
 	my $job = $jobs_data->{ids}->{$param->{id}};
-	return $job if $job && $job->{type} eq 'vzdump';
+	if ($job && $job->{type} eq 'vzdump') {
+	    # FIXME remove in PVE 8.0?
+	    # backwards compat: before moving the job registry to pve-common, id was auto-injected
+	    $job->{id} = $param->{id};
+	    return $job;
+	}
 
 	raise_param_exc({ id => "No such job '$param->{id}'" });
 
-- 
2.30.2