Worklist conditions: service + contact role presence/absence

Objective

• Support worklist rules that combine which services are on the job (for example services contains home inspection) with whether a given contact role is present or missing on the order.
• Give operations QC-style lists for incomplete contact coverage before inspection day, without relying on manual review.
• Reduce mistakes when specific roles (for example Buyer’s Agent, listing agent / “missing LA”) must be present or absent for routing and quality control.

Background

• Schedulers and QC need existence / absence semantics for contact roles on the job, not only “this role’s fields match X.”
• The same underlying capability supports “required contacts missing” scenarios: surfacing orders that are not ready because expected roles are unfilled.
• service-ids and contact-role-ids already participate in worklist filtering in attik-backend/src/routes/worklist.ts. Decision needed on the exact operators (for example role not present) and on how users combine service predicates with role predicates inside existing worklist condition groups.

Scope

Backend

• Worklist query building in attik-backend/src/routes/worklist.ts—including buildMongoCondition, post-population condition groups, handling paths such as contact-role-ids (for example mapping to people._roleId), and service-ids where conditions join or filter on charges/services—is the natural place for predicates that express role present/absent together with service membership.

Frontend

• Worklist definitions flow through attik-frontend/src/util/types/serverTypeCollection/worklist.ts and the work hub at attik-frontend/src/app/tools/work/[[...type]]/ (WorklistMenu, WorklistResolver). The editor should support the combined scenario (for example services contains home inspection AND contact role X is not present) without maintaining parallel ad hoc lists.
• Shared condition metadata in attik-frontend/src/components/conditions/templatingData.ts and Conditions.tsx may need to stay aligned if the same attributes surface outside worklists.
• Contact roles remain configured under attik-frontend/src/app/tools/settings/contact-roles/page.tsx.

References

• attik-backend/src/routes/worklist.ts
• attik-frontend/src/util/types/serverTypeCollection/worklist.ts
• attik-frontend/src/components/conditions/templatingData.ts
• attik-frontend/src/app/tools/settings/contact-roles/page.tsx

---

Prior issue bodies (archived verbatim)

ATT-1145

Objective

• Let schedulers and operators build rules and worklists that depend on whether a given contact role is present or missing on a job (for example Buyer's Agent or "missing LA" style cases).
• Reduce manual scanning and mistaken assumptions when critical roles are not on the order.

Background

• Product feedback calls for existence / absence semantics keyed by contact role, not only "this role's details match X."
• Worklists and condition builders already expose contact roles via paths such as the contact-role-ids attribute in attik-backend/src/routes/worklist.ts (mapped to people._roleId) and condition keys in attik-frontend/src/components/conditions/templatingData.ts; the gap is treating role presence vs absence as an explicit, easy-to-configure condition.

Scope

Backend

• Worklist query building and condition evaluation in attik-backend/src/routes/worklist.ts is the natural place for any new Mongo or post-population filters that must include or exclude jobs based on whether a role is filled.

Frontend

• Shared condition UIs (attik-frontend/src/components/conditions/Conditions.tsx, templatingData.ts, and service modifier flows under src/app/tools/settings/services/[id]/Modifier/) may need the same concept if "role exists / missing" should appear outside worklists.
• Contact role definitions that users assign remain managed under attik-frontend/src/app/tools/settings/contact-roles/page.tsx.

References

• attik-backend/src/routes/worklist.ts
• attik-frontend/src/components/conditions/templatingData.ts
• attik-frontend/src/app/tools/settings/contact-roles/page.tsx

---

Original description

Ex. Does Buyer's Agent exist on job

Additional request: support role-based conditions for missing role information such as "missing LA", so users can filter based on whether a specific role exists on the job.

ATT-1440

Objective

• Add worklist conditions that surface jobs where required contacts are missing (or conversely present) so QC can fix data before inspection day.

Background

• Teams need proactive lists for incomplete contact coverage on orders; manual review does not scale.

Scope

Backend

• Custom worklist filtering is implemented in attik-backend/src/routes/worklist.ts (buildMongoCondition, contact-role-ids / people paths, post-population condition groups).

Frontend

• Worklist configuration types in attik-frontend/src/util/types/serverTypeCollection/worklist.ts and the work UI under src/app/tools/work/[[...type]]/ (WorklistMenu, WorklistResolver) consume saved worklist definitions from the worklist API.

References

• attik-backend/src/routes/worklist.ts
• attik-frontend/src/util/types/serverTypeCollection/worklist.ts

---

Original description

Users want a worklist condition based on whether required contacts are present or missing on the order. The goal is to surface orders for quality control so all needed contacts are added before the inspection date.