.. _important-job-validation-flags-follow-the-shared-vocabulary: ================================================================= Important: The job validation flags follow the persons vocabulary ================================================================= Description =========== The flags of :file:`Configuration/AcademicJobs/Settings.yaml` are read by the shared settings classes of :guilabel:`academic_base`, and mean what they mean in :guilabel:`academic_persons`: * Flags are read regardless of case and of spaces around them. A flag written :yaml:`Required` made nothing required before and rendered :html:``. It makes the field required now. * A flag outside the shared vocabulary is ignored. Before, the new job form rendered the first flag that was not :yaml:`required` as the HTML input type, so a typo produced an input such as :html:``. * :yaml:`readonly`, :yaml:`disabled` and :yaml:`frontendreadonly` take effect. They cancel :yaml:`required` in the form and in the check of a submitted job, and the first two lock the field in the backend. The form keeps offering the field. * :yaml:`tel` renders a telephone input. The shipped settings mark the contact phone with :yaml:`tel` instead of :yaml:`number`. The form renders :html:`` for it, so a browser accepts a number like :code:`+49 30 123`, which a number input refused. A site package that copied the whole block of 2.x still names :yaml:`number` and has to change it, see :ref:`breaking-job-validation-settings-reach-the-backend`. A required settings field the job has no property for is left out of the check of a submitted job. Before, it made every submission fail. Affected installations ====================== Every installation that renders the new job form: the contact phone input changes its type. Installations whose site package ships its own settings file with flags in other than lower case, with an unknown flag, or with a field the job has no property for. .. index:: Frontend, NotScanned, ext:academic_jobs