Validation settings 

Configuration/AcademicJobs/Settings.yaml 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
Copied!

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: companyName is the column company_name . 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 

  • readonly and disabled do 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.
  • number sets the type of the backend field as well, and saving a record then stores the value as a whole number: +49 30 123 becomes 49. Do not use it for a field holding text such as a phone number, tel is the flag for that. The settings of 2.x marked the contact phone with number , so check a copy of them.
  • required on a field stored as a number, such as the job type and the employment type, refuses 0. That is the value the Please choose option of their selects submits, so 0 cannot 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/AcademicJobs/Settings.yaml contributes, in package loading order, and a later package changes only the fields it names.

To change them for an installation:

  1. Add Configuration/AcademicJobs/Settings.yaml to your site package with the fields you change, and nothing else.
  2. Make the site package depend on academic_jobs in its composer.json or ext_emconf.php, so that it is loaded after it.
  3. Flush the TYPO3 caches. The settings and the compiled TCA are cached, and a changed file has no effect until the cache is cleared.
EXT:my_sitepackage/Configuration/AcademicJobs/Settings.yaml
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: ~
Copied!

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\CMS\Core\Configuration\Event\AfterTcaCompilationEvent with the identifier academic-jobs/apply-settings-to-tca. It runs after every Configuration/TCA/Overrides file, so a TCA override of required or readOnly 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:

EXT:my_sitepackage/Classes/EventListener/CompanyNameOptionalInTheBackend.php
<?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);
    }
}
Copied!

The identifier is public API, the listener class is not.