Thursday, November 21, 2019
5 changes · master
New functionality added to Odoo
Belgian companies can now generate the required 281.50 tax documents for partners directly in Odoo, in both PDF and XML formats. This helps streamline local compliance reporting and reduces manual preparation for submissions to Belgian tax authorities.
Original PR description
### Purpose: Be able to generate PDF & XML files for the Belgian 281.50 document. Some fields are hardcoded because it's not possible to get these information in Odoo. Of course, all theses fields aren't very important. If you have a problem about one field please contact avw/flg. ### Doc about this task: https://docs.google.com/spreadsheets/d/1C0NMxD3DB0tuIToqhlDF7N-giwLFXeS7XRn7rnguSec/edit#gid=0 https://finances.belgium.be/fr/E-services/Belcotaxonweb/documentation-technique https://finances.belgium.be/sites/default/files/downloads/161-belcotax-brochure-2018-20190225-fr.pdf https://ec.europa.eu/taxation_customs/tin/pdf/fr/TIN_-_subject_sheet_-_3_examples_fr.pdf https://i.gyazo.com/55b16f86ca35e118776227ea159cd412.png **Task ID:** 1861202
Adds support for automatically retrieving Chilean UF, UTM, USD, and EUR rates from SBIF, Chile's official banking authority. This helps businesses keep currency and index values up to date, provided they configure an SBIF API token.
Original PR description
Modify currency_rate_live in order to get a connection from SBIF (official chilean banks entity) to get UF, UTM, USD and EUR rate. UF (unidad de fomento) is an index which calculation is based on inflation rates. It serves to have an updated quotation of goods or services, not affected by inflation. UTM (unidad tributaria mensual) is not a currency, but it is an index used for tax debts or remanent amounts. Its rate calculation is updated monthly, but in order to have a uniform connection simultaneously updates with other most used currencies. The SBIF connection requires the user to get an api token from SBIF.
Enhancements to existing features
Course cards can now show their own short description, separate from the main course description shown elsewhere. This lets teams tailor homepage and card messaging without changing the description used on the course page, improving presentation and clarity for learners.
Original PR description
The Channel model contains the two following fields: `description` and `description_html`. The former is a short plain-text description that can be filled in the creation form. The latter is a long html-formatted description. Before this commit: The description displayed on the card of the course is the `description` field. After this commit: There is an additional `description_card` field, which is initialized to the same value as the `description` field. If the `description` field is modified the `description_card` reflects the modifications. This happens however only if the user didn't modify the `description_card` field manually. If it is modified to another value manually, the link is broken. Beside, as requested by SBU orally, in the creation form of a course, the description textarea is now a one-line input field to reflect the fact that it's supposed to be a short description. Task ID: 2026165
The 404 error page has been simplified so it can be fully edited in one place across Odoo setups. This makes the page more consistent for backend-only, portal, and website users while removing module-specific popular-page additions.
Original PR description
A nicer 404 layout was introduced with e9106f8f98ff but the specs got changed
just after it was merged.
It has been decided to make the 404 fully editable (before, everything was
fully editable except the popular page div).
In order to do this, the 404 template can't have inherited views, which brings
the following changes:
1. Remove every main website module xpath view adding their most popular page
2. Remove the xpath view in portal to add popular page part (was not needed
in http_routing/web). It has been decided that having `Home` ('/' url) even
without portal and/or website is not a big deal.
Those changes allow the 404 template to be written in a single view without any
inherited views.
The 404 will be the same for backend only databases, portal and website.
task-1966460Product pages now calculate the sales count from sales order lines directly instead of using a heavier sales reporting view. This makes moving between product records faster and keeps the sales count behavior aligned with purchasing counts.
Original PR description
Versions: 10.0, 11.0, master (I don't know if <10.0) # Description of the issue/feature this PR addresses: Run `EXPLAIN (ANALYZE, VERBOSE, BUFFERS) SELECT "sale_report"."product_id" as…
Versions: 10.0, 11.0, master (I don't know if <10.0) # Description of the issue/feature this PR addresses: Run `EXPLAIN (ANALYZE, VERBOSE, BUFFERS) SELECT "sale_report"."product_id" as "product_id","sale_report"."id" as "id" FROM "sale_report" WHERE "sale_report".id IN (23324) ORDER BY "sale_report"."date" DESC;` Result: - [Execution time: 8205.306 ms](https://gist.github.com/moylop260/82c0e6bf3cd2ea8880e26593fc78e2ee#file-gistfile1-txt) This query is called from [product._sales_count method](https://github.com/Vauxoo/odoo/blob/1aacc962620982528a3dfc90d2c1dd0027359375/addons/sale/models/product_product.py#L19) This method is called from view [product.sales_count field from view](https://github.com/Vauxoo/odoo/blob/e29206a19e1eb93b92679de9c7fdc7ec58bcbbae/addons/sale/views/sale_views.xml#L593) But the [action related to open the records](https://github.com/Vauxoo/odoo/blob/e29206a19e1eb93b92679de9c7fdc7ec58bcbbae/addons/sale/views/sale_views.xml#L577-L582) is opening `sale.order.line` table instead of `sale.report` view. # Current behavior before PR: `sale.report` is so slow spending 8 seconds to switch next product in the view form for our case. `sale.report` combine too many tables and they are unneeded (to get a quantity counter of `sale_order_line`) like as: - currency rates - company - sale order - partner - pricelist - product template Purchase uses `product.purchase_count` with the number of purchase orders https://github.com/odoo/odoo/blob/9f847076530cf83d7198c16a341b4f5d29392ceb/addons/purchase/models/product.py#L36-L45 Sale uses product.sales_count with the quantity of products sold It fix the product.sales_count ti number of sales order to be consistent # Desired behavior after PR is merged: Now is faster because is using directly `sale.order.line` and it's consistent with purchase orders count.