What happened?

Steps to reproduce the issue

• Enable System - Schema.org and the Schema.org - JobPosting plugin.
• Create an article, open the Schema tab, and select the JobPosting type.
• In the "Description of the Job Location" / job location field, pick a non, telecommute option (e.g. the equivalent of "Onsite" or "Hybrid").
• Save and view the page source, then run the URL through Google's Rich Results Test.

Expected result
The generated JSON-LD should only ever use TELECOMMUTE as the value for jobLocationType, because that is the only value Google for Jobs recognises.

Specifically:
Fully remote: output "jobLocationType": "TELECOMMUTE" (plus applicantLocationRequirements).
On-site: omit jobLocationType entirely and rely on jobLocation with a PostalAddress.
Hybrid: output "jobLocationType": "TELECOMMUTE" together with a physical jobLocation. Google interprets the combination as hybrid.

Actual result
The plugin gives the possibility to chose Remote, Hybrid or Onsite for jobLocationType. These are not valid per Google's JobPosting documentation, which lists TELECOMMUTE as the only accepted value. The result is that Google's Rich Results Test / Search Console flags the value as invalid, and affected job postings can be excluded from Google for Jobs.

Background / references
schema.org defines jobLocationType as Text and gives TELECOMMUTE only as an example: https://schema.org/jobLocationType
Google's JobPosting guidance treats TELECOMMUTE as the single supported value, used when the role is 100% remote: https://developers.google.com/search/docs/appearance/structured-data/job-posting

Proposed fix (for discussion)

Restrict the field so non, remote selections do not write a free-text jobLocationType.
Map the UI options to behaviour rather than to literal strings:

"Telecommute / Remote" and "Hybrid" -> write jobLocationType: "TELECOMMUTE".
"On-site / In-person" -> do not write jobLocationType at all.

Additional comments
Happy to test a patch against a real posting via the Rich Results Test.

Version

5.4