Trying to create a module through the interface will blow up as
computing the `desc` leads to a concatenation of the module's addons
path, the module's name and a hard-coded path, which does not work as
the module does not have a name yet. This creation attempt can be
performed as the admin through m2o fields.
Given said creation through the UI doesn't really make sense, disable
it on the relevant fields.
Fixes#23059
Purpose
=======
The warrants are not displayed on the same payslip than common salaries, and therefore it is confusing to see all the different concepts matched into the same payslip.
Before this commit, the uom defined on the sale order line and on the
purchase order line was propagated to the moves. This is not the
behaviour of v8-10 and may confuse the stock operator (one time he's
working in dozen, another time in units for example). It also leads to
rounding issues if the configuration is not adapted correctly (product's
uom is in units, sale order line is in dozen, the rouding precision on
the uom is left to their defaults, now if a dozen is partially available
there's a good chance converting back and forth form dozen to units will
break).
An ir.config_parameter was added to restore the behaviour before this
commit.
Overly attached cache's overhead turns out problematic. Clearing the
cache after batches of records keeps the cache overhead low and does
not change performances.
Explanations:
env.cache is 3 levels of maps {field: record_id: {env: value}}, where
env can be either an Environment or a pair (cr, uid) depending on the
field's dependency on the context or not.
This can be an issue when the current request loads many fields in an
enormous number of records in a single environment. The (PaaS) case
here was the export of a res.partner field from 36358 records in a single
environment[0]:
* prefetch expanded the single field to 68, leading the base `cache`
to have 68 entries. getsizeof(d<len=68>) == 3360 (3kB, which we will
soon see we can ignore entirely).
* *each* of these entries would hold a map of 36358
records. getsizeof(d<len=36358>) = 3146016 (3MB), 68 times = 213MB.
* finally each record entry is also a {(cr, uid): value}, here the
dicts have a single entry which makes them 280B, and their key is a
2-tuple "worth" 72B, or 352B/record/field, or 352 * 36358 * 68 ~
870MB[1].
For a total of ~1GB, which is roughly the issue we can observe.
Future possibilities: extract the cache-clearing iterator to be more generic
and available on BaseModel directly? Or even make the default iterator
batched & cache-clearing?
[0] note that sys.getsizeof only provides the size of the object it's
called on, it is not recursive
[1] slightly more in actuality as there's some variation between the
leaves depending on the field type e.g. M2O values are a 1-tuple
adding 60B, ...
Fixes#22475
With more than 1 level of generic type, the "closure" of generic
parameters would get tokenized by python as a single right shift (>>)
rather than two gt (>, >) leading to our own tokenizing pass getting
lost and blowing up.
Fix by explicitly recognizing and splitting (>>) into (>, >). We could
consider writing the entire tokenizer ourselves instead of
post-processing Python's but given the entire post-processing function
is currently shorter than just Pythons' tokenizer's regexes...
Anyway issue found by vsc while trying to write better docstrings.
Before this rev., a traceback was raised when the user tried to
edit the company data, by clicking on the company logo in the
submenu (community edition only). This was due to code not being
converted after the ActionManager refactoring of 7b6056a0.
Also ensures that the logo is properly reloaded by specifying the
timestamp in the img url as a query string parameter instead of an
hash param, since changing the hash doesn't seem to be enough to
fool the browser's cache anymore.
Since the new year, the graphs in sale dashboards were not displayed
properly when grouped by week. This was because the computation of the
number of weeks in 2018 gave "1" as a result as this was got from the
week number of 31/12/2018 which is in fact in the first week of the
ISO year 2019.
This commit solves the problem by using the 28/12/xxxx which is always
in the last week of ISO years.
opw-816758
If a record is deleted *and* has property fields, the deletion of the
property fields will trigger the various recomputes before the record
itself has actually been deleted, and thus stuff which depend(ed) on
that record will be recomputed under the assumption that the record
still exists, which probably will not work.
Under the assumption that the same issue would occur when deleting
more than one batch of records (unlinking the data, values or
attachment would also trigger a recompute before the proper end of the
function and could lead to incoherence, e.g. some of the records being
deleted being visible to recomputes), lift the entire effective body
of the unlink into a norecompute context, to ensure that only the very
final recompute (from the top-level unlink) is actually triggered.
opw-807036
We would like to have an overview of project forecast that include
leaves, for this we need to implement several kind of 'leaves' directly
in resource module.
These kind of 'leaves' can be defined via the hr.leave.type model (only
visible in base.group_no_one (choices currently are 'leave' and 'other')
* Add field time_type on resource.calendar.leaves
* Add a domain restriction that allows for filtering on this field
* Add tests
It will enable to retrieve data from the resource module based on a
domain that we pass to the model. It can be used in order to filter on
certain leave types only.
* In resource_mixin and resource add a way to use a domain in order to
filter the leaves
* In resource_mixin add a method to get the work/leaves hours count
Before this commit, if the first exported field of an M2M is `id` (the
xid) the entire M2M is folded into a single cell with comma-separated
xids and any following field is ignored. If `id` is any but the first
field, the export behaves normally (with the m2m exported as a "table"
inside the parent record).
This behaviour makes sense for import-compatible exports where the id
is the only thing which can be exported anyway, but it is troublesome
outside of that mode as the behaviour of m2m under export becomes
incoherent/unpredictable (ish) as it depends on the position of the
m2m's `id` in the exports list.
Change it so we only perform folding in import-compatible mode (which
is the default for backwards compatibility with e.g. API calling
export_data directly & the like).
opw-813361
Fixes#22600
- In SaaS-16 we have added a related on the employee's department.
This causes access rights issues when changing the employee's department.
We do not want to rewrite all the old records, only the new ones should use the new employee's department.
Use case to reproduce:
- Install sale_stock
- Create a SO
- Cancel it
Traceback
It happens because _log_activity_get_documents need at least
one entry in the dict orig_obj_changes.
- options inside the template will not be correct if we set options in start method(template already loaded when start is call), for the correct value of options inside the template we must set it inside willstart
(PR #22751)
Before this in the event of a network failure that lasts longer than the respective return cycle of the deferred call,
this deferred will keep in purgatory forever (until reload of the client).
This is not problematic in the normal use case, but working with offline modules, such as POS or similar making use of the
long polling concept for synchronization purposes, this generates toxic behavior.
Simply: The client state never recovers on it's own from the network failure
(PR #21653)
Before this in the event of a network failure that lasts longer than the respective return cycle of the deferred call,
this deferred will keep in purgatory forever (until reload of the client).
This is not problematic in the normal use case, but working with offline modules, such as POS or similar making use of the
long polling concept for synchronization purposes, this generates toxic behavior.
Simply: The client state never recovers on it's own from the network failure
(PR #21653)
The settings of a channel were available in debug mode only. Adding a settings button on each channel allows to read/edit a channel settings easily.
Remove the unsubribe button and the settings button from the top of the page since they can be acceses another way now.
Apparently, SEO audit thingies (possibly google's own? unclear) don't
ignore *empty* keyword or description meta tags, then complain that
they're duplicated (there's a use case for SQL-like nulls).
So remove the keyword & description metas entirely if the
corresponding fields are empty.
OPW-815492
Issue 1) and 3) in 73f7567627 still
occured in 11.0. It seems this was not fully forward-ported, most
likely due to conflicts caused by
ac89783d2f.
opw-782855
When onchange RPCs return a command 4 (LINK TO), the res_id of the
record to link is given, and the BasicModel has to read the fields
in the view for that record. When one of those fields is an x2many
(for instance, displayed with widget many2many_tags), the
subrecords in the relation must be read as well (at least their
display_name).
Before this rev., this last part wasn't done by the BasicModel, and
as a consequence, the many2many_tags widget was always empty, even
though there were records in the relation.
Same thing applied to reference fields, but this is way more
uncommon.
This rev. ensures that x2manys and reference fields are correctly
fetched in this scenario.
Before this commit, there is an issue with one2many lists with records that
have been created on 'default_get': if the record has a required field that
is empty, when the user clicks on this empty required field and then somewhere
else, the record is removed from the list.
The cause of this bug is that these records have invalid field changes, here
the required field that is empty. As a consequence, it checks whether the
record is "new", and if so, removes it visually from the editable list.
(Note: a record is "new" when it is not stored in DB).
This behaviour is expected when discarding records created from "Add an item".
However, that is not intended for records that have been created as default
items of the list. These records are still considered as "new" items, because
they are not stored in DB, but they should stay in the list on discard.
This commit solves the issue by making an additional check before assuming
that the record for which we discard changes comes from "Add an item":
if the record in the list has been created before user interacts on the list
(in other words, the record has been added in the list when the user accesses
it), then we should not remove the record from the list, even though the record
has some invalid fields from the savepoint (e.g. empty required).
opw-806650
* account, board, hr_holidays, mail, sale, website_sale
Small fixes on nocontent onboarding screens.
Initial commit: https://github.com/odoo/odoo/commit/a87d761fdbf345ada5dc93e0a686b08a0f5a0417
Details:
- list: centered;
- pivot/graph: centered + empty folder face;
- Dashboard app with nocontent helper;
- Discuss inbox/starred: centered without neutral/smiling faces;
=> no faces because it's too much with animated
rainbow man when emptying the any of the boxes.
- hr_holidays: fixed onboarding screens;
- (technical) dropped obsolete 'o_view_nocontent_container' style;
- manual reconciliation 'nothing to reconcile': centered + inside form sheet;
=> renamed account's o_view_nocontent to o_view_noreconciliation,
so that it doesn't use the style of views.less.
- kanban: nocontent helper above the columns (if any);
- texts "no order to upsell"/"abandonned cart" paragraph split in two.
5ca0ef97 was forward-ported from 9.0. In 10.0 the function signature
of product.uom's _compute_price has changed. In 10.0 it uses the new
API and it no longer takes a to_uom_id keyword argument.
opw-816738
Before this commit, the domain use to retrieve pages in enumerate_pages was
wrong (mainly used for sitemap.xml). It would only show website.page that:
1. are published
2. are indexed
3. have a publishing date (whatever date, future or past).
Last point was incorrect
Now, we correctly retrieve pages that:
1. are published
2. are indexed
3. have no publishing date or a publishing date in the past
Martin Trigaux