In the filters menus, the order of groups of filters comming
from the search view arch was not always preserved in the filters menu.
This commit fixes that situation.
forward-port of @4094f755
Before, the name given to the copy method was always 'the old name (copy)'
(even bypassing what might have been given to the default values dict).
opw 1862214
This commit allow to create easily a range of periods (related to a field
of date or datetime type) to select in the filters menu.
Two new attributes on elements with tag 'filter' are now usable
in combination in a search view arch:
- date: string.
A valid field name with associated type date or datetime
- default_period: string (optional).
To choose in the following list:
- 'today'
- 'this_week'
- 'this_month' (default)
- 'this_quarter'
- 'this_year'
- 'yesterday'
- 'last_week'
- 'last_month'
- 'last_quarter'
- 'last_year'
- 'last_7_days'
- 'last_30_days'
- 'last_365_days'
Example:
<filter string="Creation Date" name="period_generator" date="create_date" default_period="this_quarter"/>
Note: the attribute 'domain' can not be used for such filters.
The generated domains are dynamic and can be saved as such
via the favorites menu.
task-10532
It is now possible to easily filter data using periods of time
(e.g. Creation Date: This Week). This adds greater flexibility to the search
view and has made some old filters become useless. In this commit, we alter
the search views in order to profit of the new framework possibilities.
This commit allow to create easily a range of periods (related to a field
of date or datetime type) to select in the filters menu.
Two new attributes on elements with tag 'filter' are now usable
in combination in a search view arch:
- date: string.
A valid field name with associated type date or datetime
- default_period: string (optional).
To choose in the following list:
- 'today'
- 'this_week'
- 'this_month' (default)
- 'this_quarter'
- 'this_year'
- 'yesterday'
- 'last_week'
- 'last_month'
- 'last_quarter'
- 'last_year'
- 'last_7_days'
- 'last_30_days'
- 'last_365_days'
Example:
<filter string="Creation Date" name="period_generator" date="create_date" default_period="this_quarter"/>
Note: the attribute 'domain' can not be used for such filters.
The generated domains are dynamic and can be saved as such
via the favorites menu.
In this commit, we implement a function which allow to combine
a list of domains into a single normalized using a 'OR' or an
'AND' operator.
We also refactor slightly py_utils.
In this commit, we implement a function which format a py.js abstract
syntax tree into a string. This is really useful whenever we need to
manipulate python expressions.
The pyeval name is quite confusing, given that there is already an eval
and an evaluate function in py.js, and that the web.pyeval exports two
evaluate functions.
Since this file is more about odoo specific customization to py.js, it
is renamed in py_utils to better express its intended use.
Some functions that were in web.pyeval were actually "odoo independant".
To make them easier to manage/understand, this commit move them in the
library py.js, as an extra file.
In the filters menus, the order of groups of filters comming
from the search view arch was not always preserved in the filters menu.
This commit fixes that situation.
If the parameter ids is given to the process_mail_queue method, it is supposed
to only process the ids it was given, not all mails.
Commit https://github.com/odoo/odoo/commit/4b122ad41d873febe288ab1f8c6cdc078ca2a479
replaced ids by self.ids, and thus default filter was always applied.
fix suggested by @suganthikarunanithi, Sodexis team
opw 1860484
This reverts commit ef444da57a.
Changing a function signature is not supposed to happen in stable;
we have already received 3 opw's about broken customizations or
modules that extend the stock because code such as:
res = self.do_next_transfer()
if not res:
<bla bla>
stops without any warning.
Before, the name given to the copy method was always 'the old name (copy)'
(even bypassing what might have been given to the default values dict).
opw 1862214
In a one2many, if the user clicked the trash button while editing another line,
the row was not unselected.
Thus the modal was not triggered, which entailed that the currently edited line
was always saved.
In particular, it allowed to give empty values to required fields.
opw 1834346
- Create 2 Companies A & B
- Set User B in Company B
- Record some `mail.activity` for User B on a lead belonging to Company
B.
- With a manager user in Company A, go to Kanban view of leads and
remove filters => all leads, including leads in Company B, are
displayed
An access error occurs.
`read_progress_bar` method, tries to access the field `activity_state`
which is: `states = record.activity_ids.mapped('state')`. The state of
a `mail.activity` is using the tz of the partner. To read the
`activity_state` of a lead, one needs to access
`record.activity_ids.user_id.partner_id.tz`
=> multi-company security rules raised
opw: 1850984, 1859470
Suppose there is a one2many field embedded in a one2many,
(say we are viewing record A with one2many field B itself with a one2many C).
Furthermore, there is a second page of the one2many field B.
If an onchange is applied on B, then the server replies with a 1 command for all
B records attached to the currently viewed object A.
This includes a list of commands [[5], [4, C_id]*] for each B record,
in particular B records that are on the second page.
Since they are on the second page, they might not have been fetched by the
frontend; in that case the corresponding C_ids are thus unknown.
As a consequence, on save the frontend sends a command 0 to create the records
for all unknown C_ids.
Since it doesn't have any value to give to the 0 command, the row creation
usually crash in the backend.
Another wrong behaviour is fixed at the same time: if the server sends an update
on the list of C ids with 4 commands.
In that case, if the record has not been prefetched, we have no way to know
if the list changed or not.
To solve this, when we receive the 4 commands by the server, we send back 4
commands.
coauthored by @aab-odoo
opw 1835936
Before this commit, the kanban view ignored the fact that a field widget
could be asynchronous. Worse, some preliminary support was done in
kanban record, but this would crash if an async widget was used.
With this commit, we properly synchronize the kanban
records/columns/renderer. If for some reason a widget needs to be
added to the DOM before it is ready, it can simply returns an empty
value in the willStart/start methods.
Before this commit, there was a traceback in the following scenario:
Let's have a kanban view with groupby and a domain.
If we clear the domain then clear the groupby, there could be a crash.
This crash occurs because when we clear the groupby, it performs a `reload`,
and assumes that the datapoint contains grouped data. However, if this
computation takes some time, it is possible to overwrite the datapoint so that
there is no longer grouped data.
This commit fixes the issue by enforcing at most 1 execution of the method
`reload` active at any time. Consequently, successive reloads operations are
now much slower.
Note that it uses the single non-reentrant mutex on the basic_model to enforce
this rule, which means:
- No more concurrent `reload` and `save`.
- If an execution having the mutex in `reload` come accross the same mutex,
it is blocked forever. This is hopefully not the case at the moment,
however a reentrant mutex should be considered in the future.
The barcodes modules had documentation only available on apps.odoo.com,
following a recent change, odoo modules are not displayed on
apps.odoo.com anymore.
Thus this commit merges the documentation onto the module description so
it is available on the module page.
opw-1846035
closes#25621
Clicking outside the new content options should close the overlay.
Every options are triggering a JS event (mostly opening a modal) that works
fine.
But the 'New Job offer' options is simply a href link which is not going
through anymore since there was a call to `preventDefault`.
opw-1860196
As `pre-` migration scripts may use the registry, we must ensure that
all fields are set up before execution in order to have a consistent
registry.
This is required when loading a registry which contains modules to
install/upgrade without `-u` flag. In this case, the setup was only done
*after* module loading.
To have a better encoding timesheet, we want for the user:
1/ when selecting project first, the task proposed will be
the ones in the project. When changing project, it reset the
task to empty.
2/ when selecting the task first, the project will be the
one from the task
Add grouping possibility on model make for vehicles in the fleet.
Deleted redundent controll on make image for vehicles if model changed.
fixed _name_search for FleetVehicle
project : RD for Dummies
task : [Fleet] Allow to filter/group by Make on vehicles
PURPOSE
=======
1. Unified product demo data
2. Less demo: one per use case
3. Demo data for all models
Specification
=============
1. Refactor all the brol in the demo data
2. Adapt the tests to make them green, as some products are
renamed, removed, created in python instead of as demo data
...
PURPOSE
=======
1. Unified product demo data
2. Less demo: one per use case
3. Demo data for all models
Specification
=============
1. Refactor all the brol in the demo data
2. Adapt the tests to make them green, as some products are
renamed, removed, created in python instead of as demo data
...
PURPOSE
=======
1. Unified product demo data
2. Less demo: one per use case
3. Demo data for all models
Specification
=============
1. Refactor all the brol in the demo data
2. Adapt the tests to make them green, as some products are
renamed, removed, created in python instead of as demo data
...
PURPOSE
=======
1. Unified product demo data
2. Less demo: one per use case
3. Demo data for all models
Specification
=============
1. Refactor all the brol in the demo data
2. Adapt the tests to make them green, as some products are
renamed, removed, created in python instead of as demo data
...
Olivier Dony