Return the assign response from Job.assign

[abreckner]

Why

XPM's job.api/assign response is a full document carrying both the outcome and the authoritative post-assignment state — the assigned staff, manager and partner:

<Response api-method="Assign"><Status>OK</Status><Job><ID>J000032</ID>...
  <Manager><ID>859230</ID><Name>Dev Testing</Name></Manager>
  <Assigned><Staff><ID>859230</ID><Name>Dev Testing</Name></Staff></Assigned>
</Job></Response>

Job.assign reduced all of that to response["Status"] — the string "OK". A caller could learn that the request succeeded but never what XPM actually recorded, so there was no way to tell a partial assignment from a complete one.

That gap is the root of a recurring class of support issue in the app: workflows deploy to XPM "successfully" with staff, manager or partner silently missing, and nothing durable records what the provider confirmed. Needed by NEB-641.

What

Job.assign now returns the whole response hash, so callers get both "Status" and "Job".

Returning the response rather than digging out one key is deliberate: a caller checking the outcome and a caller reading the confirmed assignment both need it, and neither half is recoverable from the other. It does make assign the one method here that returns the envelope rather than a member — add, update, get and applytemplate return response["Job"], while state and delete return response["Status"]. That asymmetry is the point: assign is the only call whose result is interesting on both axes.

Compatibility

This changes a public method's return type, hence the minor bump to 0.5.0.

The only consumer is XpmIntegration::Job::Api.assign_staff in Practice-Ignition, which currently discards the return value, so nothing breaks on the bump. Callers that want the confirmed assignment read response["Job"]; callers that want the outcome read response["Status"].

Worth knowing for anyone relying on the status: Connection#handle_response raises ApiError on Status == "ERROR" before assign ever returns, so in practice "Status" is always "OK" on the success path.

Testing

The existing assign cassettes already contain the full payload, so no re-recording was needed. The six assign examples now assert on both halves — the status, plus that Assigned/Staff, Manager and Partner come back on the add paths and are absent on the remove paths. That is materially stronger than the previous eq("OK").

bundle exec rake → 93 examples, 0 failures; bundle exec rubocop → 46 files, no offenses.

🤖 Generated with Claude Code

[wizardofosmium]

I dig it! 👍