Maintenance process - odoo-ps/psbe-process GitHub Wiki

Find the tickets in the project PSBE - Maintenance.
Search for Unassigned tasks in stage New (PS).

0. Before starting a ticket, check:

   • if there is a Partner handling the client's database (Referrer in the subscription is different than the customer) and there is a Commission Plan. This means that Odoo is giving back the maintenance fee to the partner, which implies that the partner must handle the maintenance himself. In that case, ping the sale on the ticket to say that the partner should handle the ticket.
   • if the customer pays maintenance fees: check the customer's (or the customer's company) subscription for a Maintenance line.
   • if they are from our team (belgian sale team).
   • if the related development is in done status.

1. Assign yourself the ticket and move it to stage Analysis (PS).

2. When you start coding move the ticket to stage Development (PS).

0. Understand the issue (it's always better with a complete description from the customer, or a video). If necessary, ask for more information to the functional, the BA or the customer itself.

1. Try to reproduce the issue in a staging branch (if the project is on SH) or in a duplicated db (if the project is on SAAS)

2. Download the repo and a dump of the database.

   • If the project is on SAAS, the code could be in a branch on one of this repos:
     • https://github.com/odoo-ps/psbe-custom (best case scenario): look for a branch with the project's name and version
     • https://github.com/odoo/ps-custom : look for a branch with the project's name and version

3. Create a new branch to fix the issue.

4. Once the issue is fixed: commit, push and create a PR.

   • Remember the Commit guidelines: [FIX][TASK_ID] brief description

5. Once the PR is approved:

   • Push the fix to a staging branch (if the project is on SH) or import the module(s) to a duplicated db (if the project is on SAAS):
   • Move the ticket to stage Functional Testing (PS).
   • Let the BA/functional know the fix is ready to be tested
   • Inform where the fix has been push in case there are several staging branch on SH, or the duplicated db's name for SAAS
   • Inform the BA/functional them to tell the customer if the tests they made are okay.

6. If the customer gives the go-ahead:

   • Push the fix to prod
   • Move the ticket to stage Done (PS).
   • Leave a note in the ticket with a summary of the fix and the link to the commit/PR. This way the changes are easy to find/understand for everyone in the future.

• Upgrade the affected module's manifest version. This is particularly useful when changing xml files for SH projects because modules are automatically upgraded when pushing to staging/prod if they have a higher version. Otherwise, the module'll have to be upgraded manually.

• You can always ask for help if needed but remain responsible until the task is Done.

• Don't forget to Timesheet directly on the task