When using the abbreviated month in the language
date format (`%b`),
e.g. `%d %b %Y`
in some languages, the parsing of the date
from this format to the database format (YYYY-mm-dd)
failed because of a dot `.` added from time to time
to the end of the abbreviated name
e.g., in French, `5 juil. 2016`
This is a bug of `moment.js` < 2.13.0,
handling badly this dot.
This is solved from `moment.js` 2.13.0,
thanks to the below revision
moment/moment@41fdb58572moment/moment#3078
Unfortunately, we cannot update this library to its latest
release in stable release of Odoo (e.g. 9.0),
as this is seen as an unstable change
(if some API changes occured in the given library)
Instead, if the parsing of the date fails with the
strict mode (meaning the date must respect the format
exactly), we perform a second pass without the strict mode,
so this dot will be ignored,
and the date can be correctly parsed.
The issue can be reproduced by loading the French language,
and setting `%d %b %Y` as date format, and then performing
an advanced search on a date field. The value of the date
in the advanced search will be empty without this revision
(for the months having more than 4 chars,
other than `mars`, `mai`, `juin`, `aout`).
Fixes#11854
opw-682534
set_bundle is called twice (one time by the session, another time
by the web_editor). As the `set_bundle` actually drop the dict of
translations instead of updating it and as web_editor only load
the terms of its module, depending on which call to `set_bundle`
ends first result on having your translations or not.
This commit update the database of translation instead of dropping
it, which fixe the current issue (the dict of traductions empty of
the traduction you really need) but another fix would be to remove
the useless call by web_editor when launched in the backend (which
is probably there because it was needed when the web_editor was only
working in the website).
The `on_attach_callback` and `on_detach_callback` callbacks are
called when an a widget is attached / detached according to the
`is_in_DOM` variable. As the community's action manager cannot
be detached from the DOM, we can hardcode this value to true.
This allow to run these callbacks when needed.
In the below revision:
c0db6aec56
The dialog close `reason` was introduced
to not reload the current form if the dialog
has been closed for a reason
(e.g. a window action was returned by the server).
This is to prevent the record reload, which:
- Is useless, as another action has been launched
and the user therefore redirected elsewhere
- Can fail, in the case the initial action deleted
the current record
(e.g. when merging a lead in an opportunity, the
lead is removed, and therefore this is not possible to reload
it).
opw-680180
* Remove dead code + optimization
* Use Dialog API from web module
* Reorganize files
* Correct buggy $() function for snippet option class
* Add comments
* Fix the snippet parent navigation :
If a page contained a three level snippet structure (i.e A contains
B contains C), when editing the following bug occured :
If B or C was selected first, parenting buttons were correctly set.
But if selecting A then C, clicking on the parent lead to going back
on A instead of going on B.
* Fix snippet thumbnail layout
* Better isolate ui css from themes
* MediaDialog image list : prevent displaying empty attachments
* ...
Since dce2a309 submenus where hidden by using the class `o_hidden` but
this was not taken into account when showing them (so opening submenu
was not possible).
When browsing a form with a one2many / many2many field
with several pages, the one2many pager page was not reset
when going to the previous/next record, while the next/previous
record could not have multiple pages on its one2many/many2many,
and the page on which the user was on the former record could
not exist in the newly displayed record.
Besides, even if the page does exist, there is no reason
to display this new record X2many value from its first page.
It's the case anyway when you edit/save, it comes back to the first page.
opw-679092
Before this commit, the list view, grouped by a selection field, displayed the
'technical' value of the field as group label. It was basically forced
to do that, because the result of the read_group only contains the
technical value.
This commit changes the list view in a way that it now requires a full field
get, so it can use it to find the correct string.
_('foo '+bar) does not work as `bar` is a variable with undefinied content
during translation export (and variable content during evaluation) so a match
will not be found.
Also trailing spaces are stripped during synchronisation with transifex.
The proper syntax would be
_.str.sprintf(_t("foo %s"), bar)
but to avoid breaking existing translations (need to reexport .pot)
use the syntax
_("foo ") + " " + bar
that is more stable friendly.
The 'No value found for the field...' string is not possible to be fixed without
breaking the translations should be split at least twice.
Write it the propre way directly.
commit 69d4aa363b replaces show()/hide() by classname o_hidden
but the folded submenus were still hidden using .hide()
thus they always remained invisible.
This commit fixes the action target="fullscreen" in community, where
the submenu on the left would sometimes remain visible.
The fullscreen feature was added in commit : d65d251c57
This reverts commit f38f8930f0.
Revert for internal choice. Odoo want to use qweb in template and remove jinja support on next version.
If users want to use jinja they can change the view to use text widget instead of html widget.
In a previous refactor, qweb configuration was simplified. However, I
missed the fact that session.js sneakily configure the qweb instance
after the fact. As a result, the kanban view did not have the _s key in
its custom qweb instance default dict. This commit allow the qweb class
constructor to add default keys to the instance.
Now, kanban view can add _s, and everything is good.
For `this.viewmanager.active_view` to be set, the view manager
switch mode must be completed, meaning the deferred returned by
the function `switch_mode` must be resolved
(see `this.active_view = view;` in `view_manager.js`, line 146)
In a 2many field, the view manager `switch_mode` deferred is resolved
when `is_loaded` of this field is as well resolved.
Before this revision, clicking fast on Save then Edit
of a vendor bills resulted to a JS error due to a race condition,
because `this.viewmanager.active_view` was undefined when
the field was not loaded / the view manager switch mode not completed.
opw-678097
The preview change the content because the browser try to fix the dom.
If a user use jinja and activate the preview, the jinja code is (re)moved by the browser and broke the template.
If the method return false, when a user write require="1" on a x2many field, the content is valid that there have none or a value.
The method was overwrited for a visual change (display the field x2m in readonly mode when they are not value) but is_false is priority use to ensure datas.
Rev e37ba61 forward-ported 8.0 revision f02b230 from PR #12379.
This patch introduces extra tests and views for o2m onchange behavior,
including new fields in the test models.
In 9.0 a new convert_to_onchange() mechanism had been
introduced at 9f81c6d
The combination of both requires some adaptation to the
expected results of the new tests and adaptation of existing tests.
The test models in `test_new_api` have an implicit depencies between
models which cannot be express on ORM:
messages depends on participants of their discussion.
So, when editing a discussion, the field `participants` should be
processed before field `messages`. This is not always done because
field processing order depends of the iteration order of a `dict` (which
is undefined in python).
The testing tour `widget_x2many` worked by chance until now.
Adapt the tour to save the participants before the messages.
Context in new API is not more a parameter.
Before this fix, context was interpreted has attribute parameter
and so the fields_get return empty dict.
This commit fix tracback when we try to export data in list view from
any model. The wizard try to know the fields from current model and a
traceback is raised (key error for field['string'])
Christophe Simonis