When paying an invoice in USD, using EUR as payment. The residual amount was shown in the payment currency instead of the original invoice residual currency.
closesodoo/odoo#26916
Steps to reproduce the bug:
- Create Product P: with BOM type - Kit and BOM components > Set - Invoicing: on delivered quantity
- Create SO with P and confirm - delivery 1 will be generated
- Cancel the SO - delivery 1 - will also get canceled
- Reset the canceled SO to quotation and confirm it - new delivery 2 will be generated
- Validate the delivery and receive product KIT
Bug:
Check SO - 'Delivered quantity' was not updated
opw:1888449
closesodoo/odoo#27358
Steps to reproduce the bug:
- Create a partner P with communication type set to BBA
- Create an in_invoice I for P with a BBA structured communication
- Validate I and try to duplicate it
Bug:
A UserError was raised "Empty BBA Structured Communication!"
opw:1883982
closesodoo/odoo#27331
Rev. db9b91ff removes a use of a mutex where it could end up in a
deadlock situation (and where the use of the mutex wasn't
necessary). However, it caused an issue as the following scenario
didn't work anymore:
- in a form view with a one2many with fields A and B (required),
with an onchange on A setting B,
- add a row and set a value for A,
- click on 'Save' directly (before the onchange RPC returns)
- whereas it should wait for the onchange to return before
trying to save, it tries to save directly but faces an unset
required field, and displays a warning to the user.
The reason is that, before saving, the FormController asks all its
widgets to commit their value (through a call to commitChange).
This call was, prior to db9b91ff, done in the mutex. The onchange
RPC being itself done in that mutex, we thus waited for the
onchange to return before calling commitChanges. After db9b91ff,
since there was no longer a mutex, commitChanges was called
directly, and the editable list returned a warning as one of its
required field was unset.
This commit ensures that commitChanges is called once all onchange
RPCs are done, by waiting the mutex to be idle.
Before this rev., if the user clicked on a tag to open the color
picker, and then clicked in the dropdown, but not on a color, the
color picker closed itself, and it was no longer possible to open
it again.
This issue came with the migration to BS4 and its following fixes.
As the color picker is now a classical BS dropdown, it closes
itself automatically, so we don't need to manually close it on
focusout.
Task 1878254.
Since 6dc37ee461 a d-none class was added to hide the menus in the
navbar during the start of the navbar. A timeout was set to mimic the
old behavior and let enought time to bind events on menus.
When the project app was installed alongside with all other apps on the
runbot, there was not enough place in the navbar. This resulted in a
race condition at the begining of the project tour.
With this commit, the d-none class is immediately removed and then the
menu are started (binded to events) before the tour has the hand to
continue its next step.
The view 'res_config_settings_view_form' doesn't exist in the module
l10n_be, so as the field wer are referencing in the xpath is added in
module account, we inherit 'account.res_config_settings_view_form'
instead.
When we get the existing tags to append them a new id, we don't get a
list of id but a list of tuple with one id, this only append if you have
more than one accounting of these country installed, as the first time
it will return an empty list. So the command sent to the ORM, is not
built correctly.
To fix this we just append commands '4' that will be append in a list.
This may be completely broken/wrong, but damn if it doesn't speed
import up (2mn to 30s, the main cost center goes back to updating
computed fields during/after creation fields).
After installing a bunch more modules including account & some others,
company-dependent fields turn out to be horrendously inefficient (more
or less entirely unbatched): near 80% of runtime is taken by setting
those fields on the partners being created, split 28%/51% between
getting the default values (_default_company_dependent) and setting
them (_inverse_company_dependent).
clear_cache on *every* set_multi call is a bit extreme and cause test
problems (test_pickings_transfer_with_different_uom_and_back_orders
has a super fucky behaviour wrt caching so breaks when clearing the
cache on every set_multi) so only cache the "default"
case (res_id=False) and only clear when specifically setting that.
This makes fetching default values essentially disappear from the
profile.
A proper ref() call implies an exists(), which isn't that expensive
but piles up over a few thousand calls.
The partner import test case trigger 7394 calls to exists, for a total
of ~6% runtime (and under 2% for the actual xid lookup).
odoo.fields.Selection.convert_to_cache checks that values being set on
the field are valid (part of the selection's values).
For res.partner because of the tz field that means duplicating a list of
~600 timezones and sorting it every time we create a partner. Which for
my test case is 2500 times and burns 3.8% of total runtime for
absolutely no reason.
statically compute the reordered tzs list and just return it as-is from
_tz_get.
Followup from the previous commit: before this, _write takes 32% of
total runtime, of which 13.7% is ultimately assignable to add_todo.
Turns out for the test case we mostly keep adding records to recorsets
where they're already present, so the 13.7% of runtime in add_todo are
mostly spent creating orderedsets (11.17) then converting those back
into recordsets (1.75%) with some time spent creating lists and
appending records (already present) in them.
Checking if the records are already present before merging them in
decreases add_todo's runtime cost to 0.5%, and ultimately _write to
20%.
As many of the ignorable calls were merging a singleton or an empty
recorset into the parent recordset, optimising for these cases was
added to BaseModel's <= and >=.
Note: all costs are according to cprofile on my machine, as a fraction
of total time to import, python-flamegraph has somewhat different cost
distributions, YMMV. Profiles use test-import of a 2500 partners file,
with name, country, street and 0~4 tags, all randomly
generated/assigned.
Costs were profiled as split 8.5%/32%/57% between data conversion,
creating records (Model.create/Model._create) and populating stored
computed fields for a total import time (unprofiled) of 1mn (±2s or
something).
For the creation step, 27% (of total runtime) were assigned to the m2m
(fields.Many2many.create), almost all of which (25%) was assigned to
accessing a record's id in a listcomp in a loop.
Optimisations:
* optimise the case where we're only adding / creating values:
represent the relation as a dict of sets instead of a set of pairs;
commands 5 and 6 will only operate on the current record's value,
instead of traversing all pairs in the relation
* optimise accessing the value of an id field by hand-inlining the
various bits, this is mostly obviated by the other previous
optimisations (number of Id.__get__ calls reduced from 5.4 millions
to 0.55) but given how common accessing a record's id is (and
how it's usually considered to be free) it's still a good idea: cost
of accessing the id field was reduced by 75% (0.55 million accesses
went from 3.32% of total runtime to 0.83%)
Without profiling, time to import my test file went from ~1mn to ~45s.
Purpose of this commit is to have a hook to allow to set CRUD actions
on node in fields view get for other views than those defined in base or
web. For example grid view defined in enterprise does not have its
CRUD actions correctly set.
We choose to extract the access rights set on nodes in a separate method
to ease inheritance. The whole postprocess_and_fields does a big mixup
of updating the node, computing fields, computing the arch and could
probably be cleaned. This is however far from the simple purpose of this
commit and we choose to make a small diff without refactoring things
especially in a near-stable version.
This commit should not change anything from functional point of view.
Since 76b7242 if we have a recurring event with 3 occurences:
[4th 4:00-4th 5:00] [14th 4:00-14th 5:00] [24th 4:00-24th 4:00]
And we detach the first one to modify it, then when getting the
info of reccurring events not detached the system get:
- starts: [14th 4:00] [24th 4:00]
- stops: [4th 5:00] [14th 5:00] [24th 5:00]
And wrongly apply the current filtering over:
[14th 4:00-4th 5:00] [24th 4:00-14th 5:00]
So the issue hides recurrences of event wrongly if:
- they have not been detached
- they don't have a duration of 0
- one or several previous events have been detached
- the stop date of the nth previous event occurrence (nth equaling
number of detached previous events) is not in the current filtering.
With this change, the stops are also filtered based on start of
occurrence + duration.
Without the change, the added test fails with:
False != '155-20120301120100' : Last event should be found searching it by date range
note: for 10.0 up to not including 11.0 which is solved with #26901
opw-1866151
closes#26887
Since 76b7242 if we have a recurring event with 3 occurences:
[4th 4:00-4th 5:00] [14th 4:00-14th 5:00] [24th 4:00-24th 4:00]
And we detach the first one to modify it, then when getting the
info of reccurring events not detached the system get:
- starts: [14th 4:00] [24th 4:00]
- stops: [4th 5:00] [14th 5:00] [24th 5:00]
And wrongly apply the current filtering over:
[14th 4:00-4th 5:00] [24th 4:00-14th 5:00]
So the issue hides recurrences of event wrongly if:
- they have not been detached
- they don't have a duration of 0
- one or several previous events have been detached
- the stop date of the nth previous event occurrence (nth equaling
number of detached previous events) is not in the current filtering.
With this change, the stops are also filtered based on start of
occurrence + duration.
Without the change, the added test fails with:
False != '27-20120301120100' : Last event should be found searching it by date range
note: 11.0 version of 10.0 #26887
opw-1866151
closes#26901
The search on project were done as sudo with a domain matching the
"project_task_rule_portal" rule. This commits remove the sudo call
and corresponding domains.
This replace lpe's fix b8fe404e, and user connected to portal to see
his tasks, avoiding an error during crawling tests:
Error use case:
User try to access a task list from /my/projects with a filter on a project.
The project filter does not exist in task list since the rules applied are for
portal user -> an error is raised
Now, project list on /my/projects and the filter available on /my/tasks should
be the same.
Crashed on installation because there is a reference in data/report_layout.xml to a template that is defined in report/din5008_report.xml (external_layout_din5008).
The report/din5008_report.xml should be loaded first to avoid this error.
When the module "base_address_extended" was installed, the contact addresses
of a company were not updated when the company address was updated.
opw:1879968
Commit https://github.com/odoo/odoo/commit/903ff171acbef7f9fe6e533f43b99eba801b200f
lowered the font-size to 14px for the frontend by customizing the
bootstrap variable in the portal app. It changed the web_editor
rte_inline tour accordingly.
This however broke the test on runbot "base" database, as the font-size
in the editor without having installed the portal app was still set to
16px. Commit https://github.com/odoo/odoo/commit/e3bc059c3649a05c12cd3c8099092282c10141b7
only moved the failed test from "base" to "all" database.
This commit unifies the font-size for all frontends by setting it in the
web app. So, after this commit: reports, editor, login screen and
frontend will always have a font-size of 14px no matter the application
which is installed (except themes).
- Set up a 10 % tax with a 'Tax Due' as 'Based on Payment'
- Create a bank statement of 110, Reconcile
- Create a new AML for the reconciliation using the mentioned tax for an
amount of 100
- Validate
The tax amount does not appear in the Generic Tax Report.
This is a specific case where the reconciliation process creates the
payment itself. Therefore, the tax amount should appear in the report.
To do so, we explicitly send the `tax_exigible` value on the AML, and
propagate it to the tax line.
opw-1858492
Changing the partner on a picking triggers an onchange which might
modify `location_id` or `location_dest_id`. However, when the picking is
not draft anymore, these fields are not supposed to be changed.
opw-1872635
Have a send email automated action on invoices upon validation (write)
Go onto the credit notes, create one, and validate
Before this commit, at the creation of the attachment (the invoice pdf), there was a traceback
because default_type was in the context containing 'out_refund'
And that attachments also have a field 'type'
So the default_get of the latter got a value that wasn't correct for its field
After this commit, we clean the context of the default_type context key since it
is irrelevant beyond that point
OPW 1868638
closes#26621
Before this commit, when paying a confirmed SO with the token access with Stripe,
Clicking on the button "pay now" wouldn't do anything, because the id of the SO couldn't be retrieved
After this commit, the regex that does just that is more generic and the flow works
OPW 1881192
closes#26884
In the first attempt at #26134, the pot_targets was cleared after creating
the pot_rows object.
Since the rows not present in the pot_targets are now skipped, clearing the pot
should not be done.
Still use a temporary list pot_rows to avoid modifying the list we are iterating
on.
Update the .po test file to match the new file format
Closes#26881
cherry-pick of 428fbd0381 that was reverted at 737ba55e1e as it was making
tests fail
The following commit will correct the tests
This commit only reverts the revert
Gustavo Valverde