The principle of Saas task is that you can not change the flow of existing program, you can only add things on top of existing ones.

All Saas customizations are put on pshk-custom repository.

Do a git clone for pshk-custom and put it to your workspace directory (parent directory of odoo/, enterprise/, ...).

Open the task you're assigned to, read through the functional analysis and technical analysis written by the FC and TC.

You can approach the responsible FC and TC for further explanation on what they wrote.

Move the task to stage: Development

For every task, we like to keep a separate repository for each client so we can track what developments have we done for each client.

Your development should be stored in branch named: {odo-version}-{client_name}-{your trigram/quadgram} which should be based from a "main" client branch.

i.e. client name=odoo, main client branch: 14.0-odoo, git branch for development:14.0-odoo-nni.

Always checkout to your new dev branch based on the client branch. If the client branch is not created yet, create the client branch based off of main and then push it.

Technical analysis are usually in this format:

If you have the chrome extension tool for Odoo PS, you will be able to see 2 the 2 parts:

Export: ./export.py scaffold <target/path> <task_id>
Analysis Link

The most important part is the export command because it will scaffold a module with initialized project structure including its content.

cd psbe-ps-tech-tools
git pull
git checkout tools-exporter
./export.py scaffold <target/path> <task_analysis_id>

{target_path} should be the pshk-custom while {task_analysis_id} is the number on export command for technical analysis box.

In the task, the FC should be including link to client's Production/Test Database.

Because you are going to do your development locally, you also have to test it locally before actually deploying it to test/production database

Generally, fetch the production database because it should be the db you are merging your development into. Test database should usually have the same configuration as the production. If there are some customizations or existing data on test db, it may be good to fetch it from there. In any case, fetch from the suitable database.

cd /path/to/support-tools
./oe-support.py fetch {link_name}

{link_name} should be the database link, NOT INCLUDING THE https:// and extra request.

After fetching, you will be directed to the database name (usually labelled with oes_..), which you can use as the -d {dbname} to running odoo-bin.

For local development, you want to test your development by "deploying" it to the db. By doing

/path/to/odoo-bin deploy {module_name} --db {local_db_name}

There are people who like to do multi-commits during development to keep track of what he did on each section (as well as being to revert commits from one to another).

In Odoo PS, we like to limit commit to 1 per task so that it's easier to track module and its commits and branches. So for people who like to develop with multi commit, here is what you might want to do:

1. Branch out from your development branch to another "dev" branch. I.e. 14.0-odoo-nni => 14.0-odoo-nni-dev. git checkout -b {version}-{client-name}-{trigram/quadgram}-dev
2. Do your commits in this "-dev" branch. When you about to make commit for pull request, merge all commits into one".

git checkout {version}-{client-name}-{trigram/quadgram}
git merge {version}-{client-name}-{trigram/quadgram}-dev
git rebase HEAD~{num_commit}

You can learn more about commit squashing here. But instead of using "s"( squash ), we use fixup

Saas modules are to be exported to the database by converting the module to zip file. Upload the zip file later on to the testing database

cd /path/to/pshk-custom
zip -r {module_name}.zip {module_name}

And then go to Apps->Import Module->Upload .zip file of module->Done

The move your task to stage: Functional Testing and mention the Task Owner that development is ready to be tested.

Before pushing the code, change the commit message to something that is understandable by the reviewer.

If code is tested correctly, you have to do pull request in to ensure code quality.

1. Push the dev branch to repository

git checkout {version}-{client}-{trigram/quadgram}
git push origin HEAD

2. Go to pshk-custom repository and you should be able to see a orange box with "Compare and Pull Request" button. Click that.

3. Fill in the target merge branch, add pshk-quickstart-reviewer as one of the reviewer, and create the pull request.

Do the same process when you push to staging, but instead the zip module should be exported to the production database.