Fix confirmation dialogs to make more sense for UDP #381

[m-mohr]

Closes #381

[Copilot]

Pull request overview

This PR aims to prevent confusing/duplicative confirmation dialogs around UDP batch job execution (issue #381), which previously allowed (or encouraged) queueing the same job multiple times.

Changes:

• Adjusts the job creation/queue flow in JobPanel to avoid offering “Start processing” when the job is already being queued.
• Adds defensive handling for “missing id” cases in the generic store read action and surfaces refresh failures to the user.
• Tweaks refreshElement to handle null updates, but still needs to correctly await async callbacks.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
src/store/storeFactory.js	Adds id validation in read, but the “load by id” fallback currently can’t work due to passing the wrong argument.
src/components/WorkPanelMixin.js	Updates refreshElement behavior for null reads, but still doesn’t await async callbacks (important for callers).
src/components/JobPanel.vue	Reworks job-created dialog/buttons and start+queue behavior to reduce double-queueing, but introduces a return-value issue when queue=true.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

refreshElement invokes callback(updated, old) but does not await it. Multiple call sites pass async callbacks (e.g. queueJob, showJobInfo), so await this.refreshElement(...) can resolve before the callback finishes, and any rejected promise from the callback won’t be caught here. Consider awaiting the callback when it returns a promise (and ideally returning/propagating its result).

Suggested change

	callback(updated, old);
	} else {
	callback(old, old);
	Utils.error(this, "Unable to update " + singular + ". Data may be outdated.");
	}
	}
	return await callback(updated, old);
	} else {
	Utils.error(this, "Unable to update " + singular + ". Data may be outdated.");
	return await callback(old, old);
	}
	}
	return updated;

[Copilot]

In read, when the entity is not found in the store (!data), the subsequent readFnById call uses data (which is null at that point) instead of the extracted id. That path will never be able to load the entity by id. Use id when calling cx.rootState.connection[readFnById](...) (and then proceed with updated).

[Copilot]

createJob assigns job = await this.queueJob(job) when queue === true, but queueJob doesn’t return a job (it returns undefined). This makes createJob(..., true) return undefined and can break callers that rely on the returned job. Either don’t reassign, or make queueJob return the queued/updated job (and ensure refreshElement awaits the async callback so the returned promise resolves after queueing).

Suggested change

	job = await this.queueJob(job);
	await this.queueJob(job);

[Copilot]

Inside queueJob, updatedJob is used as the callback parameter and then re-declared with let updatedJob = await this.queue(...). This shadowing is confusing and also makes the catch block refer to a different updatedJob than the queued result. Rename the queued result variable (e.g. queuedJob) and use that consistently for follow-up UI/error handling.

Suggested change

	let updatedJob = await this.queue({data: updatedJob});
	this.jobAfterCreation(updatedJob);
	let queuedJob = await this.queue({data: updatedJob});
	this.jobAfterCreation(queuedJob);