Wednesday, April 28, 2021
23 changes · master
Enhancements to existing features
The Studio button is no longer shown on custom report views that cannot be edited in Studio. This prevents users from being sent to the wrong screen and avoids confusion when working with views such as project overviews.
Original PR description
Currenly in master, when view mode is qweb (for instance the project overview view), the studio icon is shown. But when the user clicks it, he/she is redirected to the wrong view and user can not customize it in studio mode. This PR purpose is to prevent the button to be shown for qweb views. task-2458123 Related PR: odoo/odoo#68146
Resolved issues and error corrections
This fixes how the Indian localization adjusts the unit of measure screen so the intended fields or settings appear in the correct place. It helps avoid display or configuration issues for users working with India-specific business data.
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
Miscellaneous changes
Usecase to reproduce: - create a product with 0 stock - Sale order 500 units - a RFQ is created for 500 units - in replenishments, you have 0 units to order, OK - RFQ --> confirm PO - in replenishments, now the quantity to order is 500 --> should still be 0, it leads to confusions It happens because the replenish action check the missing quantity for today. It result by -500 units since the delivery is planned for the next day (default supplier lead days = 1). But since the orderpoi
Original PR description
Usecase to reproduce: - create a product with 0 stock - Sale order 500 units - a RFQ is created for 500 units - in replenishments, you have 0 units to order, OK - RFQ --> confirm PO - in…
Usecase to reproduce: - create a product with 0 stock - Sale order 500 units - a RFQ is created for 500 units - in replenishments, you have 0 units to order, OK - RFQ --> confirm PO - in replenishments, now the quantity to order is 500 --> should still be 0, it leads to confusions It happens because the replenish action check the missing quantity for today. It result by -500 units since the delivery is planned for the next day (default supplier lead days = 1). But since the orderpoint exist, the quantity forecasted is already computed correctly with the right lead time. But the action will remove the 500 missing today from the quantity forecasted (The idea is to add the missing quantity on the main location. e.g. I have -10 units in WH/Stock/Shelf1 -20 units in WH/Stock The orderpoint will only look for its own location -> 20 to reorder The replenishment report look by warehouse and not by location -> 30 missing. So 30 missing + 20 incomming -> 10 to add (by default on WH/Stock) The fix is to add a step when a product is missing then compute its virtual available with lead days (to avoid missing confirmed moves during the lead time). opw-2456978 Forward-Port-Of: odoo/odoo#67278
The web client now completes startup even when a user has no accessible apps or menus. This prevents test and loading timeouts in limited community-only setups, improving reliability for restricted users and lightweight installations.
Original PR description
This mostly an issue when trying to run just the tests of `web` (aka `-iweb`) with only community modules available, `TestMenusDemoLight.test_01_click_apps_menus_as_demo`, wait for the ready code…
This mostly an issue when trying to run just the tests of `web` (aka `-iweb`) with only community modules available, `TestMenusDemoLight.test_01_click_apps_menus_as_demo`, wait for the ready code times out:
AssertionError: False is not true : The ready "odoo.isReady === true" code was always falsy
and the test suite fails.
The ready code simply checks that `odoo.isReady` is set. The web client sets `isReady` when `webclient_started` is triggered (specifically in `_onWebClientStarted`, which is the handler for that event).
[The community web client only triggers `webclient_started` at the end of `doAction`][0] meaning the community client is considered ready until after the first action has executed.
[The first action is executed by `show_application`][1] whose process is the following:
1. load and initialize the menus
2. if an action is specified in the URL, run that
3. otherwise if the user has a home action, run that
4. otherwise run the first menu's action
When installing only `web`, the only menus which could be available are Apps and Settings, and the demo user has access to neither. This means the demo user has no applications, and opening the first app is a no-op ([`openFirstApp` has a case just for that situation to ensure it does nothing][2]). As a result, `webclient_started` is never
triggered, `_onWebClientStarted` is never called, `odoo.isReady` is never set, and the tour never runs.
Fix by updating `openFirstApp` to return *whether* it opened an application, and in `show_application` the last fallback if even opening the first application failed is to just declare the web client ready.
While at it, rewrite `show_application` using ES6 facilities and flatten and linearize it using guards. This means the code pretty much tracks the process described above, with one step added:
5. otherwise complete the webclient's startup
[0]: https://github.com/odoo/odoo/blob/1eb474243b55f1b9e10c70d199bbe022e68b51d0/addons/web/static/src/js/chrome/action_manager.js#L174
[1]: https://github.com/odoo/odoo/blob/d1c56ec7c435c5baba8604feccc6116e4c25ca96/addons/web/static/src/js/chrome/web_client.js#L77-L107
[2]: https://github.com/odoo/odoo/blob/e24ab17d38fb049404f04112990e8b2fe1dd7727/addons/web/static/src/js/chrome/apps_menu.js#L44-L46This update fixes small issues in the account consolidation trial balance screen that could cause controls to behave inconsistently. It also cleans up the underlying code so the screen is easier to maintain and less likely to be affected by browser changes.
Original PR description
* sets attribute on `self` but `self` is not defined locally, so really defines them on `window`. These attributes seem unnecessary (one's just being used twice) so just inline it all and remove `init` override * not to mention one of the use sites did define a local `self`, so it was always `undefined` * use the local `e` parameter, rather than the deprecated `window.event` global * don't set buttons as instance attributes, that doesn't seem useful, and use jQuery's fluent API * while at it, modernize code (shorthand methods, splats)
Have a Fiscal position FPOS which map tax A to tax B Have products DEMO with tax A and DEMO2 Allow FPOS in POS, Open a session, activate FPOS, sell DEMO and DEMO2 Close POS Go to Orders, select the last one, hit return, edit, delete DEMO2 line Tax will be wrong. This occcur because the fiscal position mapping fail an equivalence check with a virtual record, so the tax is calculated as A and not B opw-2485399 Description of the issue/feature this PR addresses: Current behavior b
Original PR description
Have a Fiscal position FPOS which map tax A to tax B Have products DEMO with tax A and DEMO2 Allow FPOS in POS, Open a session, activate FPOS, sell DEMO and DEMO2 Close POS Go to Orders, select the last one, hit return, edit, delete DEMO2 line Tax will be wrong. This occcur because the fiscal position mapping fail an equivalence check with a virtual record, so the tax is calculated as A and not B opw-2485399 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#69936
**Description of the issue/feature this PR addresses:** We add all the data related to the Argentinean perceptions for each jurisdiction. For each jurisdiction (xx) we have a new: * Tax: Percepción IIBB xx Sufrida * Tax: Percepción IIBB Catamarca Aplicada * Tax group: Perc IIBB xx * Account: Saldo a favor IIBB xx * Account: Retención IIBB xx sufrida * Account: Percepción IIBB xx sufrida * Account: Retención IIBB xx aplicada * Account: Percepción IIBB xx aplicada * Account:
Original PR description
**Description of the issue/feature this PR addresses:** We add all the data related to the Argentinean perceptions for each jurisdiction. For each jurisdiction (xx) we have a new: * Tax: Percepción IIBB xx Sufrida * Tax: Percepción IIBB Catamarca Aplicada * Tax group: Perc IIBB xx * Account: Saldo a favor IIBB xx * Account: Retención IIBB xx sufrida * Account: Percepción IIBB xx sufrida * Account: Retención IIBB xx aplicada * Account: Percepción IIBB xx aplicada * Account: IIBB xx Also, we activate some perceptions to work with demo data -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: #67149 Forward-Port-Of: odoo/odoo#69757
The media modal's document tab has cells with icons and filenames. If the filename was too long, it would overflow its cell, which caused an ugly design glitch. This ensures an ellipsis on the filename when it is too long. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69893
Original PR description
The media modal's document tab has cells with icons and filenames. If the filename was too long, it would overflow its cell, which caused an ugly design glitch. This ensures an ellipsis on the filename when it is too long. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69893
When resuming a POS session, if the latter has been opened in the past and if its state is 'Opening Control', a incorrect UserError is raised and prevents the session to be started. To reproduce the error: 1. Use a French company 2. Create a POS - Enable "Advanced Cash Control" 3. Start a new session 4. Close it 5. Set the computer's date in the future 5. Open the POS session > Continue Selling Error: A UserError is raised ("This session has been opened another day. To comply
Original PR description
When resuming a POS session, if the latter has been opened in the past
and if its state is 'Opening Control', a incorrect UserError is raised
and prevents the session to be started.
To reproduce the error:
1. Use a French company
2. Create a POS
- Enable "Advanced Cash Control"
3. Start a new session
4. Close it
5. Set the computer's date in the future
5. Open the POS session > Continue Selling
Error: A UserError is raised ("This session has been opened another day.
To comply with the French law, [...]"), but the user does not have the
possibility to close the session. Moreover, since its state is "Opening
Control", no sales have been made yet.
This fix suggests to reset the start date in such a situation.
OPW-2488952
Forward-Port-Of: odoo/odoo#69253**Description of the issue/feature this PR addresses:** In the Argentinean invoices report view, we were removing the Payment Terms and we were only showing the Payment Term name in the header. Now we add it back following the Odoo approach but we also keep the name of the terms on the header. We made this modification in the invoice report with and without payment. Example: [FA-A.00001-00000386.pdf](https://github.com/odoo/odoo/files/6337477/FA-A.00001-00000386.pdf) -- I confirm I h
Original PR description
**Description of the issue/feature this PR addresses:** In the Argentinean invoices report view, we were removing the Payment Terms and we were only showing the Payment Term name in the header. Now we add it back following the Odoo approach but we also keep the name of the terms on the header. We made this modification in the invoice report with and without payment. Example: [FA-A.00001-00000386.pdf](https://github.com/odoo/odoo/files/6337477/FA-A.00001-00000386.pdf) -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69976 Forward-Port-Of: odoo/odoo#69500
When synchronizing microsoft calendar events, if the event is permanent Microsoft says the endDate is "0001-01-01": we save that and this causes an error when it is being parsed in javascript since we require a date with higher than 1000 years in require('web.field_utils').parseDate function. With this changeset, we do not set endDate if the type of the event is not endDate (as shown[^1] in the documentation endDate only makes sense for event of type endDate). [^1]: https://docs.micr
Original PR description
When synchronizing microsoft calendar events, if the event is permanent
Microsoft says the endDate is "0001-01-01": we save that and this causes
an error when it is being parsed in javascript since we require a date
with higher than 1000 years in require('web.field_utils').parseDate
function.
With this changeset, we do not set endDate if the type of the event is not
endDate (as shown[^1] in the documentation endDate only makes sense for
event of type endDate).
[^1]: https://docs.microsoft.com/en-us/graph/outlook-schedule-recurring-events#recurrence-ranges
opw-2479029
Forward-Port-Of: odoo/odoo#69944Scenario: - add a file in mass mailing editor => an generic icon (instead of lower version where icon depended on mimetype) is added linking the file - save and send mail => no icon is shown in email received The system is targeting `a[href*="/web/content/"][data-mimetype]:empty` to add real image inside instead of using background-image attribute which is stripped in sanitized. With this commit, data-mimetype is not removed when image processing attributes are removed when a f
Original PR description
Scenario: - add a file in mass mailing editor => an generic icon (instead of lower version where icon depended on mimetype) is added linking the file - save and send mail => no icon is shown in email received The system is targeting `a[href*="/web/content/"][data-mimetype]:empty` to add real image inside instead of using background-image attribute which is stripped in sanitized. With this commit, data-mimetype is not removed when image processing attributes are removed when a file is inserted. opw-2474053 Forward-Port-Of: odoo/odoo#69915
Description of the issue/feature this PR addresses: data is updated that shouldn't. Current behavior before PR: if you would update the module the default livechat details would be reset. Desired behavior after PR is merged: By wrapping it in a no-update they're not updated with a module update. Fixes https://github.com/odoo/odoo/issues/69960 Closes https://github.com/odoo/odoo/issues/69960 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
Description of the issue/feature this PR addresses: data is updated that shouldn't. Current behavior before PR: if you would update the module the default livechat details would be reset. Desired behavior after PR is merged: By wrapping it in a no-update they're not updated with a module update. Fixes https://github.com/odoo/odoo/issues/69960 Closes https://github.com/odoo/odoo/issues/69960 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69961
Steps: - Go to Inventory / Products / Products - Create a product (2) - Storable Product - Cost: 10 - Click Update Quantity - Create a new quantity line with 3 in On Hand Quantity - Update the line with 1 in On Hand Quantity - Go back to the product - Click the "Forecasted" smart button Bug: The on hand value is 30 instead of 10. Explanation: When `location_dest_id` is the current location, it is used to specify that a given quantity has been added to this location's stock.
Original PR description
Steps: - Go to Inventory / Products / Products - Create a product (2) - Storable Product - Cost: 10 - Click Update Quantity - Create a new quantity line with 3 in On Hand Quantity - Update the line…
Steps: - Go to Inventory / Products / Products - Create a product (2) - Storable Product - Cost: 10 - Click Update Quantity - Create a new quantity line with 3 in On Hand Quantity - Update the line with 1 in On Hand Quantity - Go back to the product - Click the "Forecasted" smart button Bug: The on hand value is 30 instead of 10. Explanation: When `location_dest_id` is the current location, it is used to specify that a given quantity has been added to this location's stock. However, when removing a quantity, the move goes from the current location to a virtual one. The current location is, in this case, stored in `location_id` and the destination is the virtual location. This makes stock removals not appear in the on hand value since we only filter the layers on their move's `location_dest_id`. This commit assumes that a move always goes from or to a virtual location and checks if the current location is in `location_dest_id` or in `location_id`. opw:2510911 Forward-Port-Of: odoo/odoo#69969
The changed test uses the drag&drop helper, and an operation does not work as expected with the given params on chrome 90. The runbot currently uses chrome 80, so it is not an issue, but if your chrome is up-to-date, and you try to run the test suite, this test would fail. 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-p
Original PR description
The changed test uses the drag&drop helper, and an operation does not work as expected with the given params on chrome 90. The runbot currently uses chrome 80, so it is not an issue, but if your chrome is up-to-date, and you try to run the test suite, this test would fail. 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#69974 Forward-Port-Of: odoo/odoo#69964
According to Ebay API : https://developer.ebay.com/devzone/xml/docs/Reference/eBay/CompleteSale.html#CompleteSale Only the following characters are allowed for the field ShippingCarrierUsed: letters (a-z, A-Z), numbers (0-9), space, and dash (-). opw-2496797 Forward-Port-Of: odoo/enterprise#17979
Original PR description
According to Ebay API : https://developer.ebay.com/devzone/xml/docs/Reference/eBay/CompleteSale.html#CompleteSale Only the following characters are allowed for the field ShippingCarrierUsed: letters (a-z, A-Z), numbers (0-9), space, and dash (-). opw-2496797 Forward-Port-Of: odoo/enterprise#17979
- Go to Accounting > Accounting > Assets - Create an asset where depreciation is present in 2 fiscal years * Original Value: 1000 * Acquisition Date: 01/11/2020 * Method: Linear * Duration: 10 Months * First Depreciation Date: 30/11/2020 - Confirm the asset - Post depreciation lines for 30/11/2020, 31/12/2020 and 31/01/2021 - Go to Accounting > Reporting > Assets Report - The reports are as followed: (Depreciation part) | 2020 | |---| <table> <tr><th cols
Original PR description
- Go to Accounting > Accounting > Assets - Create an asset where depreciation is present in 2 fiscal years * Original Value: 1000 * Acquisition Date: 01/11/2020 * Method: Linear * Duration: 10 Months…
- Go to Accounting > Accounting > Assets
- Create an asset where depreciation is present in 2 fiscal years
* Original Value: 1000
* Acquisition Date: 01/11/2020
* Method: Linear
* Duration: 10 Months
* First Depreciation Date: 30/11/2020
- Confirm the asset
- Post depreciation lines for 30/11/2020, 31/12/2020 and 31/01/2021
- Go to Accounting > Reporting > Assets Report
- The reports are as followed: (Depreciation part)
| 2020 |
|---|
<table>
<tr><th colspan="4">Depreciation</th></tr>
<tr>
<th>01/01/2020</th>
<th>+</th>
<th>-</th>
<th>31/12/2020</th>
</tr>
<tr>
<td>0.00</td>
<td>200.00</td>
<td>0.00</td>
<td>200.00</td>
</tr>
</table>
| 2021 |
|---|
<table>
<tr><th colspan="4">Depreciation</th></tr>
<tr>
<th>01/01/2021</th>
<th>+</th>
<th>-</th>
<th>31/12/2021</th>
</tr>
<tr>
<td>200.00</td>
<td>100.00</td>
<td>0.00</td>
<td>300.00</td>
</tr>
</table>
- Dispose of the asset
- Set Accounting Date of the disposal to 01/02/2021
- Post the disposal
- The Assets Report for 2021 becomes:
<table>
<tr><th colspan="4">Depreciation</th></tr>
<tr>
<th>01/01/2021</th>
<th>+</th>
<th>-</th>
<th>31/12/2021</th>
</tr>
<tr>
<td>300.00</td>
<td>0.00</td>
<td>300.00</td>
<td>0.00</td>
</tr>
</table>
Opening value for 2021 has changed and "+" section has been set to 0, which is not correct.
opw-2469625
Forward-Port-Of: odoo/enterprise#17660Before this commit, the links to the documentation in Helpdesk and Field Service is for the v.13 and not v.14. Moreover, some documentations in v.14 have been removed. This commit removes the links in which the documentation has been removed or will be removed and update the link to have the most recent documentation. Forward-Port-Of: odoo/enterprise#17439
Original PR description
Before this commit, the links to the documentation in Helpdesk and Field Service is for the v.13 and not v.14. Moreover, some documentations in v.14 have been removed. This commit removes the links in which the documentation has been removed or will be removed and update the link to have the most recent documentation. Forward-Port-Of: odoo/enterprise#17439
In version 130 of expense extract, the prefix 'exp_' isn't necessary. Forward-Port-Of: odoo/enterprise#17944
Original PR description
In version 130 of expense extract, the prefix 'exp_' isn't necessary. Forward-Port-Of: odoo/enterprise#17944
task 334 --- The error occurs because the selected credit note document type is not the proper one for the current invoice and we receive an error from AFIP. This error is making a rollback and is deleting the credit note before showing the error. No matter if there was an error in AFIP or not. We have change the code to leave the credit note in draft state and show the error to the user return by AFIP. Forward-Port-Of: #12362 Forward-Port-Of: odoo/enterprise#12812
Original PR description
task 334 --- The error occurs because the selected credit note document type is not the proper one for the current invoice and we receive an error from AFIP. This error is making a rollback and is deleting the credit note before showing the error. No matter if there was an error in AFIP or not. We have change the code to leave the credit note in draft state and show the error to the user return by AFIP. Forward-Port-Of: #12362 Forward-Port-Of: odoo/enterprise#12812
… discount by fetchmail DTE server ### Current behaviour: **GIVEN** a DTE with a discount line ``` <DscRcgGlobal> <NroLinDR>1</NroLinDR> <TpoMov>D</TpoMov> <GlosaDR>AJUSTE COMISION</GlosaDR> <TpoValor>$</TpoValor> <ValorDR>1.01</ValorDR> </DscRcgGlobal> ``` **WHEN** the fetchmail DTE server runs **THEN** the invoice is created without lines ### Expected behaviour: The invoice is created with lines Forward-Port-Of: odoo/enterprise#17929
Original PR description
… discount by fetchmail DTE server ### Current behaviour: **GIVEN** a DTE with a discount line ``` <DscRcgGlobal> <NroLinDR>1</NroLinDR> <TpoMov>D</TpoMov> <GlosaDR>AJUSTE COMISION</GlosaDR> <TpoValor>$</TpoValor> <ValorDR>1.01</ValorDR> </DscRcgGlobal> ``` **WHEN** the fetchmail DTE server runs **THEN** the invoice is created without lines ### Expected behaviour: The invoice is created with lines Forward-Port-Of: odoo/enterprise#17929
Forward-Port-Of: odoo/enterprise#17914
Original PR description
Forward-Port-Of: odoo/enterprise#17914
of https://github.com/odoo/enterprise/commit/20f389ff396502000ec92d15eb9f1cfef3671b2a Domains were missing in https://github.com/odoo/enterprise/commit/edaf57f61213ae9d6f51e7377c89dc65e8734d6e . Forward-Port-Of: odoo/enterprise#17964
Original PR description
of https://github.com/odoo/enterprise/commit/20f389ff396502000ec92d15eb9f1cfef3671b2a Domains were missing in https://github.com/odoo/enterprise/commit/edaf57f61213ae9d6f51e7377c89dc65e8734d6e . Forward-Port-Of: odoo/enterprise#17964