The license was missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
The missing licenses were add in all version starting from
12.0 in repos odoo, enterprise and design-themes.
Starting from this commit, when a license is not defined,
a warning will be triggered.
closesodoo/odoo#74347
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit adds a new attribute mode for position 'replace' to the xpath feature.
This mode can take 2 values:
- 'outer' (default mode if not provided) that will replace the sibling target
- 'inner' that will preserve the sibling target
If base arch is:
```html
<p>
<field name='x'>yyy</field>
</p>
```
`<field name='x' position="replace" (mode="outer")>zzz</field>`
```html
<p>
zzz
</p>
```
`<field name='x' position="replace" mode="inner">zzz</field>`
```html
<p>
<field name='x'>
zzz
</field>
</p>
```
Mode inner is useful for theme or render flat content, but not recommanded to
be used in page editable since we ignore the inherit-branding part until now.
task-2172208
closesodoo/odoo#48679
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Okan SUMER (osu) <osu@odoo.com>
Co-authored-by: Jérémy Kersten <jke@odoo.com>
Explain the situation when a manual change has been done to the sequence
of `account.move`. This was needed because some user didn't realize that
they changed the sequence, and when they realized it, it had polluted
multiple numbers after that.
closesodoo/odoo#74326
X-original-commit: 56f7afb253da6560cddae121f5b6cdab3e3b1c6e
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Before this commit branding was removed only from nodes using t-esc and
t-raw.
This caused problems such as the ribbon preview rendering being
propagated across all products because the oe-model/id/xpath fields were
referencing the product card view itself.
This appeared because of the conversion from t-esc/t-raw to t-out.
The branding used to be removed from nodes using t-esc and t-raw, but it
was not removed for t-out.
After this commit the branding is also removed from nodes using t-out.
This restores the old way the ribbon preview was rendered, and therefore
also fixes the issue described in the related task.
task-2527056
closesodoo/odoo#74145
X-original-commit: 9e83dd83a39b542ec0e0d3045bcffcf24406c94b
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
PURPOSE
This commit aims to improve the 'Contact Tags' sections of the 'Contact'
module by adding a color picker (on the list and the form view).
SPECS
- Add a color picker on the 'Contact Tags' sections (i.e: list and form view)
- Add a placeholder for the 'name' field of the form view.
- Update the label of the 'color' field.
LINKS
Task id: 2608410
closesodoo/odoo#74033
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
makes raw a bit more expensive than necessary on creation
closesodoo/odoo#74132
X-original-commit: f9b12a59ea618fa598f0ffb6869f027c6a39bc2d
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
`load_views` calls `get_bindings` to render Action and Print menu. Before this
update, it read all action fields, including heavy computed fields
like `search_view` (which calls fields_view_get). But in fact just few fields
are used.
This slighly improves response time and data size.
closesodoo/odoo#73983
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Define `data-hotkey` on most used action buttons.
For the modals, the following keys are dedicated for "special"
actions:
- Alt+G: add
- Alt+V: save
- Alt+Z: cancel
closesodoo/odoo#73275
Taskid: 2588233
Related: odoo/enterprise#19464
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This field was only used by thinking it was the banks owned by the
company, and not the banks registered for all partners by that
company.[1]
It has always been like that, since 7eab8e26d3
even though the field didn't exist on `res.company` before that
refactoring.
[1]: checked with the following regex `compan((y(_ids?)?)|ies)\.bank_ids`
closesodoo/odoo#73229
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Requires markup every markup-using tip content as Markup. Would be a
nice occasion to migrate everything to a markup-safe markdown I think,
especially if we could migrate the translations so we don't lose them.
Before this commit, the implementation crashes when the ancestors of a
record contain non-accessible records. This fixes the code to avoid it
to crash.
We also make the semantics of hierarchical searches more consistent in
this case: searching with operators 'child_of' and 'parent_of' returns
the subset of accessible records that satisfy the hierarchy operator.
We actually make it coincide with the results of the search when using
the "_parent_store" optimization.
closesodoo/odoo#73962
X-original-commit: 3e1b960acf3f6a726338476ba9e62e5ef5c84ef9
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When installing some modules, if an other action is undertaken around
the same time it is possible for the two to deadlock, leading to the
two workers being killed by the wallclock limit watcher. This should
only be an issue on the *threaded* server, workers should not be
affected, meaning the issue is not reproducible on runbot.
A relatively reliable way to trigger this issue manually is to create
an empty database, on the "apps" kanban view install the "sales"
application, and as soon as the UI gets unblocked install the "CRM"
application. An other method (also reliable but not really doable by
hand) is to simultanously log in and install the sales
application (`sale_management` module).
The core of the issue seems to be in `_button_immediate_function`:
1. `Other` has an env ready for use and has accessed various
models (so has pretty shallow locks on the tables e.g.
ACCESS SHARE).
2. `Install` takes the registry lock to create the new registry.
3. `Install` needs to update one of the tables `other` has touched,
starts waiting on the `ACCESS EXCLUSIVE` lock (the only one
`ACCESS SHARE` conflicts with) in order to execute DDL (most `ALTER
TABLE` forms require exclusive access to the table).
4. `Other` needs a new environment (e.g. `sudo()`, `with_user`,
`with_context`, ...), starts waiting on the registry lock.
At this point the two threads are deadlocked, `other` waits on the
registry lock which `install` holds, while `install` waits on a table
lock which `other` holds. Since one of the waits is on the application
side, Postgres' deadlock detector can not notice the issue. That one
of the locks is on the Python side is why only the threaded
server *should* be affected.
An initial seemingly promising mitigation attempt was to
LOCK res_partner IN ACCESS EXCLUSIVE MODE
in the prelude of `_button_immediate_function` as `res.partner` is one
of the most commonly modified models, this would force
`_button_immediate_function` to wait until all existing requests have
completed and prevent later requests from progressing.
This turns out to be unreliable, as later requests could already have
acquired an environment and would race ahead as soon as the
transaction is committed if the scheduler lets them. Trying to lock
the registries earlier doesn't work as the locking is interleaved in
normal operation and we'd just deadlock there. The commit is because
`load_modules` does not take an externally provided cursor and instead
creates its own (thus its own connection and transaction). And because
of its lack of atomicity the issue might occur regardless.
An alternate mitigation is instead to set (or drastically reduce) the
lock wait delay during module installation, installation should
normally be entirely uncontended (or infeasible in production with
large traffic) so there is limited reason it'd be waiting several
seconds on a lock. Conveniently, this means instead of the thread
being killed entirely, the install request gets aborted *and retried*,
so it can succeed a little more slowly if that allows the other
request to complete and no other concurrent request causes the same
issue.
Other alternate mitigation which got discarded: reusing registries
when creating new environments (from existing ones) if the database is
the same, that works for some case of switching environments, it
doesn't work for other where we actually fetch a registry e.g. assets
generation calls `get_modules_order` which calls `module_boot` which
calls `module_installed_bypass_session` which gets a
registry. `get_modules_order` is the last place we know we have an
existing registry. Though maybe we could strip out the entire thing
and call `module_installed(self.env)` directly?
Issue 2581648
closesodoo/odoo#73906
X-original-commit: ab84d970dcf1a9dbd5697b6600930cd1bcba3634
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps to reproduce:
- Install "Sales" module (for test purpose)
- Active `External Email Servers` email feature and set an alias
- Go to any Sale Team, and set an Email Alias
- Send an email (from outside Odoo) to the sale team email alias
- Write the body text in hebrew
- !must ensure that the mail is encoded in iso-8859-8-i.
- Go to Settings -> Technical -> Messages and open the receveid mail
Issue:
Hebrew character are replaced by `�`.
Cause:
Python does not have -e and -i codecs.
More info here: https://bugs.python.org/issue18624
Solution:
Create an alias for iso-8859-8-i == iso-8859-8.
opw-2482579
closesodoo/odoo#73934
X-original-commit: 632ed24936000cfb4cb3296a25ff6195a89109a0
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
The method is used to get progress per column in kanban view
(green-yellow-red-red lines in Project, CRM etc). There are two main
usages:
1. get statistics for ``kanban_state`` (red/green circles)
2. get statistics for ``activity_state`` (colored clock icon for overdue/today/planned)
Before this commit all cases were handled by calling search_read and then
counting records per group in a python script. This is very inefficient,
especially for ``activity_state``.
This new implementation relies on ``read_group`` when possible, i.e.,
when both grouping fields (kanban column and progressbar field) are
stored (case 1). It then falls back on a naive implementation inside
``_read_progress_bar``. Cases like 2 above can be addressed by
overriding ``_read_progress_bar``.
We also added some minimal test to ensure that we don't break anything.
1. Performance test on 60 K project.task records (kanban_state):
With a filter for 6 records:
```
| measurement | before | after |
|--------------------+--------+-------|
| number of queries | 8 | 5 |
| query time, ms | 11 | 7 |
| remaining time, ms | 21 | 9 |
```
All records:
```
| measurement | before | after |
|--------------------+--------+-------|
| number of queries | 67 | 5 |
| query time, ms | 300 | 55 |
| remaining time, ms | 1780 | 12 |
```
---
opw-2346901
task-1915411
X-original-commit: 153621bdbab94a2a94a5bbfcabb4111cbc5970d8
Co-authored-by: Raphael Collet <rco@odoo.com>
Before this commit, some tests were indirectly using demo data.
For example `env['res.partner'].search([])` would return demo data in
addition to the partners created for the tests.
This commit changes that by ensuring that the records used are limited
to the records made for the tests. Some values have been adjusted to
account for the lower amount of available records.
closesodoo/odoo#72553
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit, if a related field's path definition contained a
non-existing field (either because of a typo or field removal) the ORM
would simply send a generic Python KeyError that didn't really help in
debugging.
With this commit, we raise our own KeyError stating which related field
has the wrong path definition and exactly which field within the path is
incorrect.
See test for an example.
closesodoo/odoo#31889
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Assigning to const variable is always a programming error, and we almost
never want to have a debugger in production code (for those cases, an
ignore comment can be added).
closesodoo/odoo#73821
Related: odoo/enterprise#19694
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Despite that Werkzeug documentation specify:
'location (str) – the location the response should redirect to.'
Werkzeug support URL as location.
So now Odoo will support URL for request.redirect as argument too.
This commit closes#73729
Re-introduce after discussion with AL the function that allow to specify
a custom placeholder for a specific model.
It has been removed because no more used since we use avatar mixin for
res.users and res.company. But it doesn't means that each model should add
his own mixin and controller and ... Keep it simple!
Use it for product and product template to have a default placeholder more
representative of the model.
Courtesy of xlu-odoo for this design
opw-2513801
closesodoo/odoo#73576
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This commit adds a sanity check to the part of the ORM that uninstalls
module data, as a recap, here's how module uninstallation works:
- We fetch all data (ir.model.data) that corresponds to the module being
uninstalled (`WHERE module='my_module'`)
- We divide this data according to its type (ir.model, ir.model.field,
constraints, etc.)
- We fetch the corresponding records to each type, we delete them in a
certain order (e.g. ir.model.field before ir.model) and then finally we
delete the ir.model.data as a last step
The data is deleted in batch for maximum performance, if one of the data
cannot be deleted however, we perform a binary search until we find the
culprit(s) and we store these culprits in a list of undeletable_ids.
At the end of the process, we delete all ir.model.data **except** for
the ones that are undeletable, however, it is possible that because of
the multiple-step procedure, an undeletable ir.model.data could have
become deletable.
Imagine that an ir.model.field cannot be deleted, its module data id is
added to the list of undeletable_ids, however if later on its ir.model
is deleted successfully, the ir.model.field is dropped because its table
is dropped, in this case the ir.model.data becomes deletable, but since
we simply ignore it at the end of the process, we potentially end up
with orphaned xmlids.
This can be problematic when we reinstall the module and uninstall it
again, as the system does not expect an orphaned xmlid, will completely
crash and prevent the 2nd uninstallation of the module.
This is the case with CRM and its
crm.lead.scoring.frequency.field.field_id field, its ir.model.field
cannot be deleted because the name field (and display_name) of the same
model depend on it, so it is left as is, then further down the process
the entire model is deleted and as a result so is all of its remaining
fields, however the ir.module.data for the field that could not be
deleted remains.
opw-2575592
closesodoo/odoo#73668
X-original-commit: 75697934b34df882ec03595b876a8a6dadcef4c5
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Introduce the env variable ODOO_DISABLE_SESSION_GC to disable session_gc
on high-volume systems and avoid random slow calls as discussed in
https://github.com/odoo/odoo/pull/70063closesodoo/odoo#73376
X-original-commit: a61d459a200a56fba74f655f73b10d1ddd8e3a1e
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
The code of the Odoo editor was on another repository
and that created unnecessary overhead. This commit move
the code inside Odoo and slightly change the folder
structure.
Related PR:
saas-14.3: #73345
saas-14.4: #73348closesodoo/odoo#73272
Master: #73272
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
This branch adds request.redirect on all requests.
In case of a front end request, we do an url_for to the location.
We removed redirect_with_hash that was only for retro compatibility
local_redirect has been renamed to redirect_query, and param keep_hash has been
removed and moved.
Default code for redirect is 303 now instead of 302.
Now redirect and redirect_query make local redirect by default, you need to
pass local=False to make external redirect.
All werkeug.utils.redirect has been replaced by request.redirect.
Http.redirect now use an http.Response type, and it become easy to add an
override like 'set_cookies' e.g.
Dispatch of a website.page return an http.response too, so we first need to
check if it is a cached version before to check if it is an Odoo Response.
Migrate your code:
http.redirect -> request.redirect(location, code, local)
http.local_redirect -> request.redirect_query(location, query, code, local)
http.redirect_with_hash -> request.redirect
Courtesy of odony for help and review ;)
closesodoo/odoo#72599
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The use-case is when a "parent" field is put on the form view, as a
readonly field, and we create a new record. Before the fix, the fields
that depend on the parent record are always False, until the record is
actually created.
closesodoo/odoo#73446
X-original-commit: ff2af932c3b73dc59620a4ce17da3a13cab12cbe
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This allows onchange to recompute fields that depend on the inherited
field that has changed. The use-case we have is a model that inherits
from 'account.move'. On its form view, setting the (inherited) journal
field does not recompute the (inherited) company field.
When the field 'journal_id' is modified, the onchange should:
- assign the new value to move_id.journal_id (*)
- recompute move_id.company_id (related='journal_id.company_id')
- recompute company_id
This commit adds the missing part (*).
X-original-commit: 2e05d0a361aa06a34eecf64613821f2e92295298
Due to odoo/odoo#51075 it's an error to assign the `_date_name` field on
an empty recordset.
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 1582, in _fields_view_get
arch_etree = getattr(self, '_get_default_%s_view' % view_type)()
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 1495, in _get_default_calendar_view
self._date_name = dt
AttributeError: 'project.phase' object attribute '_date_name' is read-only
```
Issue observed on upgrade requests 2615 and 3121.
closesodoo/odoo#73401
X-original-commit: 1bbe88796a5b03ab1ab2faec1f0fe4f735fcb485
Signed-off-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: Christophe Simonis <chs@odoo.com>
The timesheet_grid icon changes when enterprise is present. This changes
the icon from base to the one from enterprise.
Closes: odoo/odoo#72336
Task ID: 2531317
It seems quite easy to have a void content in the currently new editor
that actually holds a lot of undesired information, notably a font
tag. This is annoying when having behavior based on an html field
being empty or not. In this commit we therefore improve definition
of an 'empty' html field.
Task ID-2532529
PR odoo/odoo#71793
This commit changes the warning log for Selection fields that states
that the hook could not go through the ORM for the deletion at uninstall
(because of some business error) and that it had to bypass the ORM (aka
pure sql delete) and turns it into a runbot-level log, meaning that it's
technically a warning but the runbot won't fail because of it.
This is done because for the install/uninstall tests it shows up as an
actual failure but it is not as it is non-blocking, and 99.9% of devs
won't ever see this warning on runbot since it triggers on module
uninstall anyway.
closesodoo/odoo#73332
X-original-commit: c140f545d150da05bd47f2c2dabc28c53cefe912
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
before this commit: create_text was passed in node options and due to which it
was not parsed by translate.py, pass add-label as attribute on field so that
translate.py parse it and it is translated.
after this commit: create_text will be passed as field attribute instead of
node options.
task-1923433
closesodoo/odoo#59713
Related: odoo/enterprise#19418
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
When an installed module is not installable, we don't want
to check its dependencies because they may not be available.
Erroring out on such dependencies is not needed because
the module will not be loaded anyway. On the contrary, such
errors prevent starting a database which would otherwise
function normally.
Such errors occur when doing incremental migrations where
it happen that addons are installed (from the previous version)
but not migrated yet and therefore not installable.
When we migrate lower level dependencies Odoo marks
higher level addons as "to upgrade" even if they are not installable.
That is usually harmless, except when such addons have
dependencies that are themselve not available.
This PR fixes that.
closesodoo/odoo#73206
X-original-commit: a11e8a32883b0d0deaeb2497daa585eb3d3c686e
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
This commit updates the res.currency data files to be compliant with
the ISO 4217 standard:
Add existing currencies missing from Odoo.
Remove currencies deprecated since at least 10 years.
Update incorrect currency names and rounding values.
task-2501384
closesodoo/odoo#69356
Related: odoo/upgrade#2400
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
58d3b670221b3 was not correctly forward ported, it misses the `''` fallback part
of the original commit dc20ab9c02
Without this, traceback is shown.
Step to reproduce:
- Open HTML Editor (or edit a backend view)
- Add an input with no class but a value attribute (no type or type text)
closesodoo/odoo#73057
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Domain terms of the form `('field', 'not in', [...])` generate incorrect
queries for translated fields, example (model `res.country`, field `name`):
```
psycopg2.errors.SyntaxError: syntax error at or near "ARRAY"
LINE 1: ...M "res_country" WHERE "res_country"."name" not in ARRAY['No ...
```
The root cause is that the right part of the term is not converted to
tuple.
Observed during the upgrade request 16639
opw-2525553
closesodoo/odoo#73030
X-original-commit: 7c4db97e21f74a429e56f6cae4d4786ee74f7e22
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
With commit odoo/odoo@83ffe8b we ensured that while creating a child contact, it
takes language from its parent by default if any, otherwise falls back to DB
lang.
The fix was done with help of `default_get` method. However after merge of
odoo/odoo#55995 `default_get` is now called through the onchange for o2m
fields. Now we don't get the default value of `parent_id` here which
re-introduced the bug.
This commit fixes the behavior by setting the language from onchange
while creating the child contact and thus (once again) making the
language from parent contact prevail on DB lang.
We also re-use default_lang coming from parent in form view, which partially
reverts odoo/odoo@83ffe8b .
TaskID-2416922
closesodoo/odoo#72960
X-original-commit: 4d9b85bd07e487e7843dc458332dede36c2889c2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* Objectives:
- Allow the generation of empty date/datetime groups outside the bounds
defined by the existing data during a read_group, with the fill_temporal
context key.
{[Jan - empty]->[Feb]->[Mar - empty]->[Apr]->[May - empty]}
This will allow to get a guaranteed amount of groups regardless of the
existing data.
- Request contiguous date/datetime groups between custom bounds which do not
cover the entire domain of existence (existing data)
[Jan] {[Jul]->[Aug - empty]->[Sep]} [Dec]
If some records were "forgotten" before the desired "interesting" period, we
won't have to display "many" undesired empty groups to show them.
* Implementation:
Modify the fill_temporal context key to accept a dictionary format,
with 3 keys, to be used in _read_group_fill_temporal:
1. fill_from
2. fill_to
3. min_groups
- (1., 2.) offer a way to guarantee that at least a certain date range will
be returned as groups. They are also the bounds to fill. Any group outside
those bounds will not be removed, but there will be no empty group added. If
any of those keys is omitted, existing bounds are used, if applicable. If
fill_from and fill_to are not specified, and there is no data, no group is
returned.
edge case example:
existing dates: [Jan, Sep]
fill_from: [Apr]
fill_to: [Jul]
interval: 1 month
result: [Jan, |Apr, May, Jun, Jul|, Sep]
general usage examples:
a. We have a Forecast in a Kanban view. We are in April and we want the
forecast to cover the [Apr - Jul] period.
- domain: [(>= Apr), (<= Jul)] (limit the read_group to
the forecast)
- fill_from: Apr (current month)
- fill_to: Jul
The result would be [Apr, May, Jun, Jul]
b. We want the same Forecast [Apr - Jul], but there is a chance that some
records were forgotten in Jan, and we want to be able to reschedule
them, but we don't need the fill_temporal to take effect from Jan.
- domain: [(<= Jul)] (we removed the first bound)
- fill_from: Apr (current month)
- fill_to: Jul
The result would be [Jan, |Apr, May, Jun, Jul|]. We have the forecast
with the fill_temporal, and every month preceding the forecast as long
as there is at least one record in it (no empty month before the
forecast).
- (3.) Will be used as a way to guarantee a certain amount of returned groups
for a read_group grouped on a {date, datetime} field. This will only work
if there is at least one group to be used as reference (starting point) to
create supplementary groups if necessary.
example :
existing dates: [Mar, Apr]
min_groups: 4
interval: 1 month
result: [Mar, Apr, May, Jun]
- fill_temporal: {} will be considered as True (backend & frontend)
- The new key options are independant from each other (do not require the
others to be set in order to function properly)
Task-ID: 2243913
PR odoo/odoo#69380
1. Objective
- We are in a Kanban view, and we group by a "date/datetime" field.
- In order to "quick create" a record in a group, or to "drag & drop" a
record between 2 groups, we need a default value for this date field.
- In this case, a group represents a "range" of dates. A default value could
be the last date of this range.
- Prior to this commit, the view had only access to a display string for this
date range. We want to have access to the concrete bounds (start/end dates)
- Since some date/datetime fields have backend constraints, it would be
difficult to generate a compliant global default value. As such, the use of
the default value should be disabled by default and activated on a field by
field basis.
2. Usage
- Use the last day (for dates), or second (for datetimes) of the range to set
a default value in kanban "quick create" and "drag & drop"
- Use the end of the range of the last group from a read_group to be able to
request the next group (chronological order) in subsequent read_group calls
3. What are the changes in this commit
- read_group from the "core" "models.py", with the added __range for
date(time) fields, a dictionary for each group. The keys are the field
names and the values are a dictionary with the following keys: value:
- from: starting date(time) of the range (inclusive)
- to: ending date(time) of the range (exclusive)
- XML changes:
- with a new xml attribute on <field> tag allow_group_range_value (for the
kanban view):
- we allow (or disallow) supported non-readonly fields to be:
- draggable
- quick created
- this attribute can be used only on date(time) fields, and if not set,
the default behavior is false
- the naming is subject to contention because it relates to
different features. The relation comes from the constraint:
To perform a drag&drop or a quickCreate, we must be able to get the
value from the group containing the record.
- JS changes:
- we add "group.range" after a read_group for date fields, which is a
dictionary: {field_name: {from, to}}, for each date(time) groupby field
- since date(time) fields can use the format "date_field:granularity" when
used in a groupby, we have to properly split out the granularity to ensure
compatibility with the code previously in place (drag&drop procedures)
- update mock_server and sample_server to make use of the date range.
Adding support for datetime grouping to both mock and sample servers, for
tests and previews.
- the default value for kanban drag&drop and quickCreate features is the
last day/second of the range for date/datetime fields
4. Why can't this range be computed from the original display value with
moment.js
The Babel python library that we use for date(time) formatting (2.6.0) is kept
at the same version as the package in stable Debian Linux. This version has
some issues with displaying weeks consistently around the new year in certain
locales.
We cannot reverse compute a date(time) label with moment.js to get a range since
nothing guarantees that the range will be the same one that Babel used to
output it.
5. read_group return format discussion
Prior to this commit, the format of the value for the groupBy field was
either :
- String : used as a display value for the group.
Most notably, for date and datetime, this value cannot be used as a field
value in most cases. It would be more practical to also return the date
range along with the display value, so that Drag&Drop and QuickCreate
functionalities can be properly enabled in views
example :
"March 2021" has the range ['&', (field, '>=', 2021-03-01),
(field, '<', 2021-04-01)]
This information is lost at the end of the read_group.
- Array : used to indicate a res_id in case of a many2one field
res_id = array[0]
field_diplay_value = array[1]
Since we cannot use the array format to send the date(time)s of the period range
because it could be confused with the many2one format, this commit introduces
the use of a new `__range` key which is a dictionary with specific related
keys to be used to defer usable data to the web client.
Task-ID: 2243913
PR odoo/odoo#69380
When a custom module is in 'to upgrade' state,
and the code has a dependency that is not yet
installed, Odoo refuses to upgrade it, and
says the new dependency is unmet.
This commit fixes this by also calling button_upgrade() in this situation,
and not only for modules in 'installed' state.
This situation arises in a version migration scenario. Custom modules are
in 'to upgrade' state after migration.
If one of these custom modules has a new dependency
after migration, it refuses to upgrade.
closesodoo/odoo#72942
X-original-commit: d5ffe0159ada953985a23c29e36763599bd10ed9
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Before this commit
------------------
Since https://github.com/odoo/odoo/commit/4b28f1162a85d03f9dbe0338b06758ad151ea6a8
It's not possible to override _process_job on ir.cron and
have the new method called by _process_jobs because
_process_jobs calls _proccess_job directly from the class
and do not user the registry anymore
After this commit
-----------------
Use the registry and get ir.cron model to call _process_job
closesodoo/odoo#72897
X-original-commit: b732ebfac934c8fa38a8eb55cfdb59833611c175
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The 'class' attribute was not safely accessed using get. Since this attribute is not always
present the condition evaluation failed in some cases.
task-2276724
closesodoo/odoo#72894
X-original-commit: 58d3b670221b37c5c4c67ee53fbc545f6fb70395
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Emit JS warnings as Python warnings, otherwise it's a pain in the ass
to identify the t-raw messages (they get lost in the INFO spam).
Also just log exceptions when looking for specific messages instead of
re-raising them: if the pipe from chrome is full of exception reports,
the runner may blow its stack as it looks for the screenshot message:
on the first it takes a screenshot, then looks for the screenshot
message, finds an exception, takes a screenshot, looks for a
screenshot message, finds an exception, takes a screenshot, looks for
a s...
Before this commit: when partner is only created with name(i.e. without
address) and when 'address_inline' is passed in context then partner name shows
with unnecessary commas.
After this commit: partner name will not have unncessary commas, as we removes
unncessary '\n' in case of 'address_inline' passed in context.
task-2502597
closesodoo/odoo#72869
X-original-commit: c08082d89782b7675e8e649cba15ca9e03e40077
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Samuel Degueldre