Daily updates from Odoo
Thursday, April 18, 2019
8 changes
Enhancements to existing features
Users can now set cover images in kanban cards beyond project tasks, making visual boards easier to scan and customize. This expands a previously project-specific option into a reusable capability for other Odoo kanban views when configured.
Original PR description
Task : https://www.odoo.com/web#id=32108&model=project.task&view_type=form&menu_id=5195 Pad : https://pad.odoo.com/p/r.ebf5ce9cae9fb8be3445445c7ddd17e5 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fleet now supports assigning a future driver to a vehicle while the current driver keeps using their existing car. This helps businesses manage vehicle replacement requests and preparation periods more clearly, with added tracking for employees planning to change cars and manager information on vehicle models.
Original PR description
Basically when someone requests a new car, getting that car ready takes some time, this means that during the waiting period, that person is still driving its old car. This commit adds a field future_driver_id on fleet.vehicle to tackle that problem and a boolean plan_to_change_car on the partner to track who wants to change car. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Payment journals created from Point of Sale are now automatically marked as available in PoS. Users who remove the PoS availability filter will correctly see all payment methods, making setup and review of payment options more reliable.
Original PR description
Before this commit, payment journal "Available in PoS" should not ticked by default if created from PoS. And if I remove the filter "Available in PoS", I should not see all payments methods. Now, payment journal "Available in PoS" is ticked by default if created from PoS. And if I remove the filter "Available in PoS", I should see all payment methods. Task: https://www.odoo.com/web#id=1932119&action=327&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.c252e5a10404856f15dc205a2ddf0497 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a module is uninstalled, related mail tracking records are now removed so outdated or inaccessible field history is not kept in the database. This reduces clutter and helps prevent users from seeing tracking information whose original access rules can no longer be verified. A related cleanup also improves internal naming and avoids showing empty messages based only on subtype text.
Original PR description
[IMP] mail: Delete tracking values when uninstalling module -------------- ### Purpose mail.tracking.values should be deleted when the corresponding field is deleted (when the module which defined it…
[IMP] mail: Delete tracking values when uninstalling module -------------- ### Purpose mail.tracking.values should be deleted when the corresponding field is deleted (when the module which defined it is uninstalled). Firstly because we don't want useless data in db. Secondly because the groups associated with the field can no longer be checked if it was deleted. As we don't know to whom the value was restricted, the value should not be displayed anyway. Note: this case was fixed in saas-12.2 by b9e96b7 but the proper way to fix it is to delete the tracking values. ### Specification Delete `mail.tracking.value` when the associated `ir.model.fields` is deleted. Two alternatives were considered: 1. Change the `field` field of `mail.tracking.value` from Char to a m2o to `ir.model.fields` which allows to use delete oncascade. This implies to modify existing code, but more importantly it adds database queries. 2. Override the unlink method of `ir.model.fields` to first unlink associated tracking values. The first method is probably cleaner but the second method was nonetheless chosen as we don't want to impact performance in the main tracking flow only to better support module uninstalls which happens rarely. Note: when a module is uninstalled, `ir.model.fields` are unlinked one by one (in a for loop). Tracking values are therefore also unlinked field by field. Batchifying field deletion would greatly reduce the amount of queries. [IMP] mail: Rename groups field of mail.tracking.value ---------------- This commit renames the `groups` field into `field_groups`. The previous name was impossible to grep as the word `groups` is everywhere in the code base. Also the new name better follows the implicit convention that fields related to the tracked field all start with `field_`. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The CRM lead generation screens now show credit consumption messages that are easier to understand and translate. This improves usability for teams using lead mining and website lead reveal features by making credit feedback clearer across languages.
Original PR description
Improve the usability of crm_iap_lead and crm_iap_lead_website. Task-ID 1965687 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website's mobile hamburger menu now remains usable when the navigation bar is fixed at the top of the page. This helps visitors on small screens access all menu options instead of being blocked by a non-scrollable menu.
Original PR description
Related task: https://www.odoo.com/web#id=1938637&action=333&active_id=131&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.800ba7770c62ede5fd8eb79362d031fa -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Deferred revenue settings are now managed only on products instead of also appearing on subscription templates and subscription forms. This reduces ambiguity for users and helps ensure subscription revenue recognition is consistently driven from subscription lines.
Original PR description
Task : https://www.odoo.com/web?debug=#id=35040&view_type=form&model=project.task&action=327&menu_id=4720 Pad : https://pad.odoo.com/p/r.e5c0439f5c21f32f8c65a81d1102e18d
The salary configurator now only offers company cars that are actually available and tracks who is expected to become the next driver. New company cars are created only after both the employee and HR manager have signed the contract, reducing administrative mistakes and improving fleet planning.
Original PR description
Since we track who wants to change cars and who will be the future driver of a car, we need to implement some logic in the salary configurator to deal with this new behaviour We also want to create the new car when both the employee and the hr manager have signed to contract Task : 1930298