The format methods of the date/datetime type expect a momentjs date
so it can call its 'format' method. Since we were not giving it a
momentjs date, the call to 'format' was crashing.
This commit proposes to improve the way people follow project with two
additions
* project manager is now automatically follower of his project
* customer is now automatically follower of customer projects. Those
projects are meant to be used with external people and access rights
are based on followers. Adding the customer in followers allow him
to see and participate in the project tasks and/or issues.
This commit improves the various way of searching tasks and issues in
website pages for tasks and issues. As for other website apps it is now
possible for the customer to search in name, description, stage or
discussion thread.
It is currently not clear what adresses and tabs in employee form view
are about, especially concerning public, work and private data. This task
improves the labeling of the home address (private one) and public and
personal tabs (work and private actually).
Different method use self._context.get('lang', 'en_US') to get the lang
value but, the lang in the context can be set to None (eg: copy method).
When the context is used with a lang=None, the method can have a
unexpected behavior or crashed (eg: if you try to format a datetime with a
locale=None)lang can be None
- When an one2many is displayed in a list view, the field data are not fully loaded
since only the number of record is displayed. Then when the related form view
is opened the one2many fields displayed need to be loaded.
- Optimized the fetch of x2manys without doing an useless rpc
if we don't need all the fields but only the relation records ids and adapt
the tests for this optimisation.
- Fix wrong inheritance for kanbanmany2many_tags
Before this rev., the context sent when creating (or saving) a
record was incomplete. Thus, the created record might be incorrect.
For example, go to Sales, open a team's pipeline, click on 'Create'.
The created record should belong to the selected team, thanks to
some keys specified in the context. This wasn't the case before
this rev.
The '_render' function of field widgets can be called several
times in the widget's life cycle (each time its value changes).
The JournalDashboardGraph appends a new 'svg' to its the $el at
each rendering, so it must empty its $el at the beginning of each
rendering.
Before this fix, several graphs were displayed in the same kanban
card in the Sales dashboard when, e.g., the user changed the color
of the card.
The 'defs' attribute of the BasicRenderer is used to push the
rendering deferred of asynchronous fields. It is set to an empty
array before the rendering, and for each asynchronous field, its
deferred is pushed in the array, so that the renderer can wait for
all its fields to be rendered (no flickering).
The function '_applyModifiers' is called during the whole view
rendering (for each field in the view), and when some fields
change, as the modifiers are then re-evaluated.
As it is called during the whole view rendering, it can't delete
the 'defs' attribute, otherwise it will crash if one of the
remaining fields in the view uses an asynchronous widget (trying
to push a deferred in an undefined variable).
This rev. moves the deletion of 'defs' to the function that is
called when all modifiers are re-evaluated and applied.
... to clean up once the test is finished, because it doesn't
work.
The previous solution to clean up only deleted ace and require
from window, but doing this didn't force a reload of the libs for
a potential second test using ace (because the scripts were still
in the page). Trying to remove the scripts from the page doesn't
work either because the loadJS function uses an internal cache
to prevent from loading twice the same lib.
So if we want to have more than one test on ace, we can't clean up
the libs.
The evalContext contains the current data of a record
(the value of the fields that have been fetched,
i.e. the ones referenced in the view).
However, 'id' is a particular field that should always
be in the evalContext, even if not in the view
(as we always know its value).
Before this rev., 'id' was in the evalContext if
the record already existed, but not on new records, so it crashed
on new records if 'id' was used in the context defined on a field's node.
Since 54245deebd, when you clicked twice
on the button "Confirm" on a slow connection, you could get an error as
values is not always defined.
This commit fixes the bad indentation level :)
Before this commit, all onchanges were applied if the field
was known on the model.
However it's not possible to apply onchanges on x2many not in
the view as we don't know their fieldsInfo.
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
If the event has some tracks a button is displayed to launch a mass
mailing on those speakers. This button requires a new bridge module
between mass mailing and website_event_track.
If the event has some attendees a button is displayed to launch a mass
mailing on those attendees. This button requires a new bridge module
between mass mailing and event.
David Monjoie