ENTERPRISE ENGINEERING / ODOO 16 · NUSATIV
Engineering complex Odoo workflows for enterprise construction risk management.
Odoo development: backend workflows, authentication, risk calculations and targeted web-client changes.
PROJECT AT A GLANCE
An Indonesian state-owned construction enterprise needed risk registers, assessments and project handover decisions to remain consistent with authorization and governance rules. The platform uses Odoo 16 Community with custom risk models and construction entities extending hr.department.
PRODUCT CONTEXT / DISCLOSED VISUALS
Edited from the supplied application screenshot using AI-assisted sanitization. Approval summaries, the risk matrix and severity groups retain the source interface structure; identities and operational values are replaced with synthetic data. This edited view establishes product context, not sole authorship of every dashboard widget.
SYSTEM ARCHITECTURE
Odoo BI → FastAPI / Pydantic → Vertex AI
Cloud Run deployment automation exists in code. This diagram does not assert a live cloud deployment.
The architecture is a conceptual explanation, not a production network map. Audit logging uses an independent cursor in the PostgreSQL database, not a separately verified audit server.
MY ENGINEERING CONTRIBUTIONS
Review actions: request → approve or reject → restart/resubmit. Returning PHO/FHO to Active requires the designated Super Admin role. The reviewed model extends hr.department, not project.project.
I implemented guarded Active → PHO → FHO transitions with tier validation. The workflow checks requester roles, requires completed reviews and records reviewer information in chatter. Rejection and resubmission are review actions; they are not extra project stages. Returning a PHO/FHO project to Active is restricted to the designated Super Admin role.
I implemented password complexity checks, expiry reminders and authentication hardening. Failed-login logging opens an independent PostgreSQL cursor with autocommit, so the audit write is separate from the authentication transaction that may roll back. Redirect validation and response headers address specific web-security concerns; these mechanisms are not a guarantee of complete vulnerability elimination or federated SAML/OAuth SSO.
I implemented a deterministic quantitative score selector: lower-inclusive, upper-exclusive intervals, with the greatest upper boundary included using floating-point tolerance. Matching is independent of record ordering; invalid limits, gaps and overlaps are rejected. Separate Odoo regression tests cover stored-versus-displayed exposure and protection of historical values.
I worked on risk-register deletion controls that distinguish a deletion request from approval. Role checks govern requests and decisions rather than allowing unrestricted destructive actions. Reviewed code and regression tests establish implementation; they do not establish final client acceptance.
I patched Odoo’s FormController to check for a risk-strategy warning after a successful save, using the ORM service and a non-blocking sticky notification. The change preserves the normal save flow; it is a focused web-client customization, not a frontend rewrite.
I implemented a FastAPI gateway with Pydantic request models, a sliding-window in-memory rate limiter and a Vertex AI integration component. Cloud Run deployment automation and tests are present. This demonstrates integration and deployment code; a successful staging or production cloud deployment was not verified.
PRODUCT CONTEXT / DISCLOSED VISUALS
The matrix makes likelihood and impact visible. The reviewed contribution concerns deterministic interval boundaries, exposure calculations and stored historical values. Illustrative marker positions do not demonstrate production outcomes.
PRODUCT CONTEXT / DISCLOSED VISUALS
The supplied interface shows impact series and monitoring charts. This AI-edited source view replaces operational values with synthetic demo units and anonymous categories. Dashboard context does not establish personal implementation of every chart; AI integration code does not establish a live deployment.
ENGINEERING DEEP DIVE
A separate cursor and autocommit decouple audit writes from the login transaction. This protects the intended audit path from the parent rollback; it does not make logging infallible or records immutable.
Login transaction → may roll back
Independent audit cursor → separate write
Interval selection rejects ambiguous configurations. Separate display and stored-value checks help protect historical records when calculation logic changes.
Exposure = impact scale × probability midpoint × 0.01 × risk limit
Attributable Odoo TransactionCase sources cover permissions, scoring and workflow transitions; Playwright browser-test sources are also present. Six isolated checks of the dependency-free impact selector passed during this review. The full Odoo, database and cloud integration suites were not run. Development and testing/QC evidence must not be read as final production acceptance.
QUALITY & EVIDENCE
Attributable workflow, authentication, scoring and web-client changes were checked against private source and Git history.
October 2026 development reported complete for stated scope, promoted to testing, followed by QC feedback. Final production acceptance is not established.
Private source and communications were reviewed for this case. No proprietary code, client records or raw messages are published. Review date: 29 October 2026.