ISSUE:
The click on "THEME" tab in editor panel triggers the
'_onThemeTabClick' method which:
1- Starts the loader ('_execWithLoadingEffect' method).
2- Runs '_activateSnippet' which uses the same mutex as the
loader.
Execution order:
A1- '_execWithLoadingEffect' with promise: adds the loader in
the DOM immediately.
A2- '_activateSnippet' sets a second loader to be added after
a delay = 500.
A3- 'releaseLoader' removes the first loader.
A4- '_activateSnippet' ends : (before adding the second
loader: t(4) - t(2) < 500) and timeout is cleared.
In some cases we get t(4) - t(2) > 500 which adds a second
loader to the DOM, and the new flow will be:
B1- Same as A1.
B2- Same as A2.
B3- Second loader added to the DOM / replaces the first one
in 'loadingElements'.
B4- 'releaseLoader' removes the second loader (from the DOM
& 'this.loadingElements').
B5- Same as A4 but the first loader still in the DOM.
The goal of this commit is to fix this behaviour by preventing
more than one loader on the target element.
task-2656308
closesodoo/odoo#77500
X-original-commit: 9f21b2eefab2115c1b8581ad9f43fe1e65f934ed
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This merge will improve the layout of the mail composer and the resend modals
* revamp the mail composer and the resend modals: It will update the labels,
clarify the helper messages and make the buttons more dynamic;
* simplify the mail composer: advanced options will be placed in a dedicated
pane;
* various minor layout adjustments;
See commit messages for more info.
Task-2523036
closesodoo/odoo#71413
Related: odoo/upgrade#2877
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When the user opens the notification panel from the navbar and click on
a notification indicating that an error occurs while sending an sms
or an email, the user will be redirected to a new view listing the users
that did not received the sms or the email. As it makes no sens to create
a partner from that view, we will remove the "CREATE" button.
task-2523036
Part-of: odoo/odoo#71413
The error messages of the resend modals can be partially hidden in the
table. The user can therefore have difficulty to understand what went
wrong when the server failed to send an email or an sms. To avoid that,
we will ensure that the error messages will be fully visible in the table.
To improve the interface, we will also update the label of a some fields
and we will automatically hide the 'Send & Close' buttons from the resend
modals when the user did not select at least one recipient from the list.
task-2523036
Part-of: odoo/odoo#71413
The settings page of the mail template has too specific placeholders. To
improve the genericity and the consistency of the placeholders, we will
use placeholders about the same topic.
task-2523036
Part-of: odoo/odoo#71413
On the CRM module, the user can send an email to all the contacts
associated to the leads matching some criteria by (1) displaying the
list view, (2) applying a search filter, (3) clicking on the "EMAIL"
button and (4) checking a checkbox on the mail composer to ask the
server to use the active search. To do the same thing, the user can
(1) display the list view, (2) apply a search filter, (3) select all
the records and (3) click on the "EMAIL" button.
To avoid redundancy and improve the usability of the composer, we will
remove the search domain passing from the mail composer. Note that it
will still be possible to pass a search domain programmatically.
To improve the guidance of the mail composer, we will add helper
messages, update the labels and move the options in a dedicated pane.
The wording of the buttons will also be updated dynamically based on
the selected options.
Example: When the user enters something in the `mass_mailing_name` field
to create a new mass mailing campaign from the new message, the label of
the "Send" button will be set to "Send Mass Mailing" which gives more
indication on what will happen when the user clicks on it.
task-2523036
Part-of: odoo/odoo#71413
Customisations made by the themes for the Text-Block
snippet were also applied in the Tabs snippet.
And so, options like paddings and background-color
generated unexpected and potentially broken layouts.
closesodoo/odoo#77479
X-original-commit: 3e046fdc8edf630919ec7d6b753100100cb78f05
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This PR introduces a new component: the layout component.
Its purpose is to make abstraction of most generic components and
classes when writing a view template or an action.
To make use of this component, we also needed a new system to pass slot
from the parent of the layout to the control panel. This was done in a
hacky way and is meant to be replaced as soon as Owl provides a built-in
way to pass slots.
The control panel has also been slightly tweaked to default its props
from an environment's newly introduced key: the 'config'. This has been
done to reduce the amount of props passed to the layout and search
subcomponents.
closesodoo/odoo#77463
Forward-port-of: odoo/odoo#76140
Related: odoo/enterprise#21295
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit handles the adaptation of any component using the search
model's 'action' and/or 'view' key, now replaced by the environment
keys 'actionContext' and 'viewContext'.
Affected modules are:
- base_import
- board
- crm
- google_spreadsheet
- project
X-original-commit: 40f1ae87e1436192a70a8a7432eb72d379cfa6dc
Part-of: odoo/odoo#77463
This commit rewrites the pivot view template to make use of the view
layout component.
X-original-commit: ebb046c5b9b6b629fd6731a419c5b7daf57a9f7d
Part-of: odoo/odoo#77463
This commit rewrites the graph view template to make use of the view
layout component.
It also removes a duplicate test in the graph test suite.
X-original-commit: a9a65fd51a2317adc07bf3742f7edc360236d32e
Part-of: odoo/odoo#77463
This commit introduces a new component: the layout component.
Its purpose is to make abstraction of most generic components and
classes when writing a view template or an action.
To make use of this component, we also needed a new system to pass slot
from the parent of the layout to the control panel. This was done in a
hacky way and is meant to be replaced as soon as Owl provides a built-in
way to pass slots.
The control panel has also been slightly tweaked to default its props
from an environment's newly introduced key: the 'config'. This has been
done to reduce the amount of props passed to the layout and search
subcomponents.
X-original-commit: 3b29dd230acd961a72fb0cb971f9363958f65b60
Part-of: odoo/odoo#77463
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Before this commit, the search model would consider displaying a
search panel regardless of whether it had any sections.
Now, the search panel is considered non-displayable when there is no
sections.
X-original-commit: d3b191600b50fb052a956d1199730453789674e2
Part-of: odoo/odoo#77463
The identification of timedelta with relativedelta was wrong.
Here we define a class PyTimeDelta used by py.js to evaluate most
expressions in which datetime.timedelta and some operations producing
timedeltas occur.
The class PyTimeDelta allows to:
- create a timedelta
- add/substract two timedeltas
- multiply (divide) a timedelta by a float (resp. an integer);
- take opposite of a timedelta
- evaluate equalities between timedeltas and other expressions
- decide when a timedelta is "false"
- get total_seconds of a timedelta
In relation with that, we have improved the implementation of PyDate
and PyDateTime to allow most manipulations of datetime.date and
datetime.datetime producing/using timedeltas. It is now also possible to
evaluate equalities between dates/datetimes and other objects.
closesodoo/odoo#77453
X-original-commit: fcd4959a65a92e34ce986575c7fc279c195e9a11
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>
BEFORE THIS COMMIT / How to reproduce :
Consider a multiple choice question with single answer.
A. 2 points
B. 1 point
C. -1 point
Here, the user can only select one answer. He picks A. He only obtains 2/3 points.
This is because the maximum score was computed as the sum of all positive scores
for the question. It does not make sense, as the student can only pick one answer.
Therefore, the formula does not allow giving partial scores (here, answer B, close
to the correct answer) while maintaining correct score percentages.
AFTER THIS COMMIT:
The sum of positive scores is still used as maximum score for multiple choice
with multiple answers, as we want the student to pick all good answers for max score.
However, for multiple choice with single answer, we use the maximum positive score
(or 0, if none) among answers, as it the maximum score one can get while selecting
a single answer.
-> example above : I pick A, I obtain 2 points out of max(2, 1, (0)) = 2
-> I obtain max score for the question. 2/2.
ps: As the sum only uses striclty positive values, the negative points are still
operational and the flow is not changed.
TESTS:
A test test_partial_scores_simple_choice is added to make sure the simple_choice
is repaired and always gives 100% of points if the best answer is picked.
Task-2533836
closesodoo/odoo#77426
X-original-commit: 2cdfb7805564943ccf857e49b41d3b597fd727bb
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes two issues
* better handle void partner_id;
* get back ``object.origin`` that was removed when converting into QWeb
at odoo/odoo@0a180d04b0
Task-2657930
closesodoo/odoo#77451
X-original-commit: 3b3a47f0d3414ae5bee159f6ec4644e64441040f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
In some cases, it is impossible to validate some landed costs ("Cost and
adjustments lines do not match.[...]")
To reproduce the issue:
(Enable debug mode)
1. Set the Decimal Accuracy of Product Price to 4
2. Create a Product Category PC:
- Costing Method: FIFO
3. Create 4 storable products (category PC)
4. Create a service product (landed cost)
5. Create a PO with the 4 products:
- 6 x $0.92
- 6 x $0.92
- 3 x $75.17
- 6 x $20.54
6. Process the delivery D
7. Create a Landed Cost:
- Delivery: D
- Product: the service product
- Split Method: By Quantity
- Cost: $1000
8. Compute the landed costs + Validate
Error: a User Error is raised "Cost and adjustments lines do not match.
You should maybe recompute the landed costs.". The sum of the additional
landed cost equals $999.99 instead of $1000
From version 14, `additional_landed_cost` is a Monetary field and its
rounding property is no more based on "Product Price":
https://github.com/odoo/odoo/blob/800433bde03a36ead40a78bc6d53cbb95c24f97b/addons/stock_landed_costs/models/stock_landed_cost.py#L371-L372
Therefore, we should use the rounding of the associated currency to
round its value
OPW-2637701
OPW-2631718
OPW-2649348
closesodoo/odoo#77445
X-original-commit: c2750517428be83eb278894932e57e0a9a78fa6d
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
It turns out that the group-by 'availability' filter of the
'calendar.event' model is not really meaningful. We will hence remove it
to simplify the interface. Note that the users will still be able to group
the records by 'availability' by defining a custom group.
task-2646322
closesodoo/odoo#76901
Related: odoo/enterprise#21038
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Before this commit:
Let's consider the following two scenarios while answering time limited survey:
1) attendee's system clock is de-synchronized compared to the real time
2) Odoo server clock is de-synchronized compared to the real time
In any/both of the above cases, it will lead to a wrong timer display, and will
confuse the user and/or make him fail the test because he will think he still has
more time to submit when he does not.
With this commit:
To fix this, we simply get the offset of server UTC time and moment time, and apply
the offset while calculating the time remaining.
Task-2612972
closesodoo/odoo#77419
X-original-commit: 9e9cd045b2899abc5c8e4a92c43ed6eb2eea158a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, when creating a new ribbon after selecting an
existing ribbon, the style of the selected ribbon was added to the new
ribbon in addition to the default style.
task-2501515
closesodoo/odoo#77412
X-original-commit: 10867860489214b956fbe7fac5ff36f24c94c46d
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, the text color preview of the ribbons in the
ribbon selector was wrong. But also, if we selected another ribbon
just after changing the text color of a ribbon. This color was applied
to the selected ribbon.
task-2501515
X-original-commit: 19252137588b30a69ce57f0248a504f7e929b98e
Part-of: odoo/odoo#77412
Before this commit, a traceback was raise:
Cannot read properties of undefined (reading 'displayNotification')
Now, we correctly use self instead of this.
task-2657621
closesodoo/odoo#77360
X-original-commit: ab65d077b7b4ec04155401902eb65418b4d2f415
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- Avoid traceback when click on priority widget
- Also, fetch directly the lazy column if the web client read one record
(happen when we modify a single record).
closesodoo/odoo#77402
X-original-commit: eb26406cff7a0c61768c287a0525c2b6bc123f9e
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Avoid some useless read_group on stock move (fetch too much qty fields
in product.product) and use a query object to avoid fetching data.
To compute 11K of forecasted information of stock move (multi-warehouse
):
- Before: 1.704 ± 0.046 sec and 174 SQL request
- After: 1.554 ± 0.012 sec and 134 SQL request
X-original-commit: 338edd616c2afe1d7a08a06a0b0278c3d7083c05
Part-of: odoo/odoo#77402
If an invoice is posted, sended back to draft and the rate was change on res.currency, we preserve the value already existing on l10n_ar_currency_rate
closesodoo/odoo#77388
X-original-commit: 820df9eef856d841863306eab1e26d0437a408b0
Signed-off-by: Josse Colpaert <jco@openerp.com>
When clicking on send&print on an account move without
partner, we are getting a traceback because of the
address verification.
Instead, check if any such move is selected and return
a user error.
Task id #2655365closesodoo/odoo#77385
X-original-commit: dfba014189c35f9df0140c57effe9ea45637e0ec
Signed-off-by: Florian Gilbert <FlorianGilbert@users.noreply.github.com>
When importing an invoice with facturx, the space for the name was
wrongly defined which would make it so that it was never found in the
xml.
Task id #2655365
X-original-commit: cf85aa4dc5d3e8cb2565c90be4f487f0aade07f3
Part-of: odoo/odoo#77385
General fixes for usability
- Time off type configuration visual : https://tinyurl.com/yj2z6okp
- When you create an allocation, the end date should have a place holder "no limit". If there is no end date recorded, that value should be displayed on loading.
- In Overview, remove filter "people i manage"
- In Approvals / time off : change filters : https://i.imgur.com/uDNjZv8.png
- In Approvals / approvals : change filters like in point 5 (remove people I manage replace with my team)
- In Reporting / By Employee : filters : https://tinyurl.com/yg3u3rkf
- In Reporting / By Type : filters : https://tinyurl.com/yhbpgz5m
- Remove Allocations smartbutton from Employee App
- When you click on TimeOff Smartbutton from Employee App, you should be redirect to this screen : https://tinyurl.com/ygwxzx5b
- When an allocation is created, the validity is added to the name of the allocation like "Allocation X (validity Date --> Date) and hide the validity field in "My allocations".
- Users will have the information of the validity from the name of the allocation
task-2643692
closesodoo/odoo#77376
X-original-commit: 7f92c830d3607167bd76bc43d992fbf720a3ef29
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
`tz` field is technical field related to `resource_id`, which is required field on that model.
However it is possible to try to write a void value, which leads to an issue as it is technically required.
With this commit we make the tz field required at write.
closesodoo/odoo#77372
X-original-commit: 7cda3632b1f50ea757d25369e8a1261d8aeab16d
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The pivot and graph views have been rewrote in owl in [1]. However,
the former implemention has been kept as it is still used in some
cases (e.g. board application, studio, PieChart widget), but they
are lazy loaded [2].
Before this commit, both the new and former implementations mostly
shared the same DOM (in particular, their root element had the
same classnames). It means that the scss rules of an implementation
might interfer with the other, and vice versa.
This commit adds the "legacy" keyword in the root classnames of
those views, and properly namespaces the scss rules of legacy views
to properly dissociate the style of new and legacy views.
For the pivot view, we re-used the same scss file, so in this
commit, we duplicate it (one for the new view, the other, lazy
loaded, for the legacy view).
[1] 0134495ba5
[2] bd3cf85c841168dfd87f7166b545dd00d9b38bf4
closesodoo/odoo#77323
X-original-commit: 3862d5aae1df72d3585f915e8a2a2626322e74ad
Related: odoo/enterprise#21223
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
When the current app doesn't provide menu-items (or the user doesn't
have the rights to access them), the mobile burger menu should fallback
to the user menu instead of an empty one (like on the App Switcher).
task-2345001
closesodoo/odoo#77322
X-original-commit: 90eecd990c7c97f5914252a9cad28eeb71859e0d
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Steps to follow
- Add an HTML field in the sales order line view
- Create a sales order
- Add a product
- Add a table with multiple rows in the HTML widget
- Add a new product
-> The new product isn't selected
Cause of the issue
The CSS selector used for finding the record to edit was taking all tr
element into account
Solution
Only select direct descendants of the tbody
opw-2632817
closesodoo/odoo#77380
X-original-commit: a8a0f38f5f45f18bc8221bf835d6e54ddabc471d
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Hubert Van De Walle <hubvd@users.noreply.github.com>
The option was available before but was forgotten when the graph view
was refactored.
closesodoo/odoo#77330
X-original-commit: 624fd812c5d6b01c0cc11e8620dc703dc0370f73
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the clickbot test failed when switching from
a dashboard view to a pivot, graph or cohort view, because the
condition to wait before toggling the filters in the next view was
wrong. As a consequence, we started to toggle the filters for the
next view on the dashboard view, so when we actually switched to
that view, the filter menu was closed and the tour was blocked.
The previous condition used the `.o_{view_type}_view` classname,
targetting the root node of the view (which appears in the DOM when
the view is loaded). Unfortunately, since [1] and the new
implementation of the graph and pivot views, we added root
classnames to graph and pivot (o_graph_view and o_pivot_view),
whereas it wasn't the case before. So when leaving a dashboard
view to a graph or pivot view, the former condition was directly
true (if the dashboard contained those views), and we didn't wait
for the next graph or pivot view to be loaded.
Note that the former implementation of the cohort view already added
the "o_cohort_view" classname on its root node, but it didn't make
the clickbot test fail because we don't have cohort views next to
dashboard views in standard actions.
This commit changes the condition to use the view switcher icons
instead.
[1] 0134495ba5closesodoo/odoo#77324
X-original-commit: bc53eebc8b9cd9f6e949bbe7e91ec2f98e5a0dfc
Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Explicit flushing of the cursor had been implemented in the "legacy"
`url_open` helper, but it was missing when going through `requests`
directly (via the `opener`), or when performing XML-RPC calls.
Fix that:
* extend `requests.Session` and `xmlrpc.client.Transport` so they take
a cursor
* move the setup of the XML-RPC clients to `setUp` so they can *get*
the cursor
* move the rest of `HttpCase.__init__` to `setUpClass` and drop the
override entirely
* remove the now-redundant flush in `url_open` (as it's done by the
`opener`)
closesodoo/odoo#77359
X-original-commit: c7bdae34690f31960d1fa95b5c3b4052540f5d07
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
RATIONALE
Jinja is used a templating engine in various places, notably in mail templates
and digest content. It is known to have some limitations
* its syntax is specific and is concurrent with Odoo QWeb template language.
Additional knowledge is required just for that purpose;
* it is not XML compliant, meaning we quickly run into issues when editing
its content as HTML. Notably rendering engine (browsers) may reorder
jinja content arbitrary when its syntax is not valid, which is often
the case with advanced constructs involving nested for and if;
* jinja template do not benefit from improvements done in QWeb and its
integration in our HTML editor;
* it is an outside templating engine that we do not control;
* it adds an external dependency;
PURPOSE
Replace Jinja with Qweb so that we can now build tools to edit a Qweb
template, mainly for ``mail.template`` records. In this merge we now
support QWeb as rendering engine for mail templates. All templates are
updated accordingly. Some other records using jinja are also updated like
``digest`` content (tips).
To be able to edit template content from the backend interface a plugin to
the Odoo editor has been made to seamlessly edit documents. It includes :
* allow to make dynamic variables (eg. `<t t-out="variable"/>`) not
editable when required;
* group and hide related logical branching (ie. t-if, t-elif and t-else)
in order to see only one at once;
* a floating select input to switch visibility of a particular logical
branching;
TEXT RENDERING
Not all content previously rendered using jinja holds HTML content. For
example some email fields (e.g. ``email_from`` or ``subject``) used Jinja
syntax for rendering (e.g. ``Email for ${object.name}`` or
``${object.email_formatted | safe}``).
We want to keep dynamic rendering for those char fields. However as it is
not XML we use a new rendering engine called "inline_template". It is
based on QWeb rendering used to evaluate expression and attributes like
``t-att-href="{{object.link}}"``. Expressions should be enclosed by `{{` and
`}}` to highlight they are dynamic. For most expressions this is equivalent
to jinja expressions with a simple marker change.
LINKS
Task-2497930 (Main editor task)
Task-27033 (Main functional task)
closesodoo/odoo#77377
Forward-port-of: odoo/odoo#77074
Related: odoo/enterprise#21246
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Add a plugin for the Odoo editor that includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
- style t-tags to make them stand out
Task-27033
X-original-commit: odoo/odoo@300da82eb4
Part-of: odoo/odoo#77377
Jinja as a templating engine was problematic in differents respect:
- introduce external dependency to Odoo (less controll)
- add another templating mechanism in the stack
- specific feature in qweb cannot be reused
- difficulty in rendering easily editable templates
- more knowledge required with no betterment
By replacing jinja with qweb we can now build tools to edit a qweb
that will work with the previously jinja encoded document
(essentially `mail.template` records).
There is a catch however. Some email fields (eg. email_to) used jinja
syntax for rendering dynamic variables (ie. ${object.something} and
${object.something_that_should_not_be_escaped | safe}).
We still want user to use dynamic variables for some char fields (eg.
subject, from, to, ...). We made a new rendering engine called
"inline_template" that will render an expression enclosed by `{{` and
`}}`.
To be able to edit the templates from the backend interface, a
plugin to the Odoo editor has been made for seamlessly edit the
document.
This qweb plugin includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif, and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
Task-27033
X-original-commit: odoo/odoo@68182baff4
Part-of: odoo/odoo#77377
xO-Tx
