Developer Guidelines

1. Follow Standard Odoo Structure

Always follow the standard Odoo module structure when creating new modules, including folder organization, filenames, class naming, and method patterns.

Reference standard Odoo modules such as Sales, Account, Purchase, or Inventory (Stock) as examples of best practices.

Keep your code consistent with Odoo’s conventions to make it easier for others to maintain and upgrade.

2. Maintain Consistent PDF Report Structure

When developing new PDF reports, follow the structure of standard reports such as the Sales Quotation or Customer Invoice, unless a client specifically requests a different layout.

Avoid creating separate paper formats for every custom report unless it’s absolutely necessary.

Reuse existing templates, styles, and QWeb layouts whenever possible to ensure consistency.

3. For any implementation, Always review standard Odoo modules for similar functionality and implement accordingly.

4. Avoid Unnecessary Method Overwrites

Do not overwrite Odoo core methods unless absolutely required.

Prefer using inheritance, method extension (super()), or custom hooks instead.

If overwriting is unavoidable, clearly comment the custom code block, explaining the reason.

5. Use Separate Modules for Distinct Functionalities

Organize custom features into modular, independent components.

Avoid placing all customizations into a single large module.

Example naming conventions:

customername_sales

customername_account

customername_purchase

For Project Managers

1. Assign Tasks Project-Wise

Assign developers to projects in a structured and consistent way to ensure accountability and code ownership.

For example, if there are 4 developers and 8 active projects:

Developer 1 → Project 1 & 2

Developer 2 → Project 3 & 4

Developer 3 → Project 5 & 6

Developer 4 → Project 7 & 8

If a project has a tight timeline or high workload, add a second developer — but limit to two developers per project.

When assigning multiple developers, split responsibilities by functionality or workflow (e.g., one handles Sales, another handles Accounting).

2. Maintain Developer Ownership

The developer who worked on an initial feature or module should handle all follow-up changes, bug fixes, and extensions related to that area.

This ensures continuity, accountability, and faster turnaround, as the original developer is already familiar with the logic and dependencies.

3. Avoid creating too many tasks

As we now follow a task-wise Git branching strategy, avoid creating too many small or fragmented tasks that lead to excessive branch overhead.

Group related minor changes into a single task.

4. Enforce Timely Client Testing

Encourage clients to test as soon as tasks are deployed to staging.

Maintain a strict limit — no more than 10 pending tasks in staging.

Push to move validated tasks to production quickly to reduce backlog and avoid staging inconsistencies.

If clients consistently delay testing, pause new implementations if possible, and communicate the impact clearly to the client.

GitHub

1. Don’t Create Branches from the Staging Branch