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
Since the BS4 is using 'justify-content' property to justify grid columns,
the columns are not justified properly in pdf because wkhtmltopdf does not
support this property.
So we set supported property '-webkit-box-pack' instead of 'justify-content'
through the post processing regex that will add limited support for grid
columns justification in pdf reports using BS classes only.
However, 'justify-content-between' / 'justify-content-around' classes are
still not supported due to the limited flex support by wkthmltopdf, and so
report designer might have to put some extra efforts for such rare cases.
Task: 1880709
Closes#26846
The <!DOCTYPE> declaration must be the very first thing in an HTML
document, otherwise you may experience that the preference is given
to the "user agent stylesheet".
This is the case while printing PDF reports using the 'minimal_layout' template.
For example, layout for 'Picking Operation' report will be different in HTML and
and PDF reports. Text inside <th> will be aligned left in the HTML report, while
center in the PDF one. The issue is there since a long time, but was not obvious
enough to catch till now. (For example, in previous BS versions, explicit rule
was present to align text to the left inside <th> tag, and so the layout did not
break by luck. BSv4 afterwards, this rule was removed, shedding light on this
issue).
This commit improves the behavior while printing PDF reports by placing
<!DOCTYPE> declraration at the very beginning so that preference will be
given to custom stylesheet over "user agent stylesheet".
Task: 1880709
Closes#26846
With BS4, the website's font size was set to 16px instead of 14px as
before. We finally decided to force the 14px back. This commit also
moves some bootstrap variables extensions to portal as it should have
been done and reformat the files to match the bootstrap _variables.scss
file.
In the Route form view, there is a table summerizing all the rules that
define the current route. The order of variables was not so clear.
Task id : 1879552
This commit adds two reports on the product packaging model. They act as
labels representing the packaging. The first one is a pdf, the second
one is a text one to be printed thanks to a zebra printer.
If we use the cross tab, and the session has more than 50 seconds (or
does not exist), a remove is done in the init. The change trigger in
local storage causes the value of _lastNotificationID to become null.
This causes a loading error in the long poll.
- payment.acquirer have many fields with 'required_if_provider'
attribute and while saving form it gave an error like "Required
fields not filled", so it was confusing to know which required fields were empty.
- after this commit, it is displayed like "Required fields not filled (field name)"
opw:1881054
Remove part in service_mixins who hide this error. Queries must be able
to be canceled for better performance. Also in the case of longpolling,
if the request is not canceled, wait for a server message or the maximum
time (30 sec) to add or delete channels.
Browsers add a 1px padding to inputs but they don't do it for the
select elements, which makes them unaligned.
Tested under Chrome 68, Firefox 61 and Safari 11 on MacOS 10.13.6.
'account_accountant' is only defined in enterprise.
Before this commit, many of us forgot to manually install it
before running main_flow_tour in enterprise.
Plus, it was difficult to know that a required module is missing
when a step failed. The error was not clear.
Now, the post hook will check if this module exist (it's the case in
enterprise) and will install it.
Purpose
=======
The reified view removal makes sense from a functional point of view
as it allows to customize the res.users configuration view.
But this PR is also impossible to migrate efficiently as all the custom
groups that are not defined on the res.users model and that are not included
in the res.users view wont be displayed anymore.
It is still possible to add the group by hand in debug mode, but actually it is
not the clean workaround.
This could be done again in a better way, for example by defining a new field
like "UserGroup" and by allowing a easy customization with the Odoo Studio feature
Specification
=============
- Remove the generic methods to define the user's group computed fields
- Reintroduce the reified view
- Keep the main interesting feature of the original PR: Display the user's type
(Internal User, Public, Portal) as a selection field.
Xavier Morel