Since the changing of assets (8cc066173d)
the /web/session/modules route returned a stringified set instead of a list
After this commit, the route returns a list
closesodoo/odoo#70545
X-original-commit: 54e4a48996826dd8ea16a84517b46a847d6daf3f
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Some features of the PDF.js library doesn't work in the
webview of the mobile apps.
Initially 'window.print' is defined as an empty function in
webviews unlike browsers where it is already ready.
After that, PDF.js needs to monkey patch 'window.print' and
saves a reference to the original definition, which is not
yet fulfilled in by the mobile app (Java part).
So the print of PDF.js doesn't work in webviews and end
users will need to download the file before printing it.
Regarding the Download button, the 'download' attribute is
not supported by the webview as you can see in:
https://bugs.chromium.org/p/chromium/issues/detail?id=432414
As there's many ways to download a file in Odoo it's not
a big deal to simply hide it in PDF.js.
Because it's quite complicated to fix this, we decided
to hide the features that don't work (Download / Print)
or don't make sense (Open file).
Task-id: 2200168
* IMPACTED VERSIONS
12.0+
* HOW TO REPRODUCE
locale : Locale is en_US (or other SUNDAY based)
view: CRM - My Pipeline - Kanban view
groupBy: date_deadline:week (Expected closing)
records: one record with a planned activity, on date_deadline = 2021-05-02 (SUNDAY)
one record with no planned activity, on date_deadline = 2021-05-09 (SUNDAY)
remark: don't keep any other record in MAY for better visibility
* PROBLEM
The progressbar of the week containing 2021-05-09 displays information about the record
from the week containing 2021-05-02
* CAUSE
1. PostgreSQL `date_trunc` function follows ISO8601 which essentially means that
the start of a WEEK is always MONDAY. There is no argument to change this.
2. _read_group_format_result
https://github.com/odoo/odoo/blob/27da86a138089c1838e4b94f8a6976995b9c1fff/odoo/models.py#L2210-L2219
- Computes a label for a group of records.
- Follows the locale for the label of the week, based on a date which is
always a MONDAY because of `date_trunc`.
3. read_progress_bar
https://github.com/odoo/odoo/blob/88957afca09662af7eaa19df1e40b3699e45e79e/addons/web/models/models.py#L167-L175
- Associates a group label to a record.
- Follows the locale for the label of the week, based on the date of a record
which can be any day of the week. If the record is related to a SUNDAY and
SUNDAY is the first day of the week, it would have been in a group with a
different label in (2.) than in (3.) prior to this change.
* FIX
In 3., before associating a label to a record, we truncate the date to the
ISO start of the period, so that the label is determined for a record in the
same conditions than in 2. The locale is still used to get language-dependent
outputs with babel, but the grouping will always follows ISO8601 (date_trunc).
* TEST
Added a test for this problem case
TASK-ID : 2517848
closesodoo/odoo#70498
X-original-commit: 4560925b26fa79740b9618fd9241d3517b64f43f
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
`_(xyz)` will wrap them in an underscore.js object, which when used in
a string context will just return the string. So it's basically a
no-op, but it certainly doesn't translate the terms.
closesodoo/odoo#70476
X-original-commit: 92352ed2b5524c97b0aeeba3193c6a8d93ed82a1
Related: odoo/enterprise#18172
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Some aria attributes were missing or incorrectly set on these new
buttons:
- The button "Export All" was missing an `aria-label` attribute
- The button to show/hide optional columns was also missing an
`aria-label` attribute, and its menu items (checkboxes to show/hide
columns) were missing a proper role
- Ever since the debug manager was added in frontend on 73327db065,
the `aria-label` attribute was not being rendered correctly on the
button to open developer tools
closesodoo/odoo#70433
X-original-commit: ac3e0fcd32d66d6e0bacfabd2d224805d92dbfd1
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This commit will add the needed ESLint configurations on the JS files.
These configurations are added if the JS file uses a different
environment (serviceworker, node, etc) or if it uses a specific global
(google, ace, etc).
Co-authored-by: Samuel Degueldre <sad@odoo.com>
In eg. 13.0 when refreshing sales analysis action of a product, we would
get an error because we have a single active_ids which is not expected
by the code.
With this commit, we use .toString() on the jQuery BBQ parsed active_ids
as it was done before 32b8cec5 refactoring (january 2018).
The added test with the fix fails with an error:
TypeError: state.active_ids.split is not a function
at Class.loadState (/web/static/src/js/chrome/action_manager_act_window.js)
opw-2471982
closesodoo/odoo#70285
X-original-commit: bf9a985f4b62cc6f1eef4f9fcca2a8dfbd453004
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: pvh-odoo <SwagSamaSempai@users.noreply.github.com>
Co-authored-by: Nicolas Lempereur <nle@odoo.com>
delete redundant '}' added by accident
The redundant '}' might be added by accident.
It makes the the correct avatar image cannot be found and shown as a default camera image when the user
* Open calendar
* Hover on on of the responsibles listed in the right side panel of the calendar view
closesodoo/odoo#69139
Taskid: 2504659
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
Previously, lazy-loading xml templates was only possible by fetching the
xml file directly, this meant that it was impossible to lazy-load an
entire bundle's templates with a single request. Additionally,
requesting the xml files directly meant that no inheritance was applied,
causing the need for a separate inheritance system using t-jquery on the
client-side.
This commit alters the /web/webclient/qweb route so that it now takes a
bundle id, meaning that it is now possible to lazy-load the xml from
arbitrary bundles.
task-2497943
closesodoo/odoo#70084
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Can be simplified a bit by using the newer features of
`tools.file_open()` and `tools.file_path()`.
Let's do it since the PR is touching these lines anyway
for the change of resource paths.
closesodoo/odoo#69614
Related: odoo/enterprise#17855
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Some features of the PDF.js library doesn't work in the
webview of the mobile apps.
Initially 'window.print' is defined as an empty function in
webviews unlike browsers where it is already ready.
After that, PDF.js needs to monkey patch 'window.print' and
saves a reference to the original definition, which is not
yet fulfilled in by the mobile app (Java part).
So the print of PDF.js doesn't work in webviews and end
users will need to download the file before printing it.
Regarding the Download button, the 'download' attribute is
not supported by the webview as you can see in:
https://bugs.chromium.org/p/chromium/issues/detail?id=432414
As there's many ways to download a file in Odoo it's not
a big deal to simply hide it in PDF.js.
Because it's quite complicated to fix this, we decided
to hide the features that don't work (Download / Print)
or don't make sense (Open file).
Note that a refactoring is already in progress in order to
avoid to patch this library in master.
closesodoo/odoo#70110
Task-id: 2200168
X-original-commit: 39225827035efe11cdc90b2a7f1ae1f24a54b136
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: rfr-odoo <rfr-odoo@users.noreply.github.com>
Done this way so `_message` can be overridden with custom
markup. Should now work properly ootb: `final_message` should be a
`Markup` from qweb rendering, if `_message` also is such, the merge
should happen without further escaping of either value.
Note: needed to convert the str.__mod__ call to a concatenation as
otherwise the markupness information is lost. That's probably a
recurring issue.
The process of making HTML reports palatable to wkhtmltopdf is a bit
involved, including various renderings intersperded with
processing. This means bits of HTML are created, which are
processed (via lxml) before being fed into further templates.
On step 3, the previously processed bits need to be marked as Markup
lest they be escaped again and lead to... odd results.
Also explicitly provide encoding for one case where it's not entirely
necessary but can't hurt.
Also un-escape <base> in report templates, it seems completely
unnecessary. And try to move it to the correct location to the extent
that that's possible: per-spec, it should be in the head, not outside
the document entirely.
* QWeb bodies should be markup-safe so `0` should always be
markup-safe.
* `head` is qweb-rendered so the same.
* The `json` pseudo-module in qweb templates is `json.scriptsafe`,
which should be markup-safe.
* The result of `plaintext2html` is fully controlled and
markup-safe (the first thing we do is escape the input).
* For `append_content_to_html`, we assume the inputs are HTML and the
output is thus always properly HTML.
Alternatively, we may want to `Markup("%s%s") % ...` and require the
inputs to be properly marked? That seems like a good idea.
* In `_replace_local_links`, applying re.sub will strip out the markup
mark, so store it and reapply it on output if necessary.
That one is a big gnarly, because if the input to ustr is
markup-safe bytes (e.g. qweb rendering output) then the output is a
Markup object, but if the input is str then the output is str, so we
need to check before and after unless... we update ustr to check for
subclasses instead of exact type?
* In `_prepend_preview` the issue is similar to that of
`append_content_to_html`, though in this case we should *not* trust
the input, so we can flag the "parent document" as Markup and format
the preview bit in.
* And since we're marking mail's jinja output as safe, do the same for
web and iot.
Sadly there doesn't seem to be any hook for doing that at the
environment level of jinja, so every `Template.render` site has to
be marked.
Add a big fat warning when the qweb compiler finds a `t-raw`.
`t-esc` should now be used everywhere, the use-case for `t-raw` should
be handled by converting the corresponding values to `Markup`
objects. Even though it's convenient, this constructor *should never
be made available in the qweb rendering context* (maybe that should be
checked for explicitely?).
Replace `werkzeug.escape` by `markupsafe.escape` in
`odoo.tools.html_escape`, this means the output of `html_escape` is
markup-safe.
Updated qweb to work correctly with escaping and `Markup`, amongst
other things QWeb bodies should be markup-safe internally (so that a
`t-set` value can be fed into a `t-esc`). See at the bottom for the
attributes handling as it's a bit complicated.
`to_text` needed updating: `markupsafe.Markup` is a subclass of `str`,
but `str` is not a passthrough for strings. So `Markup` instances
going through would be converted to normal `str`, losing their safety
flag. Since qweb internally uses `to_text` on pretty much
everything (in order to handle None / False), this would then cause
almost every `Markup` to get mistakenly double-escaped.
Also mark a bunch of APIs as markup-safe by default
* html_sanitize output.
* HTML fields content, sanitization is applied on intake (so stripped
by the trip through the database) and if the field is unsanitised
the injection is very much intentional, probably. Note: this
includes automatically decoding bytes as a number of default values
& computes yield bytes, which Markup will happily accept... by
repr-ing them which is useless. This is hard to notice without `-b`.
* Script-safe json, it's rather the point (though it uses a
non-standard escaping scheme).
* Note that `nl2br`, kinda: it should work correctly whether or not
the input is markup-safe, this means we should not need to escape
values fed to `nl2br`, but it doesn't hurt either.
Update some qweb field serialisations to mark their output as
markup-safe when necessary (e.g. monetary, barcode,
contact). Otherwise either using proper escaping internally or doing
nothing should do the trick.
Also update qweb to return markup-safe bytes: we want qweb to return
markup-safe contents as a common use-case is to render something with
one template, and inject its content in an other one (with Python code
inbetween, as `t-call` works a bit differently and does not go through
the external rendering interface).
However qweb returns `bytes` while `Markup` extends `str`. After a
quick experiment with changing qweb rendering to return `str` (rather
unmitigated failure I fear), it looks like the safest tack is to add a
somewhat similar bytes-based type, which decodes to a `Markup` but
keeps to bytes semantics.
For debugging and convenience reasons, MarkupSafeBytes does *not*
stringify and raises an error instead (`__repr__` works fine). This is
to avoid implicit stringifications which do the wrong thing (namely
create a string `"b'foo'"`).
Also add some configuration around BytesWarning (which still has to be
enabled at the interpreter level via `-b`, there's no way to enable it
programmatically smh), and monkeypatch `showwarning` to show warning
tracebacks, as it's common for warnings to be triggered in the bowels
of the application, and hard to relate to business logic without the
complete traceback.
`t-out`
=======
`t-esc` is a bit confusing for the new behaviour of "maybe escape
maybe not", so add a `t-out` alias with the same behaviour.
Unlike `t-raw`, `t-esc` is only soft-deprecated for now: there are
thousands of instances, so editing all the templates is not
great. Eventually we'll add a `ci/style` to prevent addition of new
ones, and eventually we might do a bulk-replace and hard-deprecate.
Attributes handling
===================
There are a few issues with respect to attributes. The first issue is
that markup-safe content is not necessarily attributes-safe
e.g. markup-safe content can contain unescaped `<` or double-quotes
while attributes can not. So we must forcefully escape the input, even
if it's supposedly markup-safe already.
This causes a problem for script-safe JSON: it's markup-safe but
really does its own thing. So instead of escaping it up-front and
wrapping it in Markup, make script-safe JSON its own type which
applies JSON-escaping *during the `__html__` call.
This way if a script-safe JSON object goes through `markupsafe.escape`
we'll apply script-safe escaping, otherwise it'll be treated as a
regular strings and eventually escaped the normal way.
A second issue was the processing of format-valued
attributes (`t-attf`): literal segments should always be markup-safe,
while non-literal may or may not be. This turns out to be an issue if
the non-literal segment *is* markup-safe: in that case when the
literal and non-literal segments get concatenated the literal segments
will get escaped, then attributes serialization will escape
them *again* leading to doubly-escaped content in attributes.
The most visible instance of this was the `snippet_options` template,
specifically:
<t t-set="so_content_addition_selector" t-translation="off">blockquote, ...</t>
<div id="so_content_addition"
t-att-data-selector="so_content_addition_selector"
t-attf-data-drop-near="p, h1, h2, h3, .row > div > img, #{so_content_addition_selector}"
data-drop-in=".content, nav"/>
Here `so_content_addition_selector` is a qweb body therefore
markup-safe, When concatenated with the literal part of
`t-atff-data-drop-near` it would cause the HTML-escaping of that
yielding a new Markup object. Normal attributes processing would then
strip the markup flag (using `str()`) and escape it again, leading to
doubly-escaped literals.
The original hack around was to unescape() `Markup` content before
stringifying it and escaping it again, in the attribute serialization
method (`_append_attributes`).
That's pretty disgusting, after some more consideration & testing it
looks like a much better and safer fix is to ensure the
expression (non-literal) segments of format strings always result in
`str`, never `Markup`, which is easy enough: just all `str()` on the
output of strexpr. We could also have concatenated all the bits using
`''.join` instead of repeated concatenation (`+`).
Also add a check on the type of the format string for safety, I think
it should always be a proper str and the bytes thing is only when
running in py2 (where lxml uses bytestrings as a space optimization
for ascii-only values) but it should not hurt too much to perform a
single typecheck assertion on the value... instead of performing one
per literal segment.
Note: we may need to implement unescape anyway, because it's still
possible to get double-escaping with the current scheme: given an
explicitly escape-ed `foo` and `t-att-foo="foo"`, `foo` will be
re-escaped.
fixup! [CHG] core, web: deprecate t-raw
This mostly an issue when trying to run just the tests of `web` (aka
`-iweb`) with only community modules available,
`TestMenusDemoLight.test_01_click_apps_menus_as_demo`, wait for the
ready code times out:
AssertionError: False is not true : The ready "odoo.isReady === true" code was always falsy
and the test suite fails.
The ready code simply checks that `odoo.isReady` is set. The web
client sets `isReady` when `webclient_started` is
triggered (specifically in `_onWebClientStarted`, which is the handler
for that event).
[The community web client only triggers `webclient_started` at the end
of `doAction`][0] meaning the community client is considered ready
until after the first action has executed.
[The first action is executed by `show_application`][1] whose process
is the following:
1. load and initialize the menus
2. if an action is specified in the URL, run that
3. otherwise if the user has a home action, run that
4. otherwise run the first menu's action
When installing only `web`, the only menus which could be available
are Apps and Settings, and the demo user has access to neither. This
means the demo user has no applications, and opening the first app is
a no-op ([`openFirstApp` has a case just for that situation to ensure
it does nothing][2]). As a result, `webclient_started` is never
triggered, `_onWebClientStarted` is never called, `odoo.isReady` is
never set, and the tour never runs.
Fix by updating `openFirstApp` to return *whether* it opened an
application, and in `show_application` the last fallback if even
opening the first application failed is to just declare the web client
ready.
While at it, rewrite `show_application` using ES6 facilities and
flatten and linearize it using guards. This means the code pretty much
tracks the process described above, with one step added:
5. otherwise complete the webclient's startup
[0]: https://github.com/odoo/odoo/blob/1eb474243b55f1b9e10c70d199bbe022e68b51d0/addons/web/static/src/js/chrome/action_manager.js#L174
[1]: https://github.com/odoo/odoo/blob/d1c56ec7c435c5baba8604feccc6116e4c25ca96/addons/web/static/src/js/chrome/web_client.js#L77-L107
[2]: https://github.com/odoo/odoo/blob/e24ab17d38fb049404f04112990e8b2fe1dd7727/addons/web/static/src/js/chrome/apps_menu.js#L44-L46closesodoo/odoo#70039
X-original-commit: a5b2146404da9ea0cd4752a21dcd230140822c86
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The changed test uses the drag&drop helper, and an operation does
not work as expected with the given params on chrome 90. The runbot
currently uses chrome 80, so it is not an issue, but if your chrome
is up-to-date, and you try to run the test suite, this test would
fail.
closesodoo/odoo#70032
X-original-commit: 43994da9980e4133274984f720bb58f3546ea0f9
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When the colorpicker is in an iframe, listening to mouse events on the
global document can have unexpected effects. Namely clicking in the
colorpicker, then moving the mouse outside the iframe made it move the
color cursor.
This fixes that by binding it to the parent widget's document, with a
fallback on the global document in case it's missing.
closesodoo/odoo#69877
X-original-commit: 4fb33f7f8d6955a44fbb7c94c7d204e9baa09707
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Follow up on bd67479316
This test file is not respecting Odoo module dependencies.
If the module is not defined, calling `[Symbol.for("default")]` will crash.
Old require system didn't have this syntax, the similar guard was done just
before using the class.
closesodoo/odoo#69845
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The PR https://github.com/odoo/odoo/pull/68799 tried to prevent the
form's edit button to bounce when quick editing.
The fix was wrong and some field continued to bounce the button.
This commit prevents the edit button to bounce when clicking on
any field by checking if we are quick editing.
closesodoo/odoo#69826
X-original-commit: 8393b3c51b38bd285acb91279cb08a28c241c9ca
Signed-off-by: Michaël Mattiello <mcm-odoo@users.noreply.github.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This is arguably a 20 years old Firefox bug (at the very least an
under-specified area of the spec where Firefox's behaviour is
technically allowed under spec but not super useful or convenient):
`window.getSelection()` simply doesn't work when invoked on a form
field: https://bugzilla.mozilla.org/show_bug.cgi?id=85686.
Getting the selection data more explicitly by looking up the focused
form element, then checking *its* selection, seems to work fine and be
cross-browser.
Also focus() the input while at it: according to MDN
> Calling element.select() will not necessarily focus the input, so it
> is often used with HTMLOrForeignElement.focus.
And jQuery doesn't really document whether `select()` will implicitly
`focus()`, so better safe than sorry.
closesodoo/odoo#69579
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Testing what's literally just a native feature seems odd, but in this
case it's also way over-specified: Firefox's error message for the
conversion of a symbol to a number is
can't convert symbol to number
In the sign app, if a signature is saved in mobile resolution, when the user tries to sign a document in desktop, the size that is shown is the mobile size, which is strange for the user.
This PR is an odoo change and it modifies the library method that adds the image to the canvas, resizing the image to the canvas size.
task-2479787
closesodoo/odoo#68160
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
In mass mailing edition, in some configuration of:
- being in a modal or not
- size of window
- zoom level
we might get an error when getting the scrolling element.
For example when editing a mass mailing, if I set my viewport to 595
pixels height and have a 90% zoom, the editor is broken.
This is because in SnippetsMenu.starts `$().getScrollingElement()`
doesn't find an element that has the height of body. In my use case body
height is 329.111 pixels, and scroll height is 328 pixels.
Testing different zoom level and viewport height, the maximum difference
I was able to get was 1.25 so this commit increase to 1.5 the maxmimum
difference.
opw-2455727
opw-2469174
closesodoo/odoo#69664
X-original-commit: c7a4cca4a082af7c6b33a70d4b19e700e4d487e7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Add a new parser in the ace for the qweb highlight. This makes it possible
to visualize the qweb tags and the part of code.
Used in the website and in xml fields.
closesodoo/odoo#69609
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
When we have (inline) domain widget within a modal, user can not see
all the fields because overflow is hidden on the modals by default.
This is not ideal behavior.
With this commit, when the inline domain editor is opened with field
widget within a modal, we allow field selector to overflow by
manually setting visible overflow on the parent modal. The changes
are inspired by 'DomainSelectorDialog'.
Task ID-2480625
COM odoo/odoo#68586
Before this commit, `getTZOffset` and `user_has_group` weren't
correctly reset to their initial values after tests. As a
consequence tests executed afterwards might behave unexpectedly.
closesodoo/odoo#69497
X-original-commit: b7b83db88c61d7db87045d87b09d7348f3a8a9eb
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The /web/webclient/translations route's `lang` argument has had some
changes in the last year:
- before june 2020 (a9a756cf): very often it was set to null
- after june 2020 (a9a756cf): it was more often correctly set or had
en_US as fallback so never null
- after 31 march 2021 (8cc06617) in saas-14.3: lang is not sent to
server if it is null (which should never happen)
- after 15 april 2021 (a93a0a3): en_US fallback is removed to prevent
overriding server language if another language is better
But the fix in 31 march and 15 april are not compatible because the
route /web/webclient/translations require a lang argument.
With this changeset, lang argument is always sent to the server.
closesodoo/odoo#69487
X-original-commit: 0604dce996882fb93cd71885f7eb4d0749eb357f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit, `WidgetWrapper` tried to redirect the call to
`updateState` on its wrapped component but it can happen that the
wrapper is not mounted yet and thus calling a function on its wrapped
component will crash.
This commit changes the implementation of `WidgetWrapper.updateState`
to redirect the call to `this.update` which will update the props of
the wrapped component and not directly its state.
task 2504521
closesodoo/odoo#69421
X-original-commit: 67f09b9a9df248fec26f53758e76070ab3171435
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With this commit we try to improve the way the events are displayed
to the user. Now, an event is displayed for each attendee of the event
that are selected in the filter. These events are displayed correctly
based on the status of the attendee in the event.
The colors displayed for the events now represent the attendees and not the
organizer.
If an attendee edit an event, it is edited for all others attendees.
Also, when an attendee that is not the organizer try to delete the event,
then the event is now declined in place of being deleted. If the organizer
delete the event, it is deleted for all attendees.
In case of an event where all attendees have declined it but the organizer,
the organizer see now a danger icon before the name of the event and it's
outlined and not filled with color, no matter of the actual status of the
organizer in the event.
task-2196775
COM PR: odoo/odoo#55190
ENT PR: odoo/enterprise#12196
UPG PR: odoo/upgrade#1532
The calendar renderer used a template for events.
Now moved as a configurable template to ease futur calendar changes.
This commit adds also a custom event to the calendar renderer so that custom
implementations have a way to re-render the event items within the calendar
after making internal changes to the event records.
We introduce also a new option for a field "filter_field" which allows to specify
the field of the model in which we will save the status of a filter.
This is preliminary changes in order to make the calendar view able to modify
the attendance status of a meeting and refresh the events to visually display
if the user is attending or not.
Task ID 2196775
COM PR: odoo/odoo#55190
ENT PR: odoo/enterprise#12196
UPG PR: odoo/upgrade#1532
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: jeh-odoo <jeh@odoo.com>
When loading translations from Session, if no lang is defined in context or html,
it is loading translations of en_US lang by default.
No default should be used to fallback on the language of the current user.
opw-2501708
closesodoo/odoo#69336
X-original-commit: 0b9ab4efcf66d4c5099a9f33d2fb1b4dd814eb5c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Commit [1] recently fixed an issue with nested x2many fields and
onchanges: in some cases, all field values weren't sent to the
server as they should.
However, there is a small issue with this fix. We didn't correctly
apply the default value to option `changesOnly`: when not given,
it was considered false, whereas in this particular function it
should have been true.
It caused an issue in the following scenario:
Have a form view with an x2many field (say A) displayed as a list.
In the list, there is another x2many field (say B), and (whatever
its type) a field C with an onchange. When the user changes C, the
onchange is performed, and we send to the server the value of all
fields. In particular, in the row, we send the value for the
many2one field pointing to the main record (the inverse field of
the x2many relation). The value for that field is basically the
whole record, containing itself field A. For field A, the value is
a list of commands, and for the updated record, it is a command 1.
Before this commit, in the values sent for this command, field B
was the empty array, even if it wasn't empty.
This issue was reproducible in account.move, on an existing record
having already a line in invoice_line_ids (this is field A). In
that line, tax_ids (this is field B) must have a tax which is
included in the price. When changing the quantity of the product,
the subtotal wasn't correctly computed.
[1] https://github.com/odoo/odoo/commit/a8b43d02066b2299ac2f4b88056c37725e9ce6cd
opw~2489755
closesodoo/odoo#69227
X-original-commit: 3f54ca3e29d1537f66c6a3b56494dc065d9230e9
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since commit [1], a delay was added to "debounce" the quick edit to
check if the user did a click or a select.
Because of this delay, the edit button now bounces when clicking on
a field or label.
In this commit, we check if the user clicks on a "quick editable"
field or a label to prevent bouncing.
[1] https://github.com/odoo/odoo/commit/2939ea4dd4736e659cc3e4df2226a3b08ac8ec48closesodoo/odoo#68835
X-original-commit: 755a02135049f22e1e8db356169b5224f00c1f92
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Before this commit, we must to copy paste the functions useful for the
GraphRenderer when we override this model.
This commit moves the functions and the global variables in a new module
called graph_utils.
task-2458017
Rationale:
The majority of cases where an ir.asset is manually declared
outside of manifest files is to specifically add a single asset file.
This means developers are specifying a single asset *path*, and not a
glob expression. In this context, it seems better to name the filepath
field `path`, and document that it can be specified with a glob
expression when (seldom) needed, rather than making the exception appear
to be the norm - possibly puzzling many developers (What's a glob and
why do I need one?)
The doc is updated as well, and some spell-checking and wording
improvements were done too.
This required some adaptations to the existing `ir.asset` declarations:
- odoo/enterprise#17465
- odoo/design-themes#459closesodoo/odoo#68695
Related: odoo/upgrade#2348
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Change the conversion to HSL system to return floating values and leave
the rounding to the caller (for instance when converting to RGB system).
Part of https://github.com/odoo/odoo/pull/68488
X-original-commit: eab46cb2fdc55cf4951977bfc32751a33374fe1d
This should hopefully fix the race condition that is described in the related
task. The issue is that our mounted callbacks are legitimately relying on the
component to be actually rendered.
task-2481713
closesodoo/odoo#68838
X-original-commit: 8782de993d922b321d3be479dbb84e9d20a0c87a
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
On website app installation and on new website creation a configurator is launched.
The purpose of this configurator is to generate a website that meet the user's needs.
The configurator is composed of 4 steps:
1) Business description: the user is asked to describe its need with its website purpose (dropdown), its industry (autocomplete search) and its objective (dropdown).
2) Logo and palette selection: the user must select a color palette for its website. He can also upload its logo. In this case color palettes recommendations are generated based on the logo's colors.
3) Features selection: the user select the pages and applications he needs.
4) Theme selection: three themes are recommended to the user based on its industry. This screen display a preview of these three themes.
task-id: 2451965
ENT PR: odoo/enterprise#16949
UPG PR: odoo/upgrade#2316closesodoo/odoo#67537
Signed-off-by: Sébastien Mottet <smottet@users.noreply.github.com>
Lucas Perais (lpe)