Thursday, November 21, 2019
20 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
Miscellaneous changes
A deadlock can occur when the registry lock being held by a thread that's stuck [1]. When the server shuts down it tries to delete the DB's registry by acquiring this lock, joining the deadlock. There's no real reason to delete the DB's registry. It doesn't do any special cleaning that shutting the process down (or restarting it) won't do. The impact of keeping the registry a little while longer until the main thread exits or restarts won't have any meaningful impact. So we fix the pr
Original PR description
A deadlock can occur when the registry lock being held by a thread that's stuck [1]. When the server shuts down it tries to delete the DB's registry by acquiring this lock, joining the deadlock.…
A deadlock can occur when the registry lock being held by a thread that's stuck [1]. When the server shuts down it tries to delete the DB's registry by acquiring this lock, joining the deadlock. There's no real reason to delete the DB's registry. It doesn't do any special cleaning that shutting the process down (or restarting it) won't do. The impact of keeping the registry a little while longer until the main thread exits or restarts won't have any meaningful impact. So we fix the problem by not deleting it altogether. [1] The following deadlock was observed in Odoo threaded server mode: 1. incoming request spawns a new thread A A starts a transaction and does a "SELECT ... FROM res_users ..." getting an ACCESS SHARE lock on the table 2. incoming request spawns a new thread B B is a request that calls `button_immediate_install`, that will install new modules and alter the res_users table. 3. B takes and holds the registry lock and executes "ALTER TABLE res_users ...", that waits to get the ACCESS EXCLUSIVE lock on the table until A's transaction releases the ACCESS SHARE lock. 4. A continues code execution and reaches a .sudo() call, it tries to create a new environment. The creation of the new environment requires to wait for the registry's lock to be release but it's held by B. -> A waits for B's registry lock to be released -> B waits for A's ACCESS SHARE lock to be released Fixing this issue is complex and dangerous to perform in a stable branch. It occurs very rarely and starting from v12.0, where threaded time limits are implemented, it will cause the server to restart after the limit_time_real is reached. This will unblock the situation with this additional, fix allowing the server to restart. The framework team has an idea on how to fix the above deadlock problem that will most likely be made for the master branch. Forward-Port-Of: odoo/odoo#40339
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-1966460The website theme preview experience has been adjusted so the view-switching control appears where product feedback requested it. The default theme configuration was also simplified by removing automatic installation behavior, making theme handling more deliberate.
Original PR description
Move switchView according to FP request 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
Product 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.
Since Odoo V13, ES6 is supported and we therefore do not support IE 11 anymore. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#40602
Original PR description
Since Odoo V13, ES6 is supported and we therefore do not support IE 11 anymore. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#40602
- Uncomment the csv access file so it doesn't raise a warning when installing the module by default - Add blank lines at end of python files (pep8) - Easier uncomment (entire blocks, and no remaining whitespaces in empty lines) - Add `_description` to model to avoid the warning telling it's missing - Correct compute field, `self.value` raised an `ensure_one` issue - Change access so the user can add/edit/delete records in the web interface by default - Correct the server acti
Original PR description
- Uncomment the csv access file so it doesn't raise a warning when installing the module by default - Add blank lines at end of python files (pep8) - Easier uncomment (entire blocks, and no remaining whitespaces in empty lines) - Add `_description` to model to avoid the warning telling it's missing - Correct compute field, `self.value` raised an `ensure_one` issue - Change access so the user can add/edit/delete records in the web interface by default - Correct the server action, `self` is not in the server action context. Forward-Port-Of: odoo/odoo#38520
Activate Google Synchronization, create on OE a recurrent event (no allday) synchronize the calendar, then delete an event of the recursion on OE, sync again on OE. An error will popup in the console. There is a typo in the variable sent to the google API. https://developers.google.com/calendar/v3/reference/events -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#40595
Original PR description
Activate Google Synchronization, create on OE a recurrent event (no allday) synchronize the calendar, then delete an event of the recursion on OE, sync again on OE. An error will popup in the console. There is a typo in the variable sent to the google API. https://developers.google.com/calendar/v3/reference/events -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#40595
Reproduce the issue - Install Time Off - Select all the lines - Action > Export The file has only columns but no data Cause In `hr_leave_type.py` the `_search` method's limit is `False` when we select all the lines. In 04e85ef, we return the leaves ids with `[:limit]` so `[:False]` that always returns an empty array instead of `[:None]` that returns the full list. This commit replaces the `[:limit]` by `[:limit or None]` OPW-2126109
Original PR description
Reproduce the issue
- Install Time Off
- Select all the lines
- Action > Export
The file has only columns but no data
Cause
In `hr_leave_type.py` the `_search` method's limit is `False` when
we select all the lines.
In 04e85ef, we return the leaves ids with `[:limit]` so `[:False]`
that always returns an empty array instead of `[:None]` that returns
the full list.
This commit replaces the `[:limit]` by `[:limit or None]`
OPW-2126109
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#40539Steps to reproduce: 1. Go to the Accounting / Invoicing apps 2. Open Taxes (Configuration -> Accounting / Invoicing -> Taxes) 3. Try to create a new tax and the client crash. It occurs because the `_processX2ManyCommands()` method doesn't handle correctly a missing `fieldInfo` on some X2Many tags. On mobile, when calling `load_views` the kanban view is used by default. But if the kanban isn't defined, a default kanban view with only the id of the model is used. In the case of th
Original PR description
Steps to reproduce: 1. Go to the Accounting / Invoicing apps 2. Open Taxes (Configuration -> Accounting / Invoicing -> Taxes) 3. Try to create a new tax and the client crash. It occurs because the `_processX2ManyCommands()` method doesn't handle correctly a missing `fieldInfo` on some X2Many tags. On mobile, when calling `load_views` the kanban view is used by default. But if the kanban isn't defined, a default kanban view with only the id of the model is used. In the case of the taxes form, the `default_get` retrieved for this form refers to a Many2Many (`tag_ids`) inside a One2Many. But this field isn't present inside the loaded kanban view, so when we process the command defined by the `default_get`, the `field_view` item doesn't exist (because the default kanban loaded only contains the id of the field). Now instead of using an undefined `fieldInfo`, we fall back to an empty object on the missing field to avoid the crash. Forward-Port-Of: odoo/odoo#40240
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#40576
Original PR description
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#40576
Description of the issue/feature this PR addresses: Add signature for phuctranerp Forward-Port-Of: odoo/odoo#39432
Original PR description
Description of the issue/feature this PR addresses: Add signature for phuctranerp Forward-Port-Of: odoo/odoo#39432
Reproduce the issue - Install Sales & Events - Create an event with tickets (remember the category you choose) - Configuration > Event categories - Check "Ticketing" and add your tickets types - Create a quotation with "EVENT_REG" product - Select your event and your ticket - Confirm the quotation A wizard open with no lines in registration. Cause The backend response is different from the V12 due to some dark and deep changes. The old r
Original PR description
Reproduce the issue
- Install Sales & Events
- Create an event with tickets (remember the category you choose)
- Configuration > Event categories
- Check "Ticketing" and add your tickets types
- Create a quotation with "EVENT_REG" product
- Select your event and your ticket
- Confirm the quotation
A wizard open with no lines in registration.
Cause
The backend response is different from the V12 due to some dark
and deep changes. The old response was converting the
`registration_event_ids` into a create action but it does'nt do
that anymore.
This commit specifies the action for the `registration_event_ids`.
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
Forward-Port-Of: odoo/odoo#40566Reproduce the issue - Install CRM - Go in CRM > Reporting > Pipelines - Click on the first "Group by" button The dropdown menu is out of the screen at 100% zoom. If we want to see the whole menu we have to dezoom ("Ctrl" + "-") Cause I think the issue is that the "Group by" dropdown have a lot of items. This cause a large height who is not handled by the bootstrap dropdown and this cause a shift in its calculations for the position (translate
Original PR description
Reproduce the issue
- Install CRM
- Go in CRM > Reporting > Pipelines
- Click on the first "Group by" button
The dropdown menu is out of the screen at 100% zoom.
If we want to see the whole menu we have to dezoom ("Ctrl" + "-")
Cause
I think the issue is that the "Group by" dropdown have a lot of
items. This cause a large height who is not handled by the bootstrap
dropdown and this cause a shift in its calculations for the position
(translate3d propertie)
This commit decreases the max-height to a height handled by the
bootstrap dropdown.
OPW-2116974
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
Forward-Port-Of: odoo/odoo#40277Go to the webshop checkout page. Customise to add "Accept Terms & Conditions". You get a traceback. The 'change #checkbox_cgv' event is triggered before the initialisation of the WebsiteSalePayment widget. opw 2126456 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 Forward-Port-Of: odoo/odoo#40470
Original PR description
Go to the webshop checkout page. Customise to add "Accept Terms & Conditions". You get a traceback. The 'change #checkbox_cgv' event is triggered before the initialisation of the WebsiteSalePayment widget. opw 2126456 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 Forward-Port-Of: odoo/odoo#40470
Open Accounting app, go to Accounting>"Lock Dates" and set a "Tax Lock Date". Now create a Vendor Bill with invoice date prior to the tax lock date, add a line, Odoo will display a warning. Remove the Tax from the line, save. The accounting date will be forced to tax_lock_date + 1 which should be not the case since the order is without tax. Adding a check to force the tax only when tax line ids are present. opw-2115547 -- I confirm I have signed the CLA and read the PR guideline
Original PR description
Open Accounting app, go to Accounting>"Lock Dates" and set a "Tax Lock Date". Now create a Vendor Bill with invoice date prior to the tax lock date, add a line, Odoo will display a warning. Remove the Tax from the line, save. The accounting date will be forced to tax_lock_date + 1 which should be not the case since the order is without tax. Adding a check to force the tax only when tax line ids are present. opw-2115547 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#40544
Forward-Port-Of: odoo/enterprise#6767
Original PR description
Forward-Port-Of: odoo/enterprise#6767
Reproduce the issue - Install Studio - Create an app with a kanban view - Drop a field into the kanban view The field display is inline by default, it is not a correct behavior. It is more comfortable for the user to set the default display to full width. This commit is a fine-tuning 8eeb25a. This was not working because the value were never picked by the view_editor_manager. I replaced the display names according to the guidelines of NGR. OPW-2090810
Original PR description
Reproduce the issue
- Install Studio
- Create an app with a kanban view
- Drop a field into the kanban view
The field display is inline by default, it is not a correct
behavior. It is more comfortable for the user to set the default
display to full width.
This commit is a fine-tuning 8eeb25a. This was not working because
the value were never picked by the view_editor_manager.
I replaced the display names according to the guidelines of NGR.
OPW-2090810
Forward-Port-Of: odoo/enterprise#6772
Forward-Port-Of: odoo/enterprise#6703