Odoo-Modules/fusion_plating/fusion_plating/__manifest__.py

# -*- coding: utf-8 -*-
# Copyright 2026 Nexa Systems Inc.
# License OPL-1 (Odoo Proprietary License v1.0)
# Part of the Fusion Plating product family.

{
    'name': 'Fusion Plating',
    'version': '19.0.22.1.0',
    'category': 'Manufacturing/Plating',
    'summary': 'Core plating / metal finishing ERP: facilities, processes, tanks, baths, jobs, operators.',
    'description': """
Fusion Plating — Core
=====================

Part of the Fusion Plating product family by Nexa Systems Inc.

Fusion Plating is a configurable, multi-tenant capable ERP for plating and metal
finishing shops. This core module provides the process-agnostic foundation that
every shop needs regardless of size, process mix, jurisdiction, or industry.

The core ships intentionally empty of region-specific or process-specific
content — that comes from add-on modules:

* fusion_plating_process_en — Electroless nickel plating
* fusion_plating_process_chrome — Chrome coating (hex or trivalent)
* fusion_plating_process_anodize — Aluminum anodizing (Type II, III)
* fusion_plating_process_black_oxide — Black oxidizing
* fusion_plating_quality — QMS (NCR, CAPA, calibration, CoC, doc control)
* fusion_plating_compliance — Generic compliance framework
* fusion_plating_compliance_on — Ontario regulatory pack
* fusion_plating_compliance_tor — Toronto Ch. 681 municipal pack
* fusion_plating_safety — SDS, WHMIS/TDG training, JHSC, exposure
* fusion_plating_shopfloor — Tablet operator stations, QR scanning
* fusion_plating_portal — Customer portal
* fusion_plating_aerospace — AS9100 + Nadcap AC7108 pack
* fusion_plating_nuclear — CSA N299, CNSC, NQA-1 pack
* fusion_plating_cgp — Controlled Goods Program pack
* fusion_plating_logistics — Pickup & delivery
* fusion_plating_culture — Values / fundamentals framework

Core concepts
-------------
* Facility — a physical site with its own tanks, operators, compliance profile
* Process Type — extensible taxonomy of finishing processes
* Work Center — production line or station within a facility
* Tank — physical vessel with QR code and state
* Bath — the chemistry currently in a tank, with its own lifecycle
* Bath Log — daily chemistry readings with pass/fail vs target
* KPI — configurable headline metrics per shop
* Delegation Inbox — single pane of "things waiting for someone"

Design principles
-----------------
1. No client-specific strings in core.
2. No region-specific data in core.
3. No process-specific chemistry in core.
4. Works on both Odoo Community and Enterprise editions.
5. Theme-aware: respects user light/dark mode preference.
6. Multi-facility, multi-company, multi-currency capable.

Copyright (c) 2026 Nexa Systems Inc. All rights reserved.
    """,
    'author': 'Nexa Systems Inc.',
    'website': 'https://www.nexasystems.ca',
    'maintainer': 'Nexa Systems Inc.',
    'support': 'support@nexasystems.ca',
    'license': 'OPL-1',
    'price': 0.00,
    'currency': 'CAD',
    'depends': [
        'base',
        'mail',
        'contacts',
        'product',
        'stock',
        'sale_management',
        'purchase',
        'hr',
        'uom',
    ],
    'data': [
        'security/fp_security.xml',
        'security/fp_security_v2.xml',
        'security/ir.model.access.csv',
        # Menu visibility — loads after fp_security_v2.xml so the role
        # group xmlids exist when we add office_user to their
        # implied_ids. Loads after fp_menu.xml in spirit BUT references
        # cross-module menus (calendar, sale, hr, etc.) which exist by
        # the time fusion_plating loads, so safe to load here at
        # security-config time.
        'security/fp_menu_visibility.xml',
        'data/fp_landing_data.xml',
        'data/fp_sequence_data.xml',
        'data/fp_job_sequences.xml',
        'data/fp_numbering_sequences.xml',
        'data/fp_process_category_data.xml',
        # fp_menu.xml MUST load early — defines menu_fp_root, menu_fp_config,
        # menu_fp_compliance_hub, plus the 7 Phase-2 Configuration sub-folder
        # buckets. Every other view file (in this module and downstream)
        # that creates a child menu under those buckets references them
        # by xmlid, which has to already exist at parse time.
        'views/fp_menu.xml',
        'views/fp_process_type_views.xml',
        'views/fp_work_center_views.xml',
        'views/fp_tank_views.xml',
        'views/fp_bath_log_views.xml',
        'views/fp_facility_views.xml',
        'views/fp_bath_views.xml',
        'views/fp_process_node_views.xml',
        # Sub 14b — fp.step.kind catalog. MUST load before
        # fp_step_template_data.xml (templates reference kinds via
        # kind_id) AND before fp_step_template_views.xml (the form
        # references the kind action menu).
        'views/fp_step_kind_views.xml',
        'data/fp_step_kind_data.xml',
        'views/fp_step_template_views.xml',
        'views/fp_rack_tag_views.xml',
        'views/fp_job_step_move_views.xml',
        'views/fp_job_step_timelog_views.xml',
        'views/fp_rack_views.xml',
        'views/fp_bath_replenishment_views.xml',
        'views/fp_operator_certification_views.xml',
        'views/res_config_settings_views.xml',
        'views/fp_landing_views.xml',
        # Phase F — Owner-only Team page + Designated Officials on res.company.
        # Both reference menu_fp_config (Configuration root) and Phase 1
        # role groups, all loaded earlier (fp_menu.xml + fp_security_v2.xml).
        'views/fp_team_views.xml',
        'views/res_company_views.xml',
        'views/fp_work_centre_views.xml',
        'views/fp_job_views.xml',
        'views/fp_job_step_views.xml',
        'views/fp_jobs_menu.xml',
        'data/fp_work_role_data.xml',
        'views/fp_work_role_views.xml',
        # Starter recipes are NOT in 'data' on purpose. They get
        # loaded once via post_init_hook → _seed_starter_recipes_once
        # so user edits / deletions survive every -u upgrade. Putting
        # them back here would re-create deleted nodes on every
        # module upgrade (the noupdate="1" flag only blocks UPDATE,
        # not CREATE-when-missing — Odoo treats a missing ir.model.data
        # record as "needs creating").
        # 'data/fp_recipe_enp_alum_basic.xml',
        # 'data/fp_recipe_enp_steel_basic.xml',
        # 'data/fp_recipe_enp_sp.xml',
        # 'data/fp_recipe_general_processing.xml',
        # 'data/fp_recipe_anodize.xml',
        # 'data/fp_recipe_chem_conversion.xml',
        'data/fp_step_template_data.xml',
        # Phase H — Owner-approval migration workflow.
        # Views file declares the action + menu; cron declares the
        # daily 30-day expiry purge. Both reference model_fp_migration_preview
        # which Odoo's model autoload makes available before data load.
        'views/fp_migration_views.xml',
        'data/fp_migration_cron.xml',
    ],
    'post_init_hook': 'post_init_hook',
    'assets': {
        'web.assets_backend': [
            'fusion_plating/static/src/scss/fusion_plating.scss',
            'fusion_plating/static/src/scss/recipe_tree_editor.scss',
            'fusion_plating/static/src/scss/fp_chatter_dark.scss',
            'fusion_plating/static/src/scss/simple_recipe_editor.scss',
            # Sub 14b — visual icon picker for fp.step.kind etc.
            'fusion_plating/static/src/scss/fp_icon_picker.scss',
            'fusion_plating/static/src/xml/recipe_tree_editor.xml',
            'fusion_plating/static/src/xml/simple_recipe_editor.xml',
            'fusion_plating/static/src/xml/fp_icon_picker.xml',
            'fusion_plating/static/src/js/recipe_tree_editor.js',
            'fusion_plating/static/src/js/simple_recipe_editor.js',
            'fusion_plating/static/src/js/fp_icon_picker.js',
        ],
    },
    'demo': [
        'data/fp_demo_data.xml',
        'data/fp_demo_recipe_data.xml',
    ],
    'images': ['static/description/icon.png'],
    'installable': True,
    'auto_install': False,
    'application': True,
}