When creating sales/purchase receipt for a journal having a secondary currency, an error was raised as the amount_currency had the wrong sign (compared to the debit/credit).
Was Issue #1819396. Was PR #23768
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
When creating a timesheet, several fields need to be recomputed:
- `currency_id`
- `group_id`
- `department_id`
- `is_timesheet`
- `validated`
When `validated` is computed before the other fields, the recomputation
will lead to an `AccessError` because of the rule
`hr_timesheet.timesheet_line_rule_user`.
Since the test `test_timesheet_validation_user` expects an
`AccessError`, the test succeeds. However, from time to time,
`validated` is computed last => the `AccessError` is not raised.
Actually, a `ValidationError` should be raised in this case (from the
`create` override in `timesheet_grid`).
Before this commit:
Clicking on 'unstar all' button removes all messages from starred channel
but it only decreases the counter as many as there are displayed messages
on screen.
For example, if there are 40 messages starred, only 30 messages
are on screen (default limit) but unstar all will decrease counter
only for those messages instead of 40.
After this commit:
clicking on 'unstar all' button will correctly take in account all
fetched messages and not only displayed messages.
So now, after clicking on 'unstar all' button will update the starred
counter to 0.
task-ID: 33958
Previously, the ISR reference was computed from the iban number but it seems some banks (for example UBS) use arbitrary ISR references that needs to be manually set.
Was task: 40975
Was PR #22931
After this rev., in Discuss, messages are automatically loaded when
the user scrolls to the top of the channel.
Task 33958
Co-authored-by: Aaron Bohy <aab@odoo.com>
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.
The caller of `read_group` can now provide the aggregating function to use for
a given field:
# set aggregating operator for fields 'foo' and 'bar'
model.read_group(domain, ['foo:sum', 'bar:avg'], ...)
One can also aggregate the same field several times, by giving a specific
output name for each:
# aggregate 'foo' with both 'min' and 'max'
model.read_group(domain, ['foomin:min(foo)', 'foomax:max(foo)'], ...)
With project_issue installed, and when deleting an analytic account, a search
is done to check if there is linked issues. When the current user has no access on
the project.issue model, an error is raised. This check should be done as an admin.
Before this commit, when accessing the payment page with arbitrary amount
(/website_payment/pay?reference=Testinvoice&amount=150.0¤cy_id=6&country_id=)
A traceback was thrown because the keys concerning the partner were not present in the dictionary
that prepares the values for the form that we send to Stripe
Considering that those info are not mandatory for stripe (although not very good practice -- the more info the better to verify an identity)
we ignore them if not present
After this commit, the public route works fine
OPW 1832164
closes#23948
Before this commit, the smart button on the SO was computed
with only the SO's name field
In a multicompany setting, it could give up invoices from other companies
After this commit, only the invoices of the same company as the order are accounted for
OPW 1831551
closes#23925
To be able to retrieve the base amount of cash basis taxes lines, additional journal items are created for the base as well in the journal entry generated by the payment.
However, these additional journal items debitting and creditting the same account are considered as pollution in reports.
This module and hook allow to move these additional lines to an another account, if needed.
-task: https://www.odoo.com/web#id=35605&view_type=form&model=project.task&action=333&active_id=967&menu_id=4720
Was PR #23349
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
This is needed to allow having a single bank statement validating 2 payments in case of our internal OGONE processing. An incoming commit in account_batch_deposit will explain more in-depth the use case covered
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
Deleting comment / note / activity subtypes make the whole system quite
impossible to use. Indeed the whole communication mechanism is based on
those subtypes that are hardcoded.
There are some use of env.ref() about subtypes to try to avoid having those
removed. As there is some work to make some xml ids impossible to delete we
can already update some code to use xmlid_to_res_id instead of env.ref(). This
leads to some gain in query count as there is no exists() that is performed.
Globally this merge allows to save a few query on each message post and about
7K on community runbot.
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, ...)
As explained in previous commit we can use xmlid_to_res_id instead of ref()
which leads to some query gain. This commit update some other less important
places: when setting activities as done and in the composer. This lead to
a gain in tests involving activities and composer, including tracking
triggering a template. On community runbot this leads to a gain of about 1K
queries.
Priyanka Kakadiya