Have something to say?
Spectora home inspection report: repeated create/archive cycles confuse staff
Objective Remove uncertainty for inspectors and office staff when a work order accumulates multiple generations of the same Spectora Home Inspection Report template (pattern seen: initial report → second created and archived → third remains active). Determine whether behavior is expected lifecycle (new Spectora report ids over time; Attik archives ids no longer in the API payload) that should be explained or surfaced differently, or a defect (duplicate active rows, bad matching, double sync). Background Coordinators report that the activity feed and reports area feel like duplicate versions of the same template, not a single clear line of history. Example pattern from activity logs (full excerpts in the doc below): a System line often adds “Home Inspection Report (spectora)” and in the same burst moves a prior row to archived; later another add appears, leaving staff unsure which row is authoritative. Repeated field pattern (7+ jobs): Home Inspection Report template created on the work order initially; days to weeks later a second copy of the same template is added and archived; hours to days later a third copy is added and not archived—leaving two copies of the same template visible on the work order (one active generation plus prior archived row(s) and/or two non-archived rows depending on sync timing). Programmed behavior (Attik): Spectora sync is centralized in getInspectionReportsAndRequired, which updates a report when a row already matches the Spectora report id, creates when no match exists, and archives existing rows whose _spectoraReportId is absent from the current Spectora report/attachment id set returned for that inspection—so multiple waves are plausible when Spectora’s payload exposes new report ids over the job life (schedule changes, inspector changes, republish, etc.). Decision needed after spike: treat as product/UX (consolidate messaging, activity copy, or “one slot per template”) vs data bug (two active same-slot rows, same id twice, or archive while Spectora still returns the old id). Repro materials and example jobs Activity logs (Google Doc) — original three jobs Job 1 — Attik activity feed (inspection 1008590172) Job 2 — Attik activity feed (inspection 1008589968) Job 3 — Attik activity feed (inspection 1008590109) Job 4 — Attik activity feed (inspection 1008581481) Job 5 — Attik activity feed (inspection 1008589712) Job 6 — Attik activity feed (inspection 1008576981) Job 7 — Attik activity feed (inspection
Bug: Inspection emails include unrelated CC address
An unrelated email address is being included as a CC on email actions for a specific work order, even though that address does not appear to be associated with the contact on the work order. For the inspection at 308 N Florence St, Aurora, Colorado 80010, complaints indicate that cah025@gmail.com is being included in inspection emails for christinal@rentgrace.com. Resend shows the address listed as a CC. The issue appears to persist across multiple notifications, and there is a request to verify whether the CC is originating from the system. Work order: inspection 1008577726 **Additional **user feedback: When searching cah025@gmail.com, inspections associated with Christina L. populate, but that email address does not appear to be associated with her profile in any visible way. Spectora also shows no record of that email address. Additional transcript context Apr 28 implementation transcript surfaced this again as an active bug pattern, not a one-off report. Related: Inconsistent inclusion of intended profile CC addresses (e.g. listing agent CC) on the same inspection is tracked in ATT-1443.
Bug: Quote hold blocks are not auto deleting on calendar
Hold blocks for quotes that expire are not automatically removed from the calendar. Affected example: quote 69cb04fc3e902051374eeb48.
Bug: Clearing the Reasoning Description in Online Service Filters does not persist after save
Objective Restore expected behavior when users clear the Reasoning Description (and optionally the Question for Children) on an Online Service Filter option: the saved value should persist as blank after save and refresh. Users expect that clearing an optional field and saving will result in that field remaining empty; currently the previous text reappears. Background In Settings → Scheduling → Online Service Filter, the Edit/Add Filter Option modal includes a "Reasoning Description" textarea. When a user clears this field, saves, and refreshes, the old text is still present; the clear does not persist. The save request succeeds and shows a success toast; the failure is that the backend never receives a value that means "clear this field," so the stored value is left unchanged. The same pattern may affect the optional "Question for Children" field if users clear it—same payload shape applies. Scope Frontend attik-frontend/src/app/tools/settings/scheduling/online-service-filter/ServiceFilterOptionModal.tsx — The modal holds description and question in local state and, on save, sends them as description.trim() || undefined and question.trim() || undefined. When the user clears a field, that becomes undefined and is omitted from the JSON body. The fix must ensure that when the user intends to clear a field, the backend receives an explicit value that means "clear" (e.g. empty string) so the stored value can be updated. The same consideration applies for both create and update payloads. Backend attik-backend/src/routes/serviceFilter.ts — The PUT /options/:id handler updates option.description and option.question only when the corresponding key is present in the request body (if (description !== undefined) option.description = description;). When the frontend omits the key (because it sent undefined), the backend does not change the field. No backend change is strictly required if the frontend starts sending an explicit empty string for "cleared" optional fields; the existing logic will then set the stored value to empty. If the team prefers the backend to treat a missing key as "clear," that would be a separate decision and would need to be applied consistently for optional string fields on this endpoint. attik-backend/src/models/serviceFilterOptionSchema.ts — The description and question fields are optional (required: false). Storing an empty string is valid and already supported. Decision Whether to fix only on the frontend (send empty string when user clears) or also change backend semantics for missing keys is a dev decision; the minimal fix is frontend-only. References Modal and save payload: attik-frontend/src/app/tools/settings/scheduling/online-service-filter/ServiceFilterOptionModal.tsx (handleSave, update and create payloads) Update endpoint: attik-backend/src/routes/serviceFilter.ts (PUT /options/:id) Option model: attik-backend/src/models/serviceFilterOptionSchema.ts
Bug: Fix agreement block spacing and undeletable last line
Objective Remove the visual glitch in the agreement template block editor where the last line of a block cannot be deleted and an extra blank line remains, causing a visible gap between blocks when viewing the contract. Make the spacing between blocks look clean and consistent so contract layout is not affected by editor behavior. Background Agreement templates are edited in the Attik tools area; each template is composed of blocks (e.g. text blocks) that are edited with a rich-text editor. Product feedback from the SW region (Mar 9, 2026) reports that when editing a block there is always a line after the text that cannot be removed: you can go down one more line after your text but cannot delete it. That leaves a visible gap between blocks when viewing the contract. The behavior is attributed to an editor/block glitch rather than intentional design; fixing it will improve the contract appearance and reduce confusion when building agreement templates. Scope Frontend Block editor: Text block content is edited in attik-frontend/src/app/tools/agreements/templates/[id]/AgreementTextBlock.tsx, which uses TipTapWithVariables for the rich-text field. The editor receives content (TipTap/ProseMirror JSONContent) and persists it via onContentChange; block UI and wrapper are in AgreementBlockWrapper.tsx (e.g. mb-2 space-y-4 for block spacing). Editor component: The shared editor lives in attik-frontend/src/components/tiptap/TipTapWithVariables.tsx, which uses TipTap with a Placeholder extension (emptyEditorClass, emptyNodeClass), default content, and editorProps. ProseMirror/TipTap often keeps a trailing empty paragraph or similar node so the doc always has a valid structure; that can both prevent deleting the "last" line and render as extra space. Preview / output: Agreement block content is rendered for preview in AgreementTextBlock.tsx via TextContentPreview and renderTipTapToHtml; the client-facing agreement view uses AgreementContent.tsx. Any fix should ensure that stored content does not include unnecessary trailing empty nodes that produce visible gaps, and/or that the editor allows users to remove the trailing line without leaving a visible gap in the final contract. In scope: identify why the last line of a block cannot be deleted (e.g. required empty node, key handling, or placeholder behavior) and why that produces a visible gap between blocks; then adjust editor behavior and/or content normalization so that (1) users can achieve the spacing they intend and (2) the gap between blocks is not dictated by an undeletable line. Backend Agreement block content is stored as JSON (e.g. content.jsonContent) on agreement template blocks; the backend serves and persists blocks via routes such as agreement/template/blocks. No change to the stored schema is required unless the fix involves normalizing or trimming content on save. Decision needed Whether to fix only in the editor (e.g. allow deletion of the trailing node when appropriate, or collapse it visually), and/or to normalize content on save or when rendering so that trailing empty paragraphs do not create a visible gap. The implementer can choose the approach that best fits TipTap/ProseMirror patterns and existing code. References Agreement template builder: attik-frontend/src/app/tools/agreements/templates/[id]/AgreementBuilderBase.tsx Agreement text block and wrapper:
Bug: Wrong report generating in Spectora Order
AJF 2552 E Villa Linda Dr Lot 70 - It appears that the NC Final service was originally on the Attik order but the home inspection report template generated in the Spectora workorder instead of the NC Final report template.
Bug: Text blocks in emails move to the bottom randomly
Text blocks and divider blocks randomly seem to get moved to the bottom of my emails. It even happens after I save an email sometimes.
Bug: Same Day Scheduling - slots in the past
When we enabled the same day scheduling function the inspector dispatch showed an option for a same day spot that was in the past (1 pm slot was shown as an option when it was already after 2 pm when the order was being created).