update JobBoards protocol

[valentinp10]

No description provided.

[davies-jack]

Just a note, this probably could be jobId instead of just jobid :D

[alexcupit]

this might be a legacy thing from CVL and should only appear on their applications. Shouldn't need it if/when they migrate to the new application endpoint

[davies-jack]

Just noticed here, I might be wrong but from what I can see is that we now have jobPostId within both client and root? Might be a good idea to choose one to reduce any future confusion

[valentinp10]

yes. The "official" place for jobPostId was Client, but some clients integrated it in the root. Now we have to support both.

[alexcupit]

@valentinp10 the only client that has directly integrated is CVL, who I think use jobid on applications? Other jobs are created by the recruitment-service which Jack is updating to meet the protocol requirements so this could be an opportunity to remove it at the root by the sounds of things?

Noticed a duplicate within the schema so wanting to ensure nothing is wrong with this before we go ahead and merge!

[alexcupit]

Think this looks good! Do we also want to add the outputs here such as triggerProxyEmailFallback, resolvedUrl and serviceData?

[valentinp10]

Think this looks good! Do we also want to add the outputs here such as triggerProxyEmailFallback, resolvedUrl and serviceData?

I never received the schema, I only know it exists, but if we use it then yes, we want to add it

[davies-jack]

Will wait for this to be merged before I merge my work in https://github.com/ubio/recruitment-service/pull/74

[davies-jack]

Think this looks good! Do we also want to add the outputs here such as triggerProxyEmailFallback, resolvedUrl and serviceData?

triggerProxyEmailFallback will be a key on output, need to confirm the value as we just use the existence of the key.
resolvedUrl will be a string.
serviceData will be an object like so: {
domain
serviceId
url
}

Am I missing anything @alexcupit?

[alexcupit]

Think this looks good! Do we also want to add the outputs here such as triggerProxyEmailFallback, resolvedUrl and serviceData?

triggerProxyEmailFallback will be a key on output, need to confirm the value as we just use the existence of the key. resolvedUrl will be a string. serviceData will be an object like so: { domain serviceId url }

Am I missing anything @alexcupit?

Looking at recent ATS-Lookup jobs, these are the schemas being used. I think these two outputs only exist on ATS-Lookup so we could also delay enabling strict mode on this service if required.

As for triggerProxyEmailFallback which is used in application scripts, it looks to be a boolean :