›
›
›
  1. docs
  2. ›
  3. byrcsc/laravel-checklist
1.x
Browse documentationOpenClose

Getting started

  • Introduction
  • Installation and setup
  • Quick start

Core concepts

  • Templates and versions
  • Items and sections
  • Checklist lifecycle
  • Answers and evidence
  • Conditional rules
  • Scoring
  • Recurring schedules
  • Audit history

Operations

  • Author a template
  • Run a checklist
  • Create a schedule
  • Customize notifications
  • Export and report
  • Verify audit history
  • Composing with sibling packages

Reference

  • Configuration
  • Builder API
  • Models and scopes
  • Events and notifications
  • Console commands
  • Enums and contracts
  • Testing
  • Troubleshooting

Getting started

  • Introduction
  • Installation and setup
  • Quick start

Core concepts

  • Templates and versions
  • Items and sections
  • Checklist lifecycle
  • Answers and evidence
  • Conditional rules
  • Scoring
  • Recurring schedules
  • Audit history

Operations

  • Author a template
  • Run a checklist
  • Create a schedule
  • Customize notifications
  • Export and report
  • Verify audit history
  • Composing with sibling packages

Reference

  • Configuration
  • Builder API
  • Models and scopes
  • Events and notifications
  • Console commands
  • Enums and contracts
  • Testing
  • Troubleshooting

byrcsc/laravel-checklist · 1.x

Conditional rules.

Rules add answer-dependent requirements and visibility without deleting answers that stop applying.

Conditional rules let one answer affect the work around it. A requirement rule asks for supporting material; a visibility rule decides which later items or sections still apply.

Requirement rules add completion checks

$builder->passFail('No fluid leaks')
    ->requireEvidenceWhen('fail', 'photo');

$builder->yesNo('Any body damage?')
    ->requireNoteWhen(true);

The answer is accepted first. If its requirement is unmet, the package dispatches RequirementsUnmet. Submission remains blocked until the response has the required note or evidence type.

Changing the answer so the condition no longer matches removes the requirement.

Visibility rules target keys

Name an item or section, then point a rule at that key:

$builder->yesNo('Any body damage?')
    ->showWhen(true, 'damage-details');

$builder->section(
    'Damage details',
    function (TemplateBuilder $builder): void {
        $builder->text('Describe the damage')->required();
    },
    key: 'damage-details',
);

A target with at least one showWhen() rule starts hidden. It becomes visible when any show condition matches, unless a matching hideWhen() rule hides it. Hide wins over show.

Hiding a section hides all nested sections and items. A rule whose source item is itself hidden does not drive visibility.

Operators compare stored answer shapes

OperatorMeaningSupported source types
Equalsanswer equals one valueevery item type
Inanswer equals one value in a listevery item type
Belownumeric answer is below a valuenumber, rating
Abovenumeric answer is above a valuenumber, rating
use ByRcsc\LaravelChecklist\Enums\RuleOperator;

$builder->number('Temperature')
    ->requireNoteWhen(0, operator: RuleOperator::Below);

Builder-authored comparisons are cast through the source item's handler. For example, a pass/fail comparison of 'fail' is stored as false.

Text equality remains textual, so '0100' does not equal '100'. Number answers compare numerically.

Hidden answers stop counting everywhere

When an answer becomes hidden, it remains stored but changes to is_applicable = false. The package excludes it from required-item checks, requirement checks, scores, critical failures, and failed-item reports.

Each flip dispatches VisibilityChanged after ItemAnswered. The event and audit order therefore explain which answer caused the branch to change.

Publication rejects ambiguous rule graphs

Keys must be unique within the version. Rules cannot target their own source, point outside the version, or form a visibility cycle. Two items that hide one another are rejected, as is a longer closed loop.

These checks run during first publication and every later publication.

What to read next

  • Author a template for complete rule-building examples.
  • Scoring to see how hidden answers change denominators.
  • Events and notifications for requirement and visibility event payloads.
PreviousAnswers and evidenceNextScoring
View source

On this page

  1. Requirement rules add completion checks
  2. Visibility rules target keys
  3. Operators compare stored answer shapes
  4. Hidden answers stop counting everywhere
  5. Publication rejects ambiguous rule graphs
  6. What to read next