Thursday, March 14, 2019
4 changes · master
Enhancements to existing features
Sales teams can now select an existing project directly on a sales order when selling services that create tasks. This lets the order create tasks in the chosen project instead of always creating a new project, while keeping existing behaviors for other service tracking options unchanged.
Original PR description
Purpose ======= The 'service_tracking' selection field on the 'product.template' model in the 'sale_timesheet' module had its 'task_new_project' option renamed to 'task_in_project'. If one or more…
Purpose
=======
The 'service_tracking' selection field on the 'product.template' model in the 'sale_timesheet' module
had its 'task_new_project' option renamed to 'task_in_project'.
If one or more sale_order_line have a product configured with this option, a new 'project_id' field appears
on the sale_order under the 'Sales Information' section.
When a project_id is selected, the analytic account on the sale order is automatically changed
to this project's analytic account.
This allows handling more use cases on sale_order:
- If a sale_order_line has a service product with that new option and no project_id configured on the sale_order:
-> create a new project based on the configured project_template_id and then create a task in that project
(same behavior as before)
- If a sale_order_line has a service product with that new option and a project_id is configured on the sale_order:
-> directly create a task in the selected project_id
The behavior does not change for the 3 other options ('no', 'task_global_project' and 'project_only').
Specs
=======
- Add project field on sale order in "other infos" tab, shows only when a product on the SO has the option activated
- If projec is selected on SO, create task in this project, otherwise it creates a new project (as before)
- Rename 'task_new_project' into "task_in_project"
- Allow to have the new option with project template
- Selectable projects on Sales Order are `billate_type` in 'no' and 'task_rate'
- Never link SO's project to SO or AA
- Add onchange on project_id to select this project's analytic account on the SO
- Non stored computed field to check if at least one SOL has the new option
Use cases
- 2 SOL with new option (no template) will create 2 tasks in SO's project
- 2 SOL with new options (one no template, one with) + 1 SOL "create new P no T" --> create 2 tasks in SO's project and one new project
Task #1915660Kanban cards now use view-specific markers before applying special opening behavior, reducing cases where records open in the wrong view when accessed from different places such as mobile selection screens. This improves consistency across apps including Project, HR Gamification, Manufacturing, Stock, and Mass Mailing, while removing an unused Mass Mailing script.
Original PR description
Improve all KanbanRecord.include -> _openRecord, currently we have model based condition which may create an issue when same kanban is opened from other place and kanban record is clicked, e.g. consider task: https://www.odoo.com/web#id=1924779&action=333&active_id=131&model=project.task&view_type=form&menu_id=4720 Here we will open kanban view instead of listview in mobile m2o, so this only model based condition may create issue even if we have separate kanban form m2o mobile, so added class on kanban element and check if that class is available then and only then perform a specific action. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users now see more specific messages when invoice document extraction fails, instead of a generic error. This helps them understand what went wrong and decide what action to take next, reducing confusion and support effort.
Original PR description
Before this commit, the only error message displayed to the user was 'An error occurred'. Now we handle the different errors sent by the IAP server and display an error message accordingly.
Kanban records in Manufacturing Work Orders, Sign, and Barcode now use page-specific markers before triggering special opening behavior. This helps prevent the wrong view or action from opening when the same type of record appears in different places, especially on mobile.
Original PR description
Improve all KanbanRecord.include -> _openRecord, currently we have model based condition which may create an issue when same kanban is opened from other place and kanban record is clicked, e.g. consider task: https://www.odoo.com/web#id=1924779&action=333&active_id=131&model=project.task&view_type=form&menu_id=4720 Here we will open kanban view instead of listview in mobile m2o, so this only model based condition may create issue even if we have separate kanban form m2o mobile, so added class on kanban element and check if that class is available then and only then perform a specific action.