Recruitment Reference Public

Administration and Controls

How administrators keep Recruitment secure and reliable: permissions, menus, settings, public pages, API surfaces, migrations, and change management.

Guide version: r2 Module version: 1.6.0 Updated: 2026-07-22 Estimated time: 5 min 1 views
User Manual

Administration and Controls

How administrators keep Recruitment secure, configured, and reliable.

Slug: recruitmentVersion: 1.4.0Category: Human ResourceReviewed: 2026-07-16

Access and Permissions

Start with least-privilege access. Give users only the permissions required for their actual responsibilities, then test using a non-admin account.

  • recruitment
  • manage_recruitments
  • manage_applicants
  • job_offer
  • job_position
  • recruitment_create
  • recruitment_update
  • recruitment_delete
  • recruitment_category
  • recruitment_category_create
  • recruitment_category_update
  • recruitment_category_delete
  • job_offer_create
  • job_offer_update
  • job_offer_delete
  • job_position_create
  • job_position_update
  • job_position_delete
  • recruitment_seo (Manage SEO — opens the SEO & Google for Jobs editor on job postings; administrators always have it)
  • recruitment_analytics (View Analytics — opens the Posting Analytics scorecard on job postings)

Settings, Menus, and Configuration

Configuration files found

  • api_routes.php
  • api_scope.php
  • control_tokens.php
  • default_menu.php
  • menu.php
  • module_config.php
  • permissions.php
  • routes.php
  • settings.php
  • system_logs.php

Menu entries found

  • Recruitment
  • Job Postings
  • Job Positions
  • Job Portal

SEO, Analytics, and Indexing Settings

Version 1.4.0 introduces nine settings that control the job SEO, analytics, and search-engine notification features. All are read with safe defaults, so the features work with zero configuration. There is no settings screen yet; an administrator can add a value to the tenant settings table when a different behavior is needed.

Tenant settings and defaults

  • job_default_valid_days (default 30) — days after publishing used to auto-set a posting's application deadline when the form leaves it blank; 0 disables the automatic deadline.
  • job_analytics_enabled (default on) — master switch for counting job-page views and applications.
  • job_analytics_view_throttle_minutes (default 30) — repeat views by the same visitor within this window count as one view.
  • job_analytics_event_retention_days (default 90) — how long raw view and apply events are kept before automatic deletion; anonymous daily totals are kept.
  • job_indexing_enabled (default on) — master switch for search-engine notifications when postings publish or close.
  • job_indexing_indexnow_enabled (default on) — enables IndexNow pings to Bing, Yandex, and AI crawlers.
  • job_indexing_google_enabled (default on) — enables pings through the Google Indexing API.
  • google_indexing_daily_cap (default 180 per day) — the daily Google ping budget, shared across all tenant companies because it draws on a single Google project quota.
  • job_indexing_batch_size (default 50) — how many queued notifications are sent per 15-minute dispatch run.

Deploy-level credentials (server environment)

Two credentials belong in the server's .env file — never in tenant settings:

  • INDEXNOW_KEY — the IndexNow key. The matching key file must also be published at the portal address as {portal-url}/{key}.txt (place the .txt file in the site's public web folder).
  • GOOGLE_INDEXING_SA_JSON — a Google Cloud service-account key. The service account's email address must be added as an Owner of the job portal property in Google Search Console.

If a credential is missing, the related pings are simply marked "skipped" and search engines still discover postings through the jobs sitemap — nothing breaks.

Visitor Privacy Controls

Job-page analytics is built privacy-first. The rules below are the module's data-protection posture toward public job-page visitors — they are always on and require no configuration.

  • No cookies are set on visitors to public job pages.
  • A visitor is recognized within a single day only, using an irreversible code derived from their network address and browser that rotates daily.
  • Network address, browser details, and referrer are stored one-way hashed; only the referring site's name is kept readable.
  • No user identity is ever attached to public job-page views, even when a staff member is signed in.
  • Browsers that send Do Not Track or Global Privacy Control signals are not counted at all.
  • Search-engine and AI crawlers can still read the page but are logged separately and never counted as views; browser preloading is also ignored.
  • Repeat views by the same visitor within 30 minutes count once, and "unique views" means the first-ever view of that job by that visitor.
  • Raw view events are deleted after 90 days; only anonymous daily totals are retained for the charts.

Automation and Integrations

Scheduled jobs

4 jobs found, all running per tenant. Each skips cleanly until the module's database updates have been applied. Review cron, job setting gates, and last-run evidence.

  • recruitment_retention_purge — daily at 03:00 — purges recruitment data that has passed its retention window.
  • recruitment_aggregate_job_analytics — hourly at :20 past the hour — rolls raw job-page view and apply events into the daily totals that power the analytics charts.
  • recruitment_expire_job_postings — daily at 01:15 — closes open postings whose application deadline has passed (recorded with the reason "expired").
  • recruitment_dispatch_job_indexing — every 15 minutes — sends queued search-engine notifications with automatic retries.

Dashboard widgets

No dashboard widget registration was detected.

Public pages

Public, portal, guest, or verification routes/configs were detected. Test while logged out.

API surfaces

API config files found: api_routes.php, api_scope.php.

Seeders

Seeder files found: RecruitmentOpenJobsSeeder.php. Use them only for the data purpose documented by the module.

Tests

Module tests found: RecruitmentTest.php.

Administrative Controls Checklist

  • The module toggle is enabled only for tenants or environments where the workflow is approved.
  • Role permissions are assigned by responsibility, not by convenience.
  • Menu entries, default menu entries, and routes point users to the intended module-owned screens.
  • Users know who is allowed to change settings, templates, status rules, and delete actions.
  • Migrations are applied and table changes are verified in the target tenant context.
  • API routes, filters, examples, scopes, and docs are reviewed after any data model change.
  • Public pages are reviewed for privacy, accuracy, and brand consistency.
  • Holders of the recruitment_seo and recruitment_analytics permissions are reviewed periodically so only current recruiting staff can edit SEO settings or view posting analytics.
  • After each deployment, the search-engine credentials (IndexNow key file and Google service account) are verified and the jobs sitemap is confirmed reachable and registered.

Change Management

  1. Announce workflow or permission changes before they affect live users.
  2. Update module README, CHANGELOG, and this guide when a workflow changes.
  3. For menu, route, permission, widget, API, or migration changes, validate the module from a non-admin account.
  4. Keep public pages, API examples, dashboard widgets, and scheduled jobs aligned with the real data model.
Was this guide helpful?

Report a content problem