| Age | Commit message (Collapse) | Author |
|---|
|
Have a list with multi_edit enabled
Have a widget boolean_toggle displayed on some field
Select some records to be in multi edit mode
Before this commit, the record on which the boolean toggle button was clicked was written
and then the multi edit feature was triggered and wrote on all the records
The first write is unnecessary and counter intuitive
After this commit, only the write with all the multi edited records is done
|
|
This issue only occurred in community.
Steps to produce:
1) Create/Edit any record.
2) Change the menu using menu switcher
3) You will get the discard dialog at the instance and after some
time it will also display another duplicate discard dialog.
So, we have one extra redundant discard dialog on menu switching.
It is working fine when we have dirty form and then click on the
breadcrumb or click on any internal child menu.
Task : 2312437
closes odoo/odoo#57343
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
This commit introduces a new semantics to define action and method buttons
in the list view.
The aim of this feature is to be able to do some actions on selected records, or on the entire
records' domain with the help of buttons located in the controlPanel, much like the form view header buttons.
To define such buttons, one must add a `header` node in the list view's xml definition
```
<tree>
<header>
<button type="action|object" name="actionId|methodName" string="button's text" context="{}"/>
</header>
<field name="fieldName" />
</tree>
```
task-2246383
|
|
Previous commit introduces the sample data feature in list and
kanban views. When sample data is displayed, most parts of the
renderers can't be clicked on, to prevent the user from interacting
with sample records (e.g. to open a sample record in form view from
the list). This commit disables keyboard navigation as well, as
those sample records could still be accessed with the keyboard.
To do so, several refactorings have been done in views:
- _giveFocus function added on controllers (so that we can hook
on the moment where we want to focus the renderer, and prevent
it in sample mode), it kind of replaces giveFocus of ActionMixin
which wasn't use from the outside
- updateRendererState -> _updateRendererState as it is private
- _setState function added on controllers, to have a hook when we
set a new state (already existed, but only in kanban)
- _renderView function moved from Basic to AbstractRenderer, so
that we have a proper hook to deactivate clickable elements in
sample mode
Task 2232801
X-original-commit: 4482a03fe2f083f4f44fc6eb76d90ae22afbff91
|
|
With this commit, it is now possible to display sample (fake)
data in empty views, in the hope of easing user onboarding.
This can be enabled (in list and kanban views) with attribute
sample="1" on the arch root element. In this case, if there is
no data to display, sample data will be generated based on
heuristics (depending on field types and names). This can be
used in addition to the no content helper.
Task 2232801
X-original-commit: 7c8e627ff5029cb539d702705e5ce53d658c76ed
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Jérémy Hennecart <jeh@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
|
|
closes odoo/odoo#52826
Related: odoo/enterprise#11084
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
When a resequencing is done inside an object hierarchy of two
controllers, since 9b90d8727d we would call resquencing code one time
per controller.
So if for example we are in a list view inside a form view (eg. a
"Search More" modal in a form view) the resequencing would work for the
list view, but then cause traceback when it is handled by form view.
With this changeset, the first controller that get the event
`resequence_records` even gobbles it up.
Without change, added test fails because of original traceback:
Cannot read property 'res_id' of undefined@ 202 ms
Source:
TypeError: Cannot read property 'res_id' of undefined
at /web/static/src/js/views/basic/basic_controller.js:744:67
...
opw-2256818
closes #51827
closes odoo/odoo#52018
X-original-commit: eef4b99fdb9469c040af80d055933eda367b7b3d
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
... when there is no data and user clicks anywhere in the no content
helper.
Task 2239617
Co-authored-by: Jinal Patel <jip@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
Following the new selection feature in list views, this commit
adapts the delete action.
Part of task 2185145
|
|
Following the new selection feature in list views, this commit
adapts the archive and unarchive actions.
Part of task 2185145
|
|
|
|
Some web actions/controllers/viewsl have been adapted to properly instantiate the
newly refactored control panel and update it accordingly. We needed to adapt the
starting mechanism of actions and controllers to ensure that the control panel
instantiation did not delay the loading of any widget.
Part of task 2196029
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
|
|
Issue
- Take a v13 runbot
- Open survey's app
- Open one of the surveys
- Click on edit
- Click on a question
- Open 'option tab'
- Make sur the field 'mandatory answer' is true
- Try to translate field 'error message'
-> Error
Cause
this occur because because we try to update the model survey.question
from the list coming from survey.survey which mean that the
record.viewType is list and not form.
Solution
As we are looking for the field name we can simply use
ev.data.fieldName.
Another solution should be to use this.viewType instead of the record
one.
OPW-2157631
closes odoo/odoo#42952
X-original-commit: ad115d2710aec2b4ff7d4077714a1816cdfb433e
Signed-off-by: Jason Van Malder <jvm-odoo@users.noreply.github.com>
|
|
Install accounting and activate a new language. Under
Accounting>Settings>Terms and Conditions input something, save and then
click on the near lanuage button.
A popup will appear with only the possibility to close and save but with
no text.
This is because no row is fetched from the ir.translation table, because
the domain for the search is
```
['&',
['res_id', '=', None],
['name', '=like', 'res.config.settings,%'],
['name', '=', 'undefined']
]
```
* wrong res.id "None" instead of the correct one (1)
* wrong name pointing to somewhat related to 'res.config.settings'
(the field name is "res.company,invoice_terms")
* another wrong condition on name equal "undefined"
The domain is malformed because in
addons/web/static/src/js/views/basic/basic_controller.js
record.res_id is unset while record.res_ids is it. Rewriting res_id to
make sure the id is there fix the issue
Thanks to mart-e
opw-2091779
closes odoo/odoo#40394
X-original-commit: 20e84558de476c17fed73f7ea5a11989401bffaf
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
|
|
Changes the behaviour of many2ones when their value is changed via a form dialog.
Before this commit, when editing a m2o with a form dialog opened by an external button,
the field triggered an onchange with its old value before reloading its widget.
This caused the edition in list views to display outdated information when
saving multiple records.
Now, the reload is executed first, then the onchange occurs so that the value is
the newly updated one.
Part of task 2078807
closes odoo/odoo#37576
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
|
|
|
|
Before this commit, editing a record e.g. in a form
view and toggling the home menu would cause the discard
warning to be displayed twice when going to the home
menu (in enterprise) and then once again when going to
an other app. This is now fixed.
Task ID: 2043027
closes odoo/odoo#37301
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Co-authored-by: aab-odoo <aab@odoo.com>
|
|
This commit fixes:
- body of a email.template in a small field
- translation of website_description of a product does not show the
source of the translation
- translation of website_description of a product shows the full
content for the current language
HTML fields are typically fields with longer of content.
If the field is an HTML field, it should be displayed in a textarea,
like the text fields.
Most of HTML fields are split in meaningful chunks of content (using
xml_translate or html_translate method).
For these fields, the source must be displayed.
Also sort the entries on the source to have a consistent order
closes odoo/odoo#37215
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
Before this commit, translations were edited in a list view with a filter
on the field that needed to be translated.
After this commit, the translations for each fields are translated in a
dedicated dialog. The changes done to the current language are taken
into account immediately, both ways, from the dialog to the form and
from the form to the dialog.
Translating terms is also available in create mode, the user will be
prompted to save before editing a translation
Task ID: 2028152
closes odoo/odoo#36185
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
|
|
|
|
Since the renderer does not know the view id, we moved the local
storage key computation up to the basic controller, which makes
more sense since the renderer is supposed to be inert.
The _processColumns function had to be moved in willStart however,
since it now needs the controller to respond to the trigger_up
and the controller is not present during the init of the renderer.
closes odoo/odoo#34051
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
|
|
closes odoo/odoo#35404
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
closes odoo/odoo#35059
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
Let's assume a form view with a readonly many2one field with a
default value. When creating a new record, the user can click on
the many2one value, which should open the related record in a form
view (stacked in the breadcrumbs).
Before this rev., this didn't work: we actually came back to the
previous view/action in the breadcrumbs, when trying to open the
related record.
closes odoo/odoo#33172
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
|
|
The onboarding modal for setting up the few base fields of a company
has now been moved to a wizard
It is accessible from the general settings, but also in the onboarding
section of sale and account modules.
The following company settings are editable with that wizard:
- Set report **layout**:
The user can chose the overall look of the report. The current choices
are : *Standard* (default), *Background*, *Boxed* and *Clean*.
- Set company **logo**:
Changes the company logo.
- Set report **colors**:
The user can set the primary and secondary colors of the report through
a newly added widget allowing to pick a custom color.
When changing the **logo**, colors are automatically set to its most dominant
colors.
> A "Reset colors" button also triggers the color calculation.
- Set report **font**:
Changes the overall font of the report. Only Google Fonts are used
for enhanced compatibility.
- Company **tagline**, also called "header"
- **Footer**
- **Paper format**
- Report **preview**:
A mockup of a final report
Automatically updates when changing **layout**, **logo**, **colors** or **font**
Co-authored by: Julien Mougenot <jum@odoo.com>
closes odoo/odoo#33863
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
|
|
With this rev., when there are a lot of groups in a grouped list
view, groups are displayed under several pages, whereas they were
all displayed in the same page before.
This is especially interesting with the new 'expand' attribute, to
ensure that we don't read records for a large number of groups.
By default, the groups limit is set to 80 (like records), and to 10
is the 'expand' attribute is set to true. This limit can be
overriden with the 'groups_limit' attribute.
Part of task 1915702
|
|
|
|
Part of task 1896658
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
|
|
|
|
When editing a record, if it cannot be saved (b.e. due to required
fields) and the user clicks on save, then on discard
Before this fix, the window did nothing (seems like it is unresponsive)
After this fix, the user is able to discard the form.
task-id: 1937142
closes odoo/odoo#30871
|
|
Before this rev., there was a race condition when the user did
some changes on a form view (triggering an onchange), saved and
clicked on the breadcrumbs to leave the form view (before the
onchange returned). As a consequence, the dialog telling the user
that there are pending changes was displayed. This mostly occured
on the main_flow_tour since the removal of an unnecessary check,
and could be reproduced manually on a slow network.
Basically, the check if there were pending changes was done too
early (before the view was actually saved).
|
|
|
|
This branch introduces a large-scale reorganization of the
component tree generated by the web client. The short version is
that now, the control panel is a child of the view controller and
no longer a sibling. Graphically (and simplified), we go from
this:
webClient
/ | \
... ... actionManager
/ \
controlPanel viewController
/ \
to this:
webClient
/ | \
... ... actionManager
|
viewController
/ | \
ControlPanelController
/ \
CPRenderer CPModel
The motivation is that this work moves the code where it should be.
Before this commit, it was kind of weird to have code in the
controllers to render buttons outside of their root node (in
renderButtons). Also, the action manager had to take care of
coordinating search view states between view transitions.
So, this work simplifies the code. It also makes it easier to
extend. We see day after day that Odoo needs to take care of more
complex UI needs, and in many cases, these needs were quite
difficult to implement (we prefer spaghettis in our plates, not in
our code). The changes in this branch should open the way to
implement these features.
For example,
- it will now be easy to add the possibility of views (for example,
the search view or a new ControlPanel view) to add custom buttons
(of type action or object) in the control panel.
- Another need will be to serialize/ restore the state of the
search view across action boundaries (needed by the dashboard).
- Another example is the possibility for views to customize easily
the presence/absence of sub menus (filters/groupbys/favorites/
time range/...)
- Another need is an easier way for views/client action to customize
their control panel.
This commit also contains a large rewrite of the search view (so it
is more inline with our architecture and easier to maintain).
Part of task 1893568
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
|
|
|
|
|
|
Before this rev., the following scenario didn't work:
Open manufacturing order and click on Produce button (note that
bom product should have Serial number enabled) then add quantity
in Done field in o2m and press Record Production button in wizard,
it will produce UserError and after then if you change Lot number
field in wizard's o2m then the many2one value doesn't get selected.
This occured because the renderer wasn't updated after the RPC fail
and thus still got an outdated version of the state.
The issue raised after commit: 02eef78bbd3 which was done to remove
useless rpc call, it's OK to remove rpc call but let's keep
updating renderer.
Related to task ID: #1852715
Co-authored-by: Tejas Shahu <tsh@odoo.com>
|
|
With this rev., the resequencing feature (with drag and drop) that
was already available in list views is now available also in kanban
views having a field with widget="handle". This works for main as
well as x2many kanban views.
Some code handling the resequencing has been moved from the list
components (controller and renderer) to the basic ones, so that the
logic is shared between list and kanban.
Task 1902808
closes odoo/odoo#28581
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
(mainly views and ActionManager)
- add missing docstrings
- fix typos
- correctly order functions and imports
- put functions in correct sections
- stop using 'event' as argument of handlers
- don't call handlers directly
- remove trailing spaces/tabs
- move module created in stable version to its own file
- follow js guidelines in general
closes odoo/odoo#28024
|
|
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.
|
|
This rev. removes a deadlock situation that could *theoretically*
occur, but that was actually hard to reach in practice.
Before saving a record (e.g. in a form view), all field widgets
are asked to commit their value (in case they wouldn't have
notified the model yet, e.g. because the user just changed them).
For instance, let's assume that the user fills an input field, and
then triggers the save. In practice, by triggering the save, it
will force the widget to notify the model of its new value (because
it looses the focus). This is also the case using keyboard
navigation, as it actually simulates clicks. So when the widget is
asked to commit its value right after, it has nothing more to
commit.
This is fortunate, because if it actually had something to commit,
we would end up in a deadlock ('commitChanges' is executed in a
mutex, and if the widget triggers a new value, '_applyChange' is
called, and is executed in that mutex as well). In fact, executing
'commitChanges' in a mutex is useless, as '_applyChange', which is
called when a widget has something to commit, is already executed
in the mutex.
So this rev. removes the use of the mutex in 'commitChanges'.
Doing so broke several Many2One tests, because they wrongly relied
on the presence of the mutex for scenarios where the user quick
creates a relational record, and then directly saves (before the
relational record is actually created). We thus handled that
usecase properly to make the tests pass.
Task 1878254.
|
|
Attribute may be undefined.
|
|
|
|
1. Added the ability to navigate within the List view using UP and
DOWN keys.
2. By defaults, the focus should be set on the search input field.
3. From the search input field, using the DOWN key, the focus goes
to the list
4. From the search input field, using TAB key, the focus goes to the
create button
5. From the create/import buttons, using TAB or DOWN key goes to the
first row of the list, then UP and DOWN keys moves the focus from
item to item in the list.
6. When on a row, hitting ENTER opens the view of that row.
Also in this commit
1. When on the first row, hitting the UP key does nothing
2. When on the last row, hitting the DOWN key does nothing
Not included in this commit
1. Memorize the position on the list when opening an row, than
restoring when going back to that list
2. Navigation on grouped list using the keyboard
|
|
|
|
Before this commit, when some records were created from an `onchange`,
we have the following weird behaviour:
Suppose that this record has some required fields that are empty.
When we click on this record, then somewhere else, the record
disappears from the list.
This is because the records contains invalid fields, and it is wrongfully
assuming that the record to be discarded comes from "Add an item".
A previous commit [1] fixed a bit this issue with `default_get`, but since
it relied on a fragile heuristic, we decide to apply the correct fix with
this commit.
[1] https://github.com/odoo/odoo/commit/b09f0c99be2b13d33986414485556d87da186d65
|
|
Before this commit, some breaking spaces were present in the js code.
Such spaces are misinterpreted and worked by luck.
This has become a problem with exported js bunldes (e.g. the
external_lib bundle in im_livechat).
This commit replaces breaking spaces by regular spaces.
|
|
In multi pages list view, the scroll position is reset to top when
the user switches between pages. This wasn't working if he first
reset the limit, and then switched between pages.
|
|
This rev. improves the way the scroll position is restored when
coming back to a view (e.g. open a kanban view, scroll, click on a
record to open it in a form view, go back to kanban using the
breadcrumbs):
- generalize the scroll position handling from web_enterprise to
web to make it available in the community webclient as well
- also restore left scroll position, not only top (especially
useful for grouped Kanban views with a lot of columns)
- handle the case where the scrolling area is a sub element of
the view (e.g. the grouped Kanban view in mobile).
Task 34037
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Co-authored-by: Ankit Sathvara <asa@odoo.com>
|
|
|
