Daily updates from Odoo
Tuesday, August 13, 2019
7 changes
New functionality added to Odoo
Adds a new Chilean reporting module focused on F29 tax reporting and related company settings. This helps businesses in Chile prepare required tax information more directly within Odoo, reducing manual reporting work.
Enhancements to existing features
Barcode scanners are now handled through the IoT keyboard driver, making scanner support available in Community and improving compatibility with different keyboard layouts. Point of Sale barcode handling is clearer and more reliable, including better support for special characters and modifier keys.
Original PR description
This PR is linked to: odoo/enterprise#4913 We updated the hw_scanner module to transform it into an IoT Driver. Since barcode scanners work the same way than keyboards, we will use a single Driver…
This PR is linked to: odoo/enterprise#4913 We updated the hw_scanner module to transform it into an IoT Driver. Since barcode scanners work the same way than keyboards, we will use a single Driver for both of them. Here are the different changes that are introduced : - Move all the js code that is related to barcode readers to a separate file for clarity. - Move KeyboardUSBDriver to Community. Barcode scanners should be available in Community. - Remove hw_scanner. We use the same route in the new driver (for Community) so backward compatibility is ensured. In Enterprise, we now use the longpolling to read the barcodes. - Send real characters instead of the key's name. For example, we now send '_' instead of 'UNDERSCORE'. - Add the possibility to select the keyboard/scanner layout from the IoT Device form view. An action is called on the IoT Box. - Add support for modifiers: Shift, Ctrl, Shift Lock, Num Lock... -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Incoming receipts no longer show pre-created detailed operation lines by default, encouraging users to add the actual lines they need during receipt processing. Serial number workflows are improved so users can generate multiple serial-numbered lines or paste a list of serial numbers, reducing manual entry and mistakes.
Original PR description
For picking of incoming type, changes behavior so user have to create new move lines instead of modify pre-generated move lines. Also, adapts the method to generate multiple SN and adds the possibility to paste a list of SN to generate stock move lines accordling. See commit messages for more details.
The control panel date filter menus were simplified while allowing users to combine options to create a wider range of date-based searches. Date and datetime grouping also supports selecting multiple options again, and related favorite filter behavior was corrected for a more reliable search experience.
Original PR description
The aim of this PR is to review the functioning of date filters in the control panel Fitlers and Group By submenus. For filter with date attribute set, the list of proposed options is shorter but allows a bigger set of domains to be quickly created (through combinations of the options). The resulting list of domains is different of the previous one: domains like "Today" or "Last Week" are left aside but many others (and their unions) are now accessible. The domains generated in that way are no more dynamic but it is still possible to save dynamic filters in general. This PR also reintroduces the multi selection of options for groupbys of type date/datetime in the groupby menu. See task: https://www.odoo.com/web#id=2028787&action=333&active_id=133&model=project.task&view_type=form&menu_id=4720 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Sales teams can now see more useful availability information directly on sales order lines when a product may be short on stock. The update also improves inventory forecasting by accounting for reserved quantities, warehouse filters, delivery dates, and kit component availability.
Original PR description
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
Barcode scanners are now managed through the IoT device workflow, sharing the same driver approach as keyboards. This improves compatibility, enables barcode reading through IoT updates, and lets users choose keyboard or scanner layouts directly from the IoT device form.
Original PR description
This PR is linked to: odoo/odoo#35084 We updated the hw_scanner module to transform it into an IoT Driver. Since barcode scanners work the same way than keyboards, we will use a single Driver for both of them. Here are the different changes that are introduced : - Move all the js code that is related to barcode readers to a separate file for clarity. - Move KeyboardUSBDriver to Community. Barcode scanners should be available in Community. - Remove hw_scanner. We use the same route in the new driver (for Community) so backward compatibility is ensured. In Enterprise, we now use the longpolling to read the barcodes. - Send real characters instead of the key's name. For example, we now send '_' instead of 'UNDERSCORE'. - Add the possibility to select the keyboard/scanner layout from the IoT Device form view. An action is called on the IoT Box. - Add support for modifiers: Shift, Ctrl, Shift Lock, Num Lock...
Helpdesk tickets can now be tracked against multiple service deadlines at the same time, giving teams clearer visibility into whether each commitment is ongoing, met, or failed. The update also improves SLA reporting and removes background recalculations that could waste resources or slow down busy systems.
Original PR description
This merge provides a big cleaning of helpdesk application. Cleaning to be guidelines compliant and to avoid some wrong pratice. But it also refactors and improve the SLA feature. Now, a ticket can…
This merge provides a big cleaning of helpdesk application. Cleaning to be guidelines compliant and to avoid some wrong pratice. But it also refactors and improve the SLA feature. Now, a ticket can have multiple SLA visible on each ticket (still defined on the team) and with a different status. Some definition: - A 'failed' ticket is a ticket with a least one SLA failed - A failed SLA is when the ticket did not reach the stage within the SLA delay (reached late, or not reached with deadline passed) - A 'running' SLA is an SLA status not reached before the deadline As many status depends on 'now()', we decided for performance problem to remove the cron computing and recomputing the delay stored field by non stored field with a search method correctly implemented. Searching and creating ticket does not impact query count, neither speed operation: - search on failed ticket: 1 query with stored or unstored fields - create ticket: from 52031 to 52030 (for a bunch of 1000), but from 198.15 millis to 107.81 Also, an inactive database will not consume server resources to keep those field updated. This merge also provides reporting and some small feature, detailled in subcommits. Task-37561