[Instrument API] expand saving functionality to include Candidate age calculations and scoring

[ridz1208]

Brief summary of changes

Currently the API only calls the _save() function which stores the data sent to it in the appropriate instrument. That workflow is not symmetrical to saving on the front end which computes the age and scores.

This PR is not making it 100% symmetrical either since validation is not being added but it gets closer to the target

Testing instructions (if applicable)

1. try saving an instrument using the API and see if scoring and candidate age calculations are done

Link(s) to related issue(s)

• Resolves Scoring not run when instrument saved from the API #7460

[driusan]

The only thing missing from the validate code path of the save() function seems to be:

// determine the data entry completion status, and store that in
// the database
$dataEntryCompletionStatus = $this->_determineDataEntryCompletionStatus();
$this->_setDataEntryCompletionStatus(
    $dataEntryCompletionStatus
);

why not just add that?

You could also try moving the code into a final public class method and calling that from both save and the api, to ensure that they're always doing the same thing.

[ridz1208]

can I just move the data entry completion status logic to save values instead ? or you prefer not ?

[driusan]

I looked into the IBIS and CCNA repositories and on IBIS there's 19 instrument classes that override _saveValues, mostly to implement instruments that have an uploader. (I think it might be the only way to do it?)

CCNA, on the other hand, has a bunch of scripts that call _saveValues but no instruments that override it.

It's probably safer to keep it where it is to ensure that it doesn't get missed.

[driusan]

@xlecours can you look at this too?

[ridz1208]

@driusan changes done.

just curious why you wanted to do it final ?

[driusan]

I meant including the _saveValues and score parts. I just realized looking at the latest change that that's not possible because of the $this->form->process wrapper around _saveValues to extract the values. The reason for it being final is because (if those 2 calls were included) it's an internal helper that's only public so that the API (which is in a different class/module) can call it to ensure the same behaviour.

i'm not opposed to the updateDataEntryCompletionStatus being moved out. It's a little cleaner.. but you're right there's no reason for that to be final on its own.

[ridz1208]

Ohhh I get it. let me remove the final and it'll be ready