Before this commit, some breaking spaces were present in the js code.
Such spaces are misinterpreted and worked by luck.
This has become a problem with exported js bunldes (e.g. the
external_lib bundle in im_livechat).
This commit replaces breaking spaces by regular spaces.
Correct account invoice line form view so studio doesn't fail on
something that doesn't seem really correct (and somehow worked thanks
to pyeval implementation or the override from another view type).
opw-1826254
opw-1830171
closes#23997
Steps to reproduce the issue in 11.0 Enterprise:
- Go to the language English
- Remove from the time format the seconds
- Refresh the page
- Go to sales
- Create a sales order;
Bug:
- You get the warning message
closes#23596closes#22027
opw:1829577
The code in res config that enabled or disabled internal operation type
did not take into account that active_test is set to False inside this
type of code since c2e259d8.
Thus a picking type of an archived warehouse would possibly unexpectedly
be enabled after saving the settings.
opw-1826196
closes#23956
The state of the JS documentation was quite sad, not updated in a long
time. With this commit, we rework a lot of the JS doc. Most notably,
we add a section 'Javascript Cheatsheet' (help on some common
customization tasks) and rewrite the 'Javascript Reference' totally.
Note that the JS reference page also contains a reference on all field
widgets.
This work is just the beginning, it is probably not complete, but at
least we will have a foundation.
Steps to reproduce the bug:
-Create a tax of 21% tax included but don't select the "affect base" checkbox.
-Create another tax of 5.2% (no tax include)
-Create a sale order with a line that has a unit price of 121 and both taxes.
Notice that the total amount is: 126.2 (100 base amount + 21 from 21% tax + 5.2 from 5.2 tax)
-Click on "Print the proforma invoice"
Bug:
The total amount was still 126.2 and base=100, however taxes were wrong, there were 21 for the 21% tax
and 6.29 instead of 5.2 for the 5.2 tax.
Back-port of this commit: f50a08bc3d
Forward up to saas-15
opw:1819882
- Set the number of digits of 'Product Unit of Measure' to 1
- Create a stockable product:
UOM: Dozens
Purchase UOM: Units
- Buy 17 Units, validate the picking
- Create a landed cost:
Amount: 100
Split Method: By Quantity
- Compute
The Valuation Adjustment line contains contains a line with a quantity
equal to 1.4, leading to a line of 98.60. It is impossible to validate
the landed cost because of the inconsistency.
The method `get_valuation_lines` retrieves the data from the
`stock.move` and copies the following values to the
`stock.valuation.adjustment.lines`:
- `product_qty` > `quantity`
- `weight` > `weight`
- `volume` > `volume`
Therefore, we must make sure that these fields are using the same digits
precision. We adapt the precisions accordingly.
opw-1817783
When you have a receipt in multiple steps and cancel the generated RFQ
the following internal move stay in waiting another operation.
We recompute its state and pass it in waiting.
OPW-1832176
This commit reverts part of f5912cb since the spec changed afterwards.
Unpublished page will have a red toggle, which even if it is small should be
enough to draw user attention, and not a ribbon anymore.
Task-44005
Following commit 340d70338f, we make sure the delivery price
contains the right number of decimals by sending a formatted string
instead of a float. Indeed, due to the float representation, values such
as 25.310000000000002 may occur.
opw-1831656
The commit f1e842bcd2 corrected the Khmer code language but the csv language file was left with a blank line inside.
The csv parsing (to populate the list of available languages) failed into tools.misc.scan_languages() because of the blank line
Commit b6d4cd5deb introduced the auto-reconciliation when reversing
an entry. However, we should make sure to only reconcile non-reconciled
entries. Such an entry can be generated from an exchange rate entry.
opw-1826024
When doing a sudo on top, the fields are accessed with user 1 but the set is
also made with user 1.
meeting.user_id.partner_id.id is correctly computed but
meeting.partner_color_id is not set for the current user (return 0)
All events were in the same color
Introduced at b669c71aa3
opw-1829793
Closes#23923
The correct solution would be to store the total_depreciated_cost on the fleet vehicle.
But this solution is not acceptable on a stable release as it implies to update the module.
The only thing we can do here is to add the dependencies on the field 'total_depreciated_costs'
to the field 'company_car_total_depreciated_costs'.
As the field is not stored, then the field 'company_car_total_depreciated_cost'
(which is stored) is not recomputed correctly when modifying the log_contract.
This solve the following issue: Modify a recurring costs amount (depreciated)
on the fleet vehicle contract, then the final yearly cost on the related
hr.contracts are not recomputed correclty, as the field company_car_total_depreciated_cost
on the hr.contract is not recomputed on the total_depreciated_cost modification.
Purpose
=======
In contract, track fields (create a note, no need subtype. it is just for the history)
- wage
- fuel_card
- meal_voucher_amount
- representation_fees
- additional_net_amount
- retained_net_amount
- commission_on_target
- ip
- car_id
- internet
- mobile
- mobile_plus
- final_yearly_ cost
The code of khmer language was not the offical one. Installing it
produce an error in the Babel python library.
It's not possible to easily fix it by correcting the code km_KM to km_KH
because Odoo
prohibit changing language code. The solution to this is to remove the
Khmer language from the res_lang.csv file and add it to an xml data
file with the correct code. There, we can put on this record the
"noupdate" tag. This tag
will block any modification on the ir_model_data corresponding to the
xml_id=lang_km
and so avoid the error if we update the base module. Old database still
wont be able
to use khmer language (so we'll need to manually change it in database)
but new one created
after this commit will be able to use it without issue.
Before this commit if /foo redirect to /bar?a=1
/foo?debug=1 was redirectd to /bar?a=1
After this commit,
/foo?debug=1 is redirected to /bar?a=1&debug=1
Before this commit, UTM was no more set for website.page.
Website.page mechanism uses the _handle_exception to check if an url match a
record in database, instead of use the method _dispatch that uses controllers.
Consequently, module UTM never set the utm into the cookies for website.page.
Now we override method '_handle_exception' that will anyway ignore to set utm
if it is a real exception and not a fallback (redirect, page, attachment, ...)
Fixed use case:
When creating a new payment (not from invoice), the payment amount is zero and this value triggers an onchange method that set the first miscellanous journal_id as the payment journal_id and force the domain with only miscellanous journals.
This behavior was added in commit 3267e76 to be able to clear invoices by registering a 0 amount payment on it, but this has obviously only interest when registered from the invoices form view... To keep this functionality we only add a "AND" sentence to validate that the payment has invoices, if the payment has not any invoices the journal and the domain of this field will be for bank and cash.
Was task ID 1823023. Was PR #23609. Nice courtesy of Oscar Ulises Garza Córdova
Commit cae188514f was largely incomplete
and inaccurate in fixing the issue at hand
The aim of this commit is to deactivate the form buttons when the Html field is not completely loaded
thus preventing the temporary value of the iframe to be saved
OPW 1824545
closes#23905
- Create manually an account move
- Add a line with a credit != 0
- Click on "Add a line" => crash
`line_ids` does not contain the credit since it was not filled in.
opw-782980
Have a form view with a O2M.
The model at the 'many' end has a reference field
Have a record of the second model display in a modal
(by clicking on a record in the o2m list)
Before this commit:
The field reference was not filled up
This was because the fields to fetch on the modal creation weren't correctly set.
Obvisouly, it also created problem when trying to change the record on the modal:
spawning tracebacks because the reference field was not present in the local datas
After this commit:
The display of the reference field is as expected both in the original form and in the modal
OPW 1829822
closes#22468closes#23896
Use case to reproduce:
- Create a picking containing 2 moves that have a quantity_done greater than reserved quantity
- Validate the picking with or without backorder
Traceback due to a record that do not exist anymore.
It happens due to 2 functionality that have a wrong behavior when used together:
- merge_move function that will try to merge moves with same characteristics inside a same picking.
- action_done functionality that will create an extra move if the quantity done for a move is greater
than reserved quantity. (the extra move is used in order to propagate changes)
With our usecase:
- MOVE A, reserved_qty: 10, qty_done: 20
- MOVE B, reserved_qty: 10, qty_done: 15
action_done on move A will create a new move thus we will have
- MOVE A, reserved_qty: 10, qty_done: 20
- A bis, reserved_qty: 10, qty_done: 0
- MOVE B, reserved_qty: 10, qty_done: 15
then merge move will not only merge move A and A bis but will also merge B
which result with inconsenstencies and traceback since system will try to
process move B after A
- MOVE A,A',B reserved_qty:30, qty_done:35 (the 5 extra qty is not propagated)
This commit adds a kwarg in action_confirm that is propagated to merge_move
this kwargs is a record set taht will limit the moves that can be used for the merge
in order to merge extra move in original move
opw-1825264
Steps to reproduce the bug:
- Create a bank statement with a blank name
- Reconcile any line statement with an invoice
- Review the payment that was made for this statement
Bug:
The payment had no name.
opw:182754
When importing a bank statement containing an unknown bank account
number, the newly created account is automatically linked to the partner
of the current company.
This is due to the default value for `partner_id`.
Introduced in 6db235385a
opw-1816832
In a situation where `_action_done` is called on a batch of move line
when one of them is forced and there isn't enough quantity available
to reserve it, a call to `_free_reservation` is made in order to not
have move lines reserved on quantity now unavailable.
The issue is that the method looks for move line to unlink by making a
search on move line having a quantity reserved. As the `_action_done`
method defer the update of the reserved quantity at the end of the
batch, `_free_reservation` could try to find and unreserve move lines
that were juste processed, resulting in a traceback because there isn't
enough stock to unreserved (because the move line was processed and thus
moved at the next location).
We fix this issue by explicitely passing the move lines to ignore.
When you create a down payment invoice from an SO, the product that is used in the line is 'Down Payment'.
The description of this product, which is visible for the customer, was not translated to the language
of the customer in the SO and in the invoice. It was translated to the language of the user logged.
This fix is made to keep the same behavior for the description of an SO line and for the description
of the invoice line.
opw:1820081
The ZIP code is an optional field. When saving a payment method, this
generates a traceback since `partner.zip` is `False` while the field
expects a `string`.
opw-1829829
- Create a product A configured as:
Invoice based on: Ordered quantities
Service Tracking: Create a task in a new project
- Create a SO with product A and another product (price != 0)
- Set a 100 % discount on A
- Confirm the SO
- Record 2 timesheet entrieson the created task
- Generate the invoice for the SO
- Validate the invoice
A traceback (zero division) occurs.
The method computing the timesheet revenue ponderates the revenue per
currency by the ratio price on invoice over price on SO line. Since the
price on SO line zero, it fails.
We assume a ratio of 1.0 in this specific case.
opw-1829893
Rémi Rahir