Site Snag Lists
Site Snag Lists helps construction and fit-out teams record individual defects, assign repairs, retain before and after evidence, and verify the result. A contractor's submitted fix stays open until an inspector verifies and closes it. Rejected work starts another rectification attempt without removing earlier evidence.
Installation and edition
Install corvus_site_snag_lists from Apps on Odoo 20. Its direct standard dependencies are Project (project) and Mail (mail); Odoo installs their normal dependencies. Add the module directory to the server's configured addons path, refresh the Apps list and install Site Snag Lists. Back up your database and filestore before installation or upgrade.
Tested on Odoo 20 Enterprise: installation with and without demo data, focused workflow and access checks, and native HTML report rendering passed. Community has not been separately qualified. No Enterprise-only addon, hardware, external API, paid service or companion Corvus addon is required by this module. Do not install it on another Odoo major version.
The app supplies a snag numbering sequence and four editable trade references: finishes and decoration, doors and joinery, electrical, and plumbing. It does not create a live project, contractor account or outbound integration. Optional demo data creates the fictional Cedar Court refurbishment, two demonstration users, a linked inspection task and six defects. Demonstration users have no supplied password; do not use them as production accounts. Demo evidence is explicitly labeled original illustration, not a photograph of a real site.
Roles and visibility
An administrator assigns the Site Snag Lists privilege in Settings → Users:
- Operator reports and updates accessible snags, adds evidence, assigns repairs and submits fixes. Only the assignee or an inspector can submit a fix.
- Inspector includes Operator access and can start verification, verify and close, reject a fix or reopen a closed snag.
- Manager includes Inspector access, maintains trades, and may delete an unworked reported snag with no evidence or decisions. Worked snags must be retained.
These roles imply native Project user access. They do not grant Project administrator access. The native project's read permissions, the optional task's read permissions and the user's allowed companies restrict every snag, evidence image and decision. A snag Manager does not bypass a private project. Ask the Project administrator to grant legitimate project access when needed. Public and portal users receive no snag access.
Choose an internal assignee who has Operator access, can read the selected project and can use its company. Native project membership changes also change visibility of its snags. Evidence uses native image attachments linked to the protected photo record. The app adds no public photo links or access tokens.
Setup
- Open or create the native project through Project with an authorized project manager. Configure its visibility and team before sharing defects.
- Give the relevant staff their snag roles and allowed companies.
- In Site Snags → Configuration → Trades, review the supplied trades. Managers can add a trade, change its display order or archive it. A trade with no company is shared; a company-specific trade is usable only in that company.
- Review the Site Snag sequence in technical sequences if your administrator uses a different reference format. The default prefix is
SNG/and the numbering is shared across companies. - Agree operational meanings for Minor, Normal, Major and Critical severity. These values classify work; they are not safety approval or certification.
Report a defect
Open Site Snags → Defect Register → New. Enter a short defect title, project, site, zone, trade and severity. Link a task if relevant; it must belong to the selected project. The reported date defaults to today and cannot be in the future. Describe the defect and the expected repair, then save. The module assigns its reference and starts it as Reported.
The location fields distinguish, for example, Cedar Court from Ground floor / Reception. Use stable zone names for readable registers. The project and company can be changed only while Reported. Business details become read-only after closure; reopen first to make a correction.
Add before and after evidence
Use Evidence above the form or Defect and Photos → Add a line. Enter a useful caption, choose Before or After, and upload the image. The native image form adapts to the available screen; ordinary mobile browser access is supported by Odoo's native layout, with no separate mobile application or offline synchronization.
The original image is attached to its protected photo record and resized through native image fields. Uploads are associated with the current rectification attempt. Saved evidence images, captions and phases cannot be overwritten or deleted by the app's roles. If a photograph is incorrect, add a new captioned image that explains the correction. Do not upload personal or sensitive information that is unnecessary for defect rectification. Evidence retention follows the database and filestore backup policy chosen by your organization.
A current-attempt After image is required to submit a fix. At least one Before image is required before verified closure. Further supporting photographs can be added while the snag is open. Closed snags must be reopened before adding evidence. Chatter attachments are useful supplementary discussion; the explicit Before/After evidence records are what the workflow and closeout report use.
Assign one or several snags
For one snag, click Assign. For a batch, select rows in the Defect Register, then choose Actions → Assign Snags. Set an internal assignee and target date, review the selected records and click Assign All.
Every selected snag must be Reported, Assigned or Reopened. Every project and company must be accessible to the assignee. A mixed selection containing Fixed, Verification or Closed records fails as one operation; it does not partly assign the valid rows. Each assigned snag receives one append-only assignment note. After the first assignment, change the assignee or target date through Assign so the new decision is retained; direct edits and imports cannot bypass that history. A due date is a target, not an automatic escalation or transfer validation.
Fix, verify and close
The state path is Reported → Assigned → Fixed → Verification → Closed. Reopening branches from Fixed, Verification or Closed into Reopened, then assignment starts another repair attempt.
- The assignee completes the physical repair and uploads an After image for the current attempt.
- Click Submit Fix, keep the Submit Fix decision, enter the rectification details and confirm. The state becomes Fixed and the fix timestamp is recorded. The defect is still open.
- An Inspector opens Record Decision, chooses Start Verification, and records what will be checked. The state becomes Verification.
- After inspecting the work, the Inspector chooses Verify and Close, enters the result and confirms. The snag must have Before evidence. The state becomes Closed and the closure timestamp is recorded.
The module enforces roles, states and evidence on the server, including imports and API calls. Direct status edits are rejected. The inspector may also be the assignee if your organization's process permits it; this module enforces inspector authority, not mandatory separation into two different people.
Reject, reopen and correct
An Inspector can choose Reopen / Reject Fix from Fixed, Verification or Closed and must explain why. This clears the current fix/closure timestamps, increments the attempt number, returns the snag to Reopened and restores it to the open count. Earlier closure decisions, photos and timestamps in the inspection history remain intact.
Assign the reopened snag again, perform the rework, and upload a new After image. An image from an earlier attempt cannot satisfy the new fix. Repeat verification and closure. Use Inspection History to read all assignment, rectification, verification, reopening and closure notes in order. Decisions cannot be edited or deleted; add a new decision to explain a later finding.
Repeated closure, verification before a fix, and a fix without current evidence are rejected with an actionable message. If another user is updating the same snag, refresh after their operation and retry once the latest state is visible.
Worked example
At Cedar Court, report Reception wall joint crack on the refurbishment project and its finishes inspection task. Set the location to Ground floor / Reception, trade to Finishes and decoration, and severity to Normal. Describe the required joint repair and matching finish. Add a Before image with a caption locating the crack.
Assign the defect to Morgan Ellis with Friday's target date. Morgan repairs the joint, adds an After image and submits a fix with the materials and work details. Alex Reed starts verification, checks the adjoining joint in normal lighting, and closes the snag with a clear inspection result. Print the Defect Register and Closeout from the form.
If a crack reappears, Alex reopens it with the finding. The defect returns to the open count as attempt 2, with its first closure retained. Reassign it to Morgan and require a new After image before the second fix. The fictional demo includes both a completed repair and a reopened repair to illustrate these paths.
Registers, deadlines and analysis
The Defect Register shows identity, zone, trade, severity, assignee, target date, current age and state. Search by reference, title, project, site, zone, trade or assignee. Use Assigned to Me, Open, Awaiting Inspection, Overdue, Open 14+ Days or Closed to focus work. The column selector exposes attempt, company, activities and open/closed counts. Group by project, trade, state, severity or reporting week. Export follows normal Odoo permissions.
Current age is the calendar-day difference from the reported date to today, or to the latest closure for a closed record; it is not a working-day or SLA clock. Live age is displayed on records. Age and Severity groups stored counts by severity and reporting week and offers the 14-day aging filter. Open counts include Reported, Assigned, Fixed, Verification and Reopened. Only Closed contributes to closed counts. Archived records are excluded from normal actions; use the Archived filter when reviewing retained records.
Closed Defect Analysis is permanently restricted to Closed records. Its average Closeout Days measures calendar days from reporting to the latest verified closure, so open defects do not dilute the average. A reopened record leaves this action until closed again.
Switch the register to Calendar for target dates. Records without a target date are absent from the calendar. Set the initial target date on a Reported form; use Assign for later target-date changes. The form's native chatter supports manually scheduled Odoo activities and discussion; the addon does not automatically email contractors or create periodic reminder jobs.
Print the closeout report
Select one or several snags and choose Print → Defect Register and Closeout. The report begins with a register and the selected open/closed counts, followed by a detailed page for each defect with project, task, company, location, severity, assignee, dates, retained Before/After images and chronological inspection notes.
Native HTML report rendering has been verified. PDF output requires a configured, working native Odoo PDF engine and has not been qualified for this release.
The report includes all selected states and labels the current state explicitly. Printing does not approve or close anything. A selection must be accessible in full; the report does not reveal another project's records. Counts refer to the selected defects, not the entire site. The report records defect coordination, not statutory certification, general deliverable acceptance or contractor backcharges.
Upgrade and preservation
Back up the database and filestore together, update the addon in your Odoo 20 environment and review one existing open and one closed record. The numbering sequence and initial trade definitions are normal noupdate reference data intended to preserve user changes. Verify the sequence and trade settings after an upgrade before resuming work. Optional demo data does not replace production configuration. Keep archived trade definitions that are already referenced instead of deleting them.
The module supplies no destructive migration or scheduled cleanup of evidence. Uninstalling an addon is different from upgrading and can remove its business data; follow your organization's retention and backup procedure before any uninstall. No historical source, unrelated addon or external system is modified by installing this module.
Troubleshooting
- The app is missing: ask an administrator to assign Operator, Inspector or Manager access and refresh the session.
- A project or snag is missing: check allowed companies and native project/team visibility. The optional task must also be readable. Grant legitimate project access rather than broadening snag permissions.
- The assignee is rejected: ensure the person is an internal Operator, can read the project and has the snag company among their allowed companies.
- Submit Fix is rejected: assign the snag first, use its assignee or an Inspector, add an After image for the current attempt, and enter a note.
- Closure is rejected: an Inspector must first start verification; add a Before image and a meaningful closure note.
- Batch assignment fails: remove any Fixed, Verification or Closed row and check every project's assignee access. No part of the rejected batch is committed.
- An image cannot be edited: retained evidence is immutable. Add another captioned image; reopen a closed snag first.
- Counts differ from a printed report: the printout counts only its selected records. Check filters, archived records and allowed companies. Fixed and Verification are still open.
- The calendar omits a record: set its target date. Closed records may still appear unless you filter them out.
- A report image is absent: confirm the image is an explicit evidence record, not only a chatter attachment, and check the filestore restore. For PDF generation, ask your Odoo administrator to check the native PDF engine and report-server configuration; server PDF output has not been qualified.
Scope and support
This addon provides operational defect rectification and reinspection. It does not supply a plan-drawing engine, contractor portal, offline app, automatic contractor backcharges, commercial variation approval, safety certification or statutory compliance assessment. No external service is contacted by its business methods.
Copyright © 2026 Corvus Nexus Technologies LTD. Licensed under Odoo Proprietary License v1.0 (OPL-1). Support: support@corvusnexus.com. Company: https://corvusnexus.com. When requesting support, include your Odoo major version, module version, affected workflow and a sanitized error; do not send credentials or unnecessary site photographs.
Availability
This guide covers the Odoo 20 package. Older-version packages are not part of this release.