The 'Add New Column' was still in `folded` mode after clicking on 'Discard'
because the mode was toggle two times: one by `_cancel` and another one by
`_onClick` which already toggles the mode.
This commit also use `_applyChanges` directly instead
of using `notifyChanges` to avoid the mutex which will
cause a deadlock (we are already in the mutex).
It is frequently needed whenever we want to make something responsive
Also, we refactor the code to the new coding guidelines (this part was
done by ged)
Since the new views, buttons were extracted of the <footer/> tags and
placed directly in the buttons area. While this would be a good idea,
this was ignoring the modifiers placed on the <footer/> tags. Multiple
solutions were possible:
1) Leave the <footer/> tag as it is (like before the new views)
This creates an useless <footer/> element in the DOM most of the
time.
2) Propagate the <footer/> modifiers to its children.
This requires some code to do the propagation and a modifier might
be evaluated multiple times for nothing (for each child).
3) Allow only one <footer/> tag in form views and divide buttons in
child <div/> elements.
Only creates the necessary DOM elements and modifiers are evaluated
only once.
While the third choice is obviously the better one, this commit is
implementing the first solution. Indeed, changing all the XML views
might not be a good idea in the current state.
before this commit when toggling allday flag in calendar form view, it was
possible to have one day error.
The input datetime is wrong when the user don't use the datepicker widget
(insert date by keypress instead of click on datepicker)
sometimes, the value could be null (crash because try to clone false)
* account, mail, sale
Since the views refactoring, modifiers were not properly handled
anymore (readonly/required not recomputed, use of readonly/required
of "python field" instead of "view field", ...). This commit tries to
implement a system which allows to handle the modifiers (re)computation
the same way for all the basic views.
For this to work, many specialized renderers behaviors have been moved
to the basic renderer so that more mechanisms are shared (especially by
the form renderer and the list editable renderer). The list editable
renderer is hugely impacted by this commit.
Here is a list of key changes:
- The basic renderer now has a `_renderFieldWidget` function which is
used without modification by the form and the list renderers.
- Modifiers have to be registered thanks to the basic renderer
`_registerModifiersData` function (this is done automatically for
fields by the `_renderFieldWidget` function for example).
- All instantiated widgets are accessible, organized by record, and
ordered in a special basic renderer variable.
- The code which resets the widgets of the form view and the code
which updates the row of a list editable view is now shared in the
basic renderer and now also automatically updates the DOM according
to the reevaluated modifiers.
- The last point has an huge impact on list editable renderer: all the
widgets have to be instantiated when editing a row (even readonly and
invisible ones) as they can be switched to editable/visible during
edition (after a modifiers update).
- `replace_element` and `readonly` options of `AbstractField` are
useless: widgets are now always replacing the list editable cells
in edition and the `readonly` widget mechanism is replaced by the
notion of 'focusable' widgets.
(see `AbstractField.getFocusableElement`)
- The 'tab' navigation mechanism is impacted by the previous point,
some code sharing have been done in basic renderer for this too.
- `AbstractField` does not care anymore of the 'required' status, this
is the view responsability to check that a required field has a set
value on save.
- Some list editable bug fixing (e.g. it was possible to edit multiple
rows at the same time, it was not possible to navigate towards the
previous field, crash on o2m add an item click, ...)
- The mockserver now properly simulates server modifiers computation.
- ...
Note: list editable style may be worse than before this commit but a
CSS update is coming in a few days.
Extract setting the employee's parent when changing the department manager.
This allows customizing the way the managers are handled easily in extension
modules.
Closes#16490
- Create 2 companies (A & B)
- Create a product shared between companies
- Add a reordering rule in each company
- Add a supplier for each company
- Run the scheduler (from the cron)
The supplier selected is always the supplier with the smallest sequence,
since it is run in sudo mode.
opw-728346
Before this fix, active_id wasn't defined on non existing record.
For example: when you tried to add a new contact on a new partner.
Now, active_id is false if there is no id on the current record.
So, you can use this value to evaluate the context
When you try to empty a date or datetime field, you get a traceback
saying that 'clone' and 'isSame' are not functions.
This error occurs when you empty the field because the value is 'false'
and you cannot call 'clone' or 'isSame' on false.
To fix this, we ensure that value is not false before calling these
methods on it.
This bug has been introduced in rev: https://github.com/odoo/odoo/commit/c32724eae06c987e74a0600f1669696e499edc33
- Create a SO with a product that is a service and will be invoiced
based in delivery quantities and will be tracked on timesheets and
contract.
- Confirm
- Use a simple user that only has for rights: "Employee"
- Create a timesheet as the employee for the contract created by the sale
- Log some time
- Save it
- Check the SO: ok the number of hours should be "to be invoiced"
- Edit the timesheet and set one day to 0 hours => Access Error
In case of a zero value, the timesheet widget sends an unlink command
for the corresponding entry. In this case, the `sudo` is not set at the
appropropriate moment since the context key `force_so_lines` will resue
lines which are not defined in the `sudo` environment.
opw-728453
Before this all domains in the POS were ignored. Introduced by
e574027056.
When the specified method is search_read buildQuery rewrites args
using the domain and fields properties. This ensures that in that case
they are set.
The 'mode' attribute can be used for x2many fields to force the
view mode. Before this rev., it was ignored and if a tree view
existed in the view description, it was selected by default.
This was mainly a problem in mobile as in this case, kanban views
are prefered, and the data_manager forces the mode to be kanban,
so the data was fetched according to the kanban view fields, but
later on the list view was instantiated instead of kanban by the
x2many field, so it crashed if both views didn't share the exact
same fields.
Onchange results weren't correctly applied for many2manys, and
for x2manys inside x2manys.
More precisely, if an onchange RPC returned a command 4 (link to)
for a many2many field, this command was ignored. If it returned
nested commands (commands 0, 1 or 4 inside commands 0 or 1), they
were ignored as well.
The function that applies the result of an onchange is now
recursive, and it handles commands 0, 1, 4 and 5.
The fieldsInfo attribute on the basic model's datapoints is used
by to determine which fields need to be loaded for a record/list
of records. This information wasn't correctly specified in some
cases. As a result, the display_name of many2many fields (e.g.
using widget many2many_tags) inside list views were fetched, and
thus empty tags were displayed.
No test is added by this commit, as it already makes a broken test
pass (this test didn't pass since the previous commit).
There were several issues with this widget, and the way the model
handles its requests (mainly the removal of values).
It crashed for instance on the product form view when the user
updated the routes field (field route_ids in tab inventory).
The readonly attribute of a field in its description can be
overriden in the views (e.g. with modifiers). So readonly fields
may actually be edited from views in which there is a modifiers
on their node overriding the default value.
Before this rev., readonly fields couldn't be saved, even if they
could be edited from views (with such modifiers).
For instance, it wasn't possible to change the value of the
partner_id field in a draft sale_order.
'session' is no longer an widget attribute, 'getSession()' should
be used instead.
Also remove a dead JS field widget (not used since
odoo/odoo@158f779b46)
Before this commit, it was not easily possible to add the seamless closing
workflow while having 2 or more depreciation boards (eg. according to accounting
standard). With this commit, I can construct the move lines independently
inherit properly and pass all created move lines to the window action.
Closes#16073
For one2many and many2many fields, you have several ways for specifying
a view other than the default one:
- to write the arch of the view in the field tag
Example:
<field name="many2many">
<tree>
...
</tree>
</field>
- to write xmlid of the view in a specific key (*_view_ref)
in the context of the field.
Example:
<field name="many2many" context="{'tree_view_ref':'module.tree_view_ref'}">
Before this fix, the second case didn't work.
the default view was loaded instead of the one passed in the context.
In fact, this context is evaluated after the loading of the record but
we need some static keys to load the view (before fetching the record).
Each REPL python shell behave differently depending on the exit method.
Force a rollback at the end to avoid inconsitent behavior.
Thanks to Harry Jollenbeck for the report: https://www.odoo.com/groups/59/26318707
When we try to archive a kanban column we get a traceback when the field
'active' exists on the model but not in the view.
This traceback is caused by an unecessary check of the active value of
the record.
To fix it, we apply the 'active' value on all records, and not only on
the ones where active value changed.
The field partner_id on stock.picking is not a required field so it
would possibly cause error when getting the name of the report since
partner_id was used in it since efdb5373c3.
opw-728549
Traceback when:
* click on first row of calendar
* move an event somewhere else with drag and drop
* click on the mini calendar
* filter from the control panel triggers a traceback
* add an attendee: traceback
* day/week/month: traceback
* cannot add a leave, the fromViewDialog does not open
* one day oo server-side when select all day
The client must receive the tzOffset to apply this on all hours.
To use the date picker we must change the date to apply the change
in the user's tzOffset, without this change the result is wrong.
For datetime widget we must change like it to avoid max stack error.
The server send the tzOffset, if it's undefined, by default the client
use the browser time offset.
Every test are change to use tzOffset.
A test is added in calendar to use the click by position for the
fullcalendar lib. This test create and drag and drop an event to check
timezone error and error when we use default value in the context.
Use formating date like 2026-04-04T08:00:00Z instead of 2026-04-04 08:00:00
is important for phantomjs, because it's crash without information if the
formating is not the standard format.
For the parsing, when the client receive a server date the date is utc
formating but when it's parsed from the client is in the user's timezone
Martin Geubelle