Validation settings
Configuration/ describes which fields of a job
are required, how they are rendered in the public new job form, and what the
backend record editor of a job demands.
The file is read by the same settings classes of academic_base that academic_persons uses, so the flags mean the same in both extensions.
The file
The shipped configuration defines a single set,
job
. Its keys are
property names in camel case, each carrying a list of flags:
validations:
job:
title:
- required
employmentType:
- required
type:
- required
companyName:
- required
employmentStartDate:
- required
description:
- required
link:
- url
contactEmail:
- email
contactPhone:
- tel
A property that is not listed is neither required nor specially rendered. Flags are read regardless of case and of spaces around them. The flags are the ones of academic_persons, and a flag outside that vocabulary is ignored.
Where the flags take effect
Every flag is read by the new job form, by the check of a submitted job, and by the backend record editor of a job:
| Flag | New job form | Submitted job | Backend record editor |
|---|---|---|---|
required
| Marks the field with an asterisk | Value must not be empty, 0 counts as empty for a number such as
the job type | Required |
readonly
,
disabled
| Shown, not marked | Not required | Read only, not required |
frontendreadonly
| Shown, not marked | Not required | As the other flags say |
email
| Renders
<input type="email">
| Value must be an e-mail address | An e-mail field |
url
| Renders
<input type="url">
| Value must be a URL | Unchanged |
number
| Renders
<input type="number">
| Not checked | A number field |
tel
| Renders
<input type="tel">
| Not checked | Unchanged |
date
| Renders
<input type="date">
on a text field | Not checked | Unchanged |
textarea
and
html
belong to the profile editor of
academic_persons. The new job form chooses between a text field
and a text area per field itself, so do not use them here: on a text field
they render an invalid input type.
The backend half applies to the fields the job table has a column for, with
the column name derived from the property name:
company is the
column
company_. For every configured field the settings decide
whether it is required and read only, also when they say no: a field listed
with
url
alone is not required in the backend, whatever the TCA of the
job table or a TCA override of a site package says.
A field the job has no property for is left out of the check of a submitted job, and a field the job table has no column for is left out of the backend.
Points to be aware of
readonlyanddisableddo not lock a field in the new job form. The form keeps offering it and stores what is submitted. They lock the field for backend editors, so what a visitor entered stays as it is.numbersets the type of the backend field as well, and saving a record then stores the value as a whole number:+49 30 123becomes49. Do not use it for a field holding text such as a phone number,telis the flag for that. The settings of 2.x marked the contact phone withnumber, so check a copy of them.requiredon a field stored as a number, such as the job type and the employment type, refuses0. That is the value the Please choose option of their selects submits, so0cannot be a value an integrator offers for a required select.
Overriding the settings
Settings are collected from all installed extensions. Every package that
contains Configuration/ contributes, in
package loading order, and a later package changes only the fields it names.
To change them for an installation:
- Add
Configuration/to your site package with the fields you change, and nothing else.Academic Jobs/ Settings. yaml - Make the site package depend on academic_jobs in its
composer.orjson ext_, so that it is loaded after it.emconf. php - Flush the TYPO3 caches. The settings and the compiled TCA are cached, and a changed file has no effect until the cache is cleared.
validations:
job:
# The flags of a field are replaced as a whole.
companyName:
- required
- readonly
# An empty list drops every flag: optional everywhere.
description: []
# `~` removes the field: the backend keeps what the TCA says.
link: ~
There is no TypoScript and no site set equivalent for these settings.
Changing the backend after the settings
The flags reach the backend through a listener of
\TYPO3\ with the
identifier academic-. It runs after every
Configuration/ file, so a TCA override of
required
or
read on a configured field does not survive it.
A site package that has to differ there either changes the settings file, or, for what the flags cannot say, orders a listener of its own after that identifier. A field that is required in the form and optional in the backend is such a case:
<?php
declare(strict_types=1);
namespace MyVendor\MySitepackage\EventListener;
use TYPO3\CMS\Core\Attribute\AsEventListener;
use TYPO3\CMS\Core\Configuration\Event\AfterTcaCompilationEvent;
/**
* The new job form demands a company name, backend editors may leave it
* empty, for a job an editor enters for the institution itself.
*/
final class CompanyNameOptionalInTheBackend
{
#[AsEventListener(
identifier: 'my-sitepackage/company-name-optional-in-the-backend',
after: 'academic-jobs/apply-settings-to-tca',
)]
public function __invoke(AfterTcaCompilationEvent $event): void
{
$tca = $event->getTca();
$tca['tx_academicjobs_domain_model_job']['columns']['company_name']['config']['required'] = false;
$event->setTca($tca);
}
}
The identifier is public API, the listener class is not.