b82a1ae38b0eb72bdf39f32a87b6431a91628939
22
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 lase@odoo.com
|
506a1c19be |
[FIX] sale: set a default qty_delivered on new sol
Steps to reproduce:
- Create an SO with an SOL and save the record.
** The `qty_delivered` of that SOL will be null in the DB. **
Cause of the issue:
Since the `qty_delivered` field is computed, the default value is set in
the DB comes from the `_compute_qty_delivered` method at record creation
However, no default value is set here when the `qty_delivered_method` is
not `'analytic'`.
Note:
In 15.0, a default value was set because of these lines:
https://github.com/odoo/odoo/blob/313418804ae5cb6a786488ffc174b8eebffb796e/addons/sale/models/sale_order_line.py#L350-L353
These were removed by this commit
|
||
|
lase@odoo.com
|
1121aa7ab1 |
[FIX] sale_project: omit notes SOL in project status
Reported issue: Steps to reproduce: Be sure that 'industry_fsm' is installed. - Go to Project > Projects and swap to the list view - Create and save a new project with a customer - Access the related SO via the smart button - Add a service product, a storable product a section and a note - Go back and access the project status with the smart button > The SOL generated for the section and the note appear as SO items Expected behavior: The purpose of the project status tab is to have an overview at the project to help in the analyse its profitability, the time investment,.. as such, these SOL should not be considered as SO items. In addition, these lines lose their entire purpose in the list view used in this overview (they can not be moved and display irrelevant infos). Cause of the issue: These lines were not filtered out by the current query. opw-3794386 closes odoo/odoo#157984 Signed-off-by: Lancelot Semal (lase) <lase@odoo.com> |
||
|
lase@odoo.com
|
85a75d2d82 |
[FIX] project: assign copied task to copied project
Steps to reproduce:
- Create a project with a task with a sub-task
- Assign manually the sub-task to the project
- Create a product that creates a project based on this product template
- Create an SO with that product
> A copy of your project template will be created and assigned to the SO
Expected Behavior:
Just as in 16.4, the copy of the subtask created during this process
should be associated with the copy of your project template.
Current Behavior:
The subtask is associated with the original project template.
Cause of the issue/Fix:
Confirming the SO will call the copy method on your project template.
During this call copies of its task and sub-task will be created and
should then be remapped to the correct project/task using by the
`map_tasks` method call:
https://github.com/odoo/odoo/blob/f31174e02157e612650e77ebba3ed1fe54b96776/addons/project/models/project_project.py#L436-L437
This use to do the job correctly in 16.4 because of these lines:
https://github.com/odoo/odoo/blob/ce28edbaae5a9af0a8c6e1f2addf4285ec56e9e1/addons/project/models/project_project.py#L415-L419
However, these were removed by Commit
|
||
|
lase@odoo.com
|
094447485c |
[FIX] base: change the adress format in Luxembourg
Steps to reproduce: Create and print an SO for a customer based in Luxembourg Expected behavior: According to Bpost and to the Post of Luxembourg, the zip code should be displayed before the city name in the address format in Luxembourg. Current behavior: The zip code is displayed after the city name. opw-3791142 closes odoo/odoo#161738 X-original-commit: 83b38fab6cc69d0ed2c6abae34f2b4e76ef8a601 Signed-off-by: Lancelot Semal (lase) <lase@odoo.com> |
||
|
lase@odoo.com
|
6a177c503d |
[FIX] hr_recruitment: notify interviewers followers
Steps to reproduce: - Change the recruitment access rights of Marc Demo to "Interviewer". - Go to Recruitment > Applications > All Applications. - Create a new application and add Marc Demo as follower of the chatter. - Write and send a message on the chatter. > Marc Demo will not be notified Expected behavior: As discussed the PO of the recruitment module (gmf), since users with "interviewer" access rights have access to the chatter and since the sensible informations are now shared via the salary offer model instead of relying on the chatter of the application model, the followers of the chatter with "interviewer" access rights should be notified if pinged on a log note or if a general message is sent. Cause of the issue: Since sensitive informations used to pass through the chatter, users with "interviewer" access rights did not have access to it, and were removed on purpose from the recipients of the notifications: https://github.com/odoo/odoo/blob/cd6ed7f9fd2e0654cfb0672d7a9536dca21035cf/addons/hr_recruitment/models/hr_applicant.py#L376-L379 to avoid any leak of sensible information. Note: This access right did not exist before saas-16.4 opw-3783965 closes odoo/odoo#161198 X-original-commit: 6e8795cf5a7d51c4682941a253fb158e8e7e874e Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com> Signed-off-by: Lancelot Semal (lase) <lase@odoo.com> |
||
|
lase@odoo.com
|
61231577a2 |
[FIX] account: assign a vehicle to a posted journal entry
steps to reproduce: - Go to Accounting > Accounting > Actions > Lock Dates - Set a Tax Return Lock Date to a date of the previous month - Create and confirm vendor Bill with a taxed line of positive price - Go to Accounting > Reporting > Audit Reports > Journal Report - Hover over the Vendor Bills and click on "journal items" - Add the optional vehicle field to the recods - Select your expense line and try to add a vehicle > Invalid Operation "You cannot modify the taxes related to a posted journal item..." Cause of the issue: Modifying the "vehicle_id" of the account move line will trigger a call of the `_sync_dynamic_line` method in order to modify other account move line linked to the same account move: https://github.com/odoo/odoo/blob/6a4808802c67f98696338d0b6f6a07934c8003fb/addons/account/models/account_move.py#L2285-L2287 During the call of this write method, the account move line that we did not directly modified will not be excluded: https://github.com/odoo/odoo/blob/6a4808802c67f98696338d0b6f6a07934c8003fb/addons/account/models/account_move_line.py#L1571 as `..._field_will_change(line, vals,"vehicule_id")` will be `True`. The error will therefore be raised two lines later because a 'tax_id' is present in vals as a 'tax_id' was set on our related account move line. Expected behaviour: Since the 'tax_id' present in vals is the same as the one already set on our account move line, we are not modifying the taxes related to a posted journal item and we should not raise the error. opw-3810718 closes odoo/odoo#161387 X-original-commit: 3cd87c61c852eef96195a39a4011a6baa39e3078 Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com> |
||
|
lase@odoo.com
|
8574e18180 |
[FIX] hr_recruitment: update the description of interviewer's rigths
Current Behavior: The description of the "Interviewer" access rights is the following: "Interviewer right will give access to all job position/applications where the employee is defined. It will allow to refuse, plan meetings. **Chatter content will not be available.**" However, the "interviewer" users have access to the chatter as no sensible content can be accessed from it. > The description therefore needs to be updated. Note: This access right did not exist before saas-16.4 opw-3783965 closes odoo/odoo#161197 X-original-commit: eb2facc88701ca7deaa02947ee9e6c30687c0588 Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com> |
||
|
lase@odoo.com
|
1160d80da4 |
[FIX] website_sale: hide unpublished product to portal subcontractor
Steps to reproduce:
- Activate Subcontracting in the settings.
- Create a storable product
- Create a BOM of type "subcontracting" where the subcontractor is a
Portal user (e.g. Joel Willis) for that product.
- Log out and connect as your portal user.
- Go to the website shop and search your product.
Expected behavior:
The portal user should only be able to see the published products.
Current behavior:
The portal user sees unpublished products for which he is subcontractor.
Cause of the issue:
The commit
|
||
|
lase@odoo.com
|
795fe01294 |
[FIX] stock: show destination on report of internal transfers
Steps to reproduce: - Activate "Storage Locations" in the settings and create a warehouse - Inventory > Operations > Transfers > Internal - Create a new internal transfer with a non-zero product move line - Print the "Picking Operations" Expected behavior: The destination of the move should be on the document. Current behavior: The report (and hence the printed version) of an internal transfer does not display the destination of the transfer. Cause of the issue / fix: This part of the report is displayed under a `t-elif` condition. However for internal trasnfers the condition of the `t-if` and of the `t-elif` are both `true` so that two `t-if` should be used for an appropriate display of the report. Note: Prior to commit 567b8d6, two `t-if` were used. opw-3797998 closes odoo/odoo#159313 X-original-commit: c59e01f1ed32563da3dd86308bf46a1f2cdb5834 Signed-off-by: Tiffany Chang (tic) <tic@odoo.com> Signed-off-by: Lancelot Semal (lase) <lase@odoo.com> |
||
|
lase@odoo.com
|
e108e5854c |
[FIX] project: show only active users as possible task assignees
Steps to reproduce:
- Go to the project application and click on any project with a task
- Hover over the task and click on the "assign button"
> inactive users can be assigned to the task
Cause of the issue:
Clicking on the "assign button" will call of the `name_search` method on
`res.users` to determine which user can be added as a task assignee.
Since the domain of the `user_ids` field of the `project.task` model:
https://github.com/odoo/odoo/blob/331d8451d9011aff6a8290c473a52fa77b30b358/addons/project/models/project_task.py#L169-L170
is override in the view:
https://github.com/odoo/odoo/blob/fcd66ee3321649405cf21bc1d625d71abf3d5819/addons/project/views/project_task_views.xml#L649
inactive users will not be filtered out due to the domain.
On the other hand, they could still be filtered out during this call
because inactive records should automatically be filtered out, during
the call of the `_where_calc` method, unless explicitely asked for:
https://github.com/odoo/odoo/blob/9134358b579361ef5d7e4da43d4778027564adc9/odoo/models.py#L5389
https://github.com/odoo/odoo/blob/9134358b579361ef5d7e4da43d4778027564adc9/odoo/models.py#L5091-L5093
However, since the `'active_test'` is set to `False` in the
context of the the `user_ids` field:
https://github.com/odoo/odoo/blob/331d8451d9011aff6a8290c473a52fa77b30b358/addons/project/models/project_task.py#L169-L170
the inactive records will also not be filtered out by the call of this
`_where_calc` method.
Note:
Prior to version 17.0, the flow worked "as expected" since the
context set in the `user_ids` was not properly taken into account
and inactive records were therefore filtered out by the call of this
`_where_calc` method. Thanks to commit
|
||
|
lase@odoo.com
|
47c2acf22d |
[FIX] l10n_se: invert values of blocks F and G for Swedish tax report
Steps to reproduce: with SE Company: - Accounting > Vendor > Bills - Create and confirm a vendor bill with any of the `Ingående moms` taxes - Reporting > Tax report **The values of Block F and G appears in negative** Cause of the issue: The erroneous values come from the `se_48` formula of the `account_tax_report_data` which provides minus the value it should: https://github.com/odoo/odoo/blob/bd7aadf589ef1ba4556164bc70fc0fbb62928e48/addons/l10n_se/data/account_tax_report_data.xml#L374 This is due to the fact that the se_48 formula is set to minus the value it should on the `Ingående moms` taxes see for instance: https://github.com/odoo/odoo/blob/de1bee39c449eee2c5f0b722cf50aa33eade5142/addons/l10n_se/data/template/account.tax-se.csv#L58-L62 where the use of se_48 can be compared to the correctly used se_30. opw-3750771 closes odoo/odoo#158392 X-original-commit: 834e026b221d966df13a4b4450f4047c8a879c2e Related: odoo/enterprise#59022 Signed-off-by: Lancelot Semal (lase) <lase@odoo.com> |
||
|
lase@odoo.com
|
7fa4f71b63 |
[FIX] mrp: Generate MOs for BOM with product repetition
Steps to reproduce:
- Create 4 products: Final product (FP), Product 1,2,3 (P1,P2 and P3)
- Set routes to manifacture on each product
- For P1, P2, P3 add a 0:0 reordering rule.
- Add a BOM for P2 with 1 unit of P1 as components
- Add a BOM for P3 with 1 unit of P2 as components
- Add a BOM for FP with 1 unit of P3 and of P2 as components
The MO overview of a FP shoud look like this :
FP
/\
/ \
P3 P2
| |
P2 P1
|
P1
- Create and confirm a manufacturing order for a FP
Current behavior:
As the quantity on hand is not sufficient to manufacture a FP,
manufacturing orders are automatically created for P3, P2 and P1.
However, the quantity on each of these MOs is of 1 unit.
Expected behavior:
Since 2 units of P2 and of P1 will be required to manufacture the FP the
quantity of their respective MOs should be at 2.
Cause of the issue:
Confirming the MO for FP will call the trigger_scheduler() on its raw
stock move:
https://github.com/odoo/odoo/blob/79813f08e5a2f0188ac7d184d000486f25319503/addons/mrp/models/mrp_production.py#L1291
https://github.com/odoo/odoo/blob/f3ef40da0406bb0fd683dce3a08739e247fd6dfc/addons/stock/models/stock_orderpoint.py#L495
In this method, we compute the qty to order for the orderpoints of P2
and P3. Since these ones are positive, procurement will be run for both
of these leading to the creation of 2 new MO's via the manufacture
route. The post process of the scheduler is then run
https://github.com/odoo/odoo/blob/f3ef40da0406bb0fd683dce3a08739e247fd6dfc/addons/stock/models/stock_orderpoint.py#L550
An override of this method in mrp will then find the created MO and
confirm these, triggering the above process once more but now for the
MO's of P3 and P2 rather than FP: we start by computing the qty to order
for the orderpoints of P2 and P1 to manufacture P3 and P2. However, to
compute this quantity, we look at the forecast of these quantities and
this is where the problem comes in:
https://github.com/odoo/odoo/blob/f3ef40da0406bb0fd683dce3a08739e247fd6dfc/addons/stock/models/stock_orderpoint.py#L284
With the orderpoint of P2:
- `virtual_available` is at a value of -1 since there is currently 2
stock moves taking this product (one to manufacture FP and one to
manufacture P3) and one stock move bringing one unit of this product
(the one coming from the MO of P2 we are currently trying to confirm)
- `orderpoint._quantity_in_progress()` has a value of 1 due to the MO
of P2 that we are currently confirming.
Adding these quantities to one an other, the forecasted qty of P2 is at
0. This is a mistake since the incoming stock move for P2 is counted
twice in the forecast qty: once in each term. As a result no new
procurement will be generated for P2 hence the issue.
FIX:
Since this `_quantity_in_progress()` seems to have been introduced to
improve purchase flows rather than to interact with manufacturing flows:
https://github.com/odoo/odoo/commit/943da6df0f1d39e8e10869b25c5ba8cc13a2aa54
We decided to ignore its contribution during our manufacturing flow for
the forecast qty to be correctly computed. This requires to ignore the
contribution of each mo triggering the scheduler and those that already
triggered the scheduler since the confirmation of the MO of FP.
Notes: The test sets a little more complex MO overview than the
above use case to be sure to catch corner cases situations.
opw-3689920
closes odoo/odoo#158217
X-original-commit: 4c0b9ef2ad75d3f831fce0abaa62a1d660ba5ca6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
|
||
|
lase@odoo.com
|
adb2cd2b05 |
[FIX] purchase_requisition: compute taxes for alternative PO creation
Steps to reproduce: - Create a request for quotation for a product with set vendor Taxes - Create an alternative purchase order from that RFQ with Copy Product Current Behavior: The purchase order line of the PO associated with the created alternative does not compute the taxes. Expected behavior: The taxes should be computed in the same way as if the PO was created manually and then linked to the alternatives. Cause of the issue: When creating a PO manually, the taxes of each purchase order line are computed when the product is set during the call of the `onchange_product_id` onchange method: https://github.com/odoo/odoo/blob/64c13193ae0fe23eb1b426f5bbcd8531e9a40967/addons/purchase/models/purchase.py#L1221 https://github.com/odoo/odoo/blob/7ed0a773b6e0711b127f236ce665c35202d973bc/addons/purchase/models/purchase.py#L1055-L1061 By contrast, PO created from the `action_create_alternative` generate each `purchase.order.line` using `Command.create`. Therefore these lines will not trigger the onchange method and their taxes will not be computed. Fix: To KISS, we compute the taxes of each line just after the creation of the record using the `_compute_tax_id` method. opw-3750719 closes odoo/odoo#158300 X-original-commit: 15799594bda41bdb4b65387aa5f0d46482cb91c1 Signed-off-by: William Henrotin (whe) <whe@odoo.com> |
||
|
lase@odoo.com
|
1767efd9be |
[FIX] sms: compute the body of the SMS template
Steps to reproduce: - Go to Settings > Technical > Phone > SMS > SMS Templates - Create a new SMS template that applies to contacts with any content and add context action to save the template (this will allow you to use this template from the contact form view). - Go to Contacts, select any, click on the gear icon and send an SMS using your new SMS template. -> Issue : the Body of the SMS template is not displayed. Cause of the issue: The send SMS action generates an `sms.composer wizzard that triggers a call of the `onchange` method to compute the values of the form view of the record from scratch. The body of the message is computed during the snapshot1 of the onchange of the `sms.composer` https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/addons/web/models/models.py#L1076 by the `_compute_body` method: https://github.com/odoo/odoo/blob/72c1a4f96a1219d98ce9b90ee54fd7297b9ab999/addons/sms/wizard/sms_composer.py#L167 To be processed correctly, this computation requires a `template_id` (field of the sms.composer model). This `template_id` information is present in the `self._context` of the onchange as a 'default_template_id'. However, since the template_id is not present in the form view of the sms.composer, it is not part of the `fields_spec` arguments of the onchange and this `default` value is not converted into a value before the snapshot1 at this step: https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/addons/web/models/models.py#L931-L938 Prior to Odoo 17.0, this was not a problem as the value was still used from the context the snapshot1. However, this value is now cleaned form the context during the snapshot1: https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/odoo/api.py#L567 https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/odoo/tools/misc.py#L1010-L1014 As a result, there is no template_id during the call of the `_compute_body` and the body of the message stays empty. Fix: In order to compute the body, correctly, we add the template_id as an invisible field of the `sms.composer` form view so that it becomes part of the `fields_spec` arguments of the onchange so that its default value 'default_template_id' is converted into a real value: https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/addons/web/models/models.py#L931-L938 that will be used as an argument of the snapshot1. opw-3733881 closes odoo/odoo#154549 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com> |
||
|
lase@odoo.com
|
aed0e74462 |
[FIX] l10n_de_skr03: fiscal positions with VAT id should be vat_required
Steps to reproduce: - Install the l10n_de package - Create and select a german company - Accounting > Configuration > Settings > Fiscal localization - Set: Deutscher Kontenplan SKR03 for the fiscal localization - Accounting > Configuration > Accounting > Fiscal Positions - Click on "Geschäftspartner EU (mit USt-ID)" (this fiscal position translates to "Business partner EU (with VAT ID)". Issue: The `vat_required` field of this fiscal position is False but sould be True as the fiscal position is "(with VAT id)". Cause of the issue: The `vat_required` field is a Boolean of the account.fiscal.position model without defaut value nor compute method. As such it is interpreted as "False" when unset (just like any unset python boolean). Since the `vat_required` field is not set in the data file of the `l10n_de_skr03` localization for the "Geschäftspartner EU (mit USt-ID)" fiscal position, it will be interpreted as False. Fix: We update the data file of the fiscal localization to the expected value opw-3721912 closes odoo/odoo#157022 X-original-commit: 19703adb2f7a5f790ee3c9a3037be6cdf189efd7 Signed-off-by: Florian Gilbert (flg) <flg@odoo.com> Signed-off-by: Lancelot Semal (lase) <lase@odoo.com> |
||
|
lase@odoo.com
|
6fcd31cc21 |
[FIX] mrp_subcontracting : generates BOM for dynamic attributes
Current Behavior: Traceback when printing the BOM overview. Expected behavior: Generates a PDF of the BOM overview even if the information displayed is entirely relevant. Steps to reproduce: Inventory > Configuration > Products > Attributes Create an attribute with Variants Creation Mode set to "Dynamically". Create a new product with this single attribute and multiple values. Create a BOM for this product with BOM Type set to "Subcontracting". Print the BOM overview. Cause of the issue: Creating such a product generates a 'product.template' that is not associated to any variant and hence does not correspond to any 'product.product'. As a result the function_get_bom_data made can not apply the method _select_seller properly in that case. Notes: - There is no error if a variant was manually created for that product. - If the Variants Creation Mode set to "Dynamically" a variant is still automatically created to be associated to the product tempalte so that the erro does not rise. Fix: As the _select_seller method is only defined for product.product and not for product.template, we can not not apply it here. Furhtermore, since the additional informations provided by the override of the method get_bom_data in the the BOM overview will not be relevant without the existence of a variant, we skip this part of the code when the argument of _select_seller is not valid. opw-3698050 closes odoo/odoo#156346 X-original-commit: b983026f004d4958d2a47a0dac9b1b54e24ab04c Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com> Signed-off-by: Lancelot Semal (lase) <lase@odoo.com> |
||
|
lase@odoo.com
|
9444e2cfb5 |
[FIX] sale_loyalty: translate discount description
Current Behavior: The word "Discount" is translated in the users language unlike the content of the description which is translated into the customer's language Expected behavior: The word "Discount" should be translated as the content of the description. Steps to reproduce: Sales > Product > Discount & Loyalty Create a new loyalty program and add a translation to the reward description. Create a SO for a customer with the same language. Add products to meet the requirements of the loyalty program and click on Promotion. A line is created for the reward, but the word "Discount" is not translated into the customer's language, but the rest of the description is. Cause of the issue: The translation of the word Discount is done inside a dictionary comprehension using the _ = GettextAlias() method. As a result, 'self' does not appear in the arguments from which _ guesses the contextual language. Therefore, the language in which the translation happens is the contextual language of the request (user). Fix: The translation is applied before the discionary comprehension so that the method "_" correctly guesses the contextual language. opw-3700429 closes odoo/odoo#155296 X-original-commit: 03cbf7238400130c412a1606b6a9a2f22725e590 Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com> |
||
|
lase@odoo.com
|
bb77d9e554 |
[FIX] account: render draft invoice without early payment
Current behaviour:
500: Internal Server Error
Error while rendering the template account.report_invoice_document
Steps to reproduce:
Accounting > Configuration > invoicing > Payment Terms
New > Create and save a payment term with 2 lines
For example :
- name 80/20 test
- line_1 : 80% after 0 days
- line_2 : 20% after 30 days
Sales > Orders > Quotations
Chose any > use payment terms 80/20 test
Save and create associated invoice > chose regular invoice
> create draft invoice > preview > 500: Internal Server Error
Cause of the issue:
The method _get_amount_due_after_discount() called during the rendering
of the template does not return a value in case self.early_discount is
False.
Fix:
Return total_amount by default since no discount is applied.
opw-3683708
closes odoo/odoo#155080
X-original-commit: c8154b6aa57cc42e352260c7f75e52cd29a2d52d
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
|
||
|
lase@odoo.com
|
b036a33656 |
[FIX] stock, sale_stock: update delivered quantities for negative SO lines
Current behavior: Creating an SO with negative quantities for a storable product with an invoicing policy of type "delivered quantities" automatically generates a return move for the stocks. However, when this delivery is validated, the delivered quantities are not updated on the SO. This is problematic as these quantities are therefore not taken into account on the associated invoice. Expected behavior: The delivered quantities should be updated negatively on the SO to enable the invoicing of these lines. This is already the behavior in the POS application and when you create an SO with positive quantities followed by a return for a larger quantity than the one delivered. Steps to reproduce: Create a storable product with an invoicing policy of type "delivered quantities". Create an SO with 2 lines: - a line with positive quantities for any other product. - a line with negative quantities for the product you created. Confirm and validate the corresponding deliveries. Return to the SO. The quantities for the second line are not updated. Create an invoice. The second line is not taken into account. Cause of the issue: The to_refund field of the stock.move model defined in the stock_account module enables a decrease of the delivered quantities in the associated Sale Order. This field is set to True for "classic" returns but not for the stock.move generated from sale.order.line with negative quantities. Fix: We rely on the _get_custom_move_fields method to add the to_refund field in the procurement 'values' arguments in case the stock_account module is not installed. It is then available to use in the _get_stock_move_values method where we set its value to True if the quantity is negative (so that the move should be considered as a refund) opw-3676045 closes odoo/odoo#154496 X-original-commit: 92917d507a63ee08fc839ed3f7607d5e5060f0a2 Signed-off-by: William Henrotin (whe) <whe@odoo.com> |
||
|
lase@odoo.com
|
1c4a3cfd4d |
[FIX] calendar: Adjust meeting dates in an all_day setup
Steps to reproduce: - Calendar > create an all_day meeting with an additional attendee - Save > Edit > change starting date to a later day > traceback Cause of the issue: The write call of the method _onchange_date is applied to a pseudo record. However, the write method expects a record with an integer id to correctly _send_mail_to_attendees down the line. Fix: Since we don't want to send_mail_to_attendees anyway, we skip this part of the write method using the already existing contextual escape 'is_calendar_event_new'. opw-3733753 closes odoo/odoo#154091 X-original-commit: f206781b3f4cababa4e69c8c9586f0f5406acc83 Signed-off-by: Lancelot Semal (lase) <lase@odoo.com> |
||
|
lase@odoo.com
|
9dcf453b95 |
[FIX] mrp: Align columns on MO rendering
Current behavior: The column : "To Consume" is not aligned with the values. Cause of the issue: There is an html anchor with a t-else close that should not be there. Fix: This anchor is removed. opw-3692098 closes odoo/odoo#150891 Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com> |
||
|
lase@odoo.com
|
6a133f736d |
[FIX] snailmail_account: generate snailmail
Current behavior: If a customer has no email set, creating an invoice for that customer and clicking on send and print will not generate a snailmail for the invoice, even if, the checkbox (checkbox_send_by_post) is True. Expected behavior: A snailmail should be sent to the customer. Steps to reproduce: Using module_account from saas-16.2 to 17.0. Create a customer invoice for a customer without email > print and send > check "By Post" > send and print. Cause of the issue: The action action_send_and_print defined in account_move_send.py filters the moves that trigger a mail creation in the var "success". This variable filters out all moves without a partner_id.email. This makes perfect sense for emails but not for snailmails. However, creations of both types of mails are triggered by the _hook_if_success method taking "success" as an argument. Fix: To allow snailmail creations and correctly trigger email creation, we filter the moves with a partner email after the _hook_if_success method and only for email creation, not for snailmails. opw-3668487 closes odoo/odoo#152506 X-original-commit: b17a2c594aed08248c30842c62d2030de3087b51 Signed-off-by: Florian Gilbert (flg) <flg@odoo.com> Signed-off-by: Lancelot Semal (lase) <lase@odoo.com> |