ModifyBiteJobPostingsRequestEvent 

\FGTCLB\AcademicBiteJobs\Event\ModifyBiteJobPostingsRequestEvent is owned by this extension. A listener changes the request the job list sends to the search API of B-ITE.

When it is dispatched 

The Job List b-ite dispatches the event each time it renders, after the request is built from the options of the content element and before it is sent. The payload a listener hands back is sent as it is, encoded as JSON. The result event follows once the response is decoded.

What a listener reads and changes 

Method Returns
getPayload() , setPayload() The request sent to the B-ITE search API, see the keys below.
getSettings() The values stored below settings.jobs in the plugin settings of the content element, which the payload is built from. They are not merged with TypoScript and not normalised, see Rules and pitfalls.
getRequest() The request of the page being rendered.
getPluginControllerActionContext() The context of the job list that asked, with all its settings, TypoScript included, or null when the service was called outside of a plugin.

The keys of the payload 

The extension sends these keys. A listener changes any of them and adds every other key the B-ITE search API accepts. Renaming or removing one of them in a later version is a breaking change.

Key Sent by the extension
key The job listing key of the content element, Job listing key.
channel 0.
locale de.
page offset 0: the postings from the first one on.
filter An empty filter: every posting of the job listing.
sort order and by, the sort direction and the sort field of the content element, Sort direction and Sort by.

Example: a custom field filter 

Up to version 2.0 the extension filtered by the B-ITE custom field zuordnung of one installation and grouped the postings by its value. Version 2.1 removed that code, see Breaking: Remove project specific custom fields. Two listeners bring it back for the installation that needs it, and only there. This one adds the filter to the request, the second one names the value of every posting for the grouping, see Example: a grouping by a custom field.

The value of the filter comes from a plugin setting of the project's own FlexForm, here settings.jobs.relation:

EXT:my_extension/Classes/EventListener/FilterJobsByRelation.php 
<?php

declare(strict_types=1);

namespace MyVendor\MyExtension\EventListener;

use FGTCLB\AcademicBiteJobs\Event\ModifyBiteJobPostingsRequestEvent;
use TYPO3\CMS\Core\Attribute\AsEventListener;

final class FilterJobsByRelation
{
    #[AsEventListener(identifier: 'my-extension/filter-jobs-by-relation')]
    public function __invoke(ModifyBiteJobPostingsRequestEvent $event): void
    {
        $relation = (string)($event->getSettings()['relation'] ?? '');
        if ($relation === '' || $relation === 'all') {
            return;
        }
        $payload = $event->getPayload();
        $payload['filter'] = ['custom.zuordnung' => ['in' => [$relation]]];
        $event->setPayload($payload);
    }
}
Copied!

Where the custom field sits in a posting, and which values it has, depends on how it is set up in B-ITE, so read one response of your job listing before relying on the path above.

The upgrade wizard academicBiteJobs_listViewFlexFormUpgradeWizard removes the setting settings.jobs.custom.zuordnung of version 2.0 from every job list, so a project FlexForm that brings the field back gives it a name of its own, as settings.jobs.relation above.

Rules and pitfalls 

The payload is sent as the listeners leave it. Nothing checks it against the B-ITE API. A payload B-ITE rejects makes the request fail, the failure is logged, and the list shows its empty state, unless a result listener adds postings.

The options of the content element are already in the payload. A listener that replaces sort or key overrides what the editor chose, so change them only where a project setting of its own asks for it.

The rules both events share are on the overview page.

Introduced in