We improve various aspects of the domain selector:
- We make the domain selector be able to display all domains accepted by the class Domain (domain.js)
- We improve the edition/selection of values, e.g. for the operators in/not in
- We improve/simplify the style/dom
Task IDs: 3507123, 3508940
closesodoo/odoo#128680
Related: odoo/enterprise#48324
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Mathieu Notté <mano@odoo.com>
This commit removes instagram from the `snippets_all_drag_and_drop` tour
to prevent too much external calls.
task-2603045
closesodoo/odoo#138558
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This PR offset the cart_summary of the size of the tallest header to
make sure the header is not hiding the cart summary when the user
scrolls in the checkout.
This is a temporary solution and the real header height should be
used as a value instead of the default's one.
task-3551420
closesodoo/odoo#138543
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
A traceback occurs when clicking on Search More in the employee field of
expense if the user has no rights on employee
Steps to reproduce:
1. Install Expenses
2. Go to Settings > General Settings > Users and click on Manage Users
3. Open user Mitchell Admin and remove all access rights on Employees
4. Go to Expenses and create a new expense
5. Click in the employee field, then on "Search More..." in the dropdown
6. An error occurs
Solution:
Depending on the group of the user, use 'hr.employee' or
'hr.employee.public' as done in https://github.com/odoo/odoo/commit/41eaff0f4c172a6018b0c8d9518d521c3832ef94
opw-3473418
closesodoo/odoo#138539
X-original-commit: 5d842587090b684786c3279d1ebe962ae57021b7
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Commit [1] introduced a method to restore the mega menu state (closed)
so it's not saved open when saving the website builder edition.
That method is `_restoreMegaMenus()`.
It was then moved with commit [2], where it was called in `destroy`
where it was actually making the code crash because once you reach
`destroy`, the website content (the iframe) has already been reloaded
(and thus removed / recreated).
It's done through `reloadIframe()`.
So, depending of your network speed and the server response time, if the
page is served before reaching the mega menu restoration, it will crash.
Restoring the mega menu in the (wysiwig) destroy doesn't seems to do
anything as the page is already saved when reaching `destroy`.
Step to reproduce:
- Have a high latency, like 500ms (you can create a profile in chrome
debug tool in network tab)
- Create a mega menu on the website
- Enter edit mode
- Directly save or discard
-> Traceback, the jQuery toggle elements (`.o_mega_menu_toggle`) are not
in the DOM anymore, since the iframe got reloaded. Those elements
thus don't have a reference to `$` anymore, ultimately making this
line crash:
```js
const $toggle = toggle.ownerDocument.defaultView.$(toggle);
```
[1]: https://github.com/odoo/odoo/commit/1345702258adbfbee0d780dc22e552395e6d1df7
[2]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997
opw-3483837
opw-3478642
closesodoo/odoo#138538
X-original-commit: caeb92bfb624c9c30ec9f9e3c2b1dd385e9b089b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Add a test to ensure that the `MediaDialog` is opened with the correct record
`resId` (to properly link files to that record) inside an html field.
task-3502797
closesodoo/odoo#138525
X-original-commit: 5184bed2efd9923c0371d5e117a7915415ceee5a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
HtmlField's Wysiwyg and website's Wyiswyg have different needs when it
comes to record info. The former has such info in the options object
received from its parent component, which is updated when the record
changes (ex: switching pages in a form view). The latter uses the
Wysiwyg with multiple editable ".o_editable" elements, and each one of
those carry such information in its dataset.
Before this commit, when the HtmlField's record changed, the MediaDialog
would fetch the record info from the editable's dataset, which was no
longer updated. This led to the creation of attachments for uploaded
images with the wrong record reference.
This commit makes sure the correct data is read from the Wysiwyg options
object instead (which contains the up-to-date record info), while making
this behaviour overridable (by website).
This commit also removes the 'res_model' and 'res_id' props passed to
the MediaDialog component, as such props are not used ('resModel' and 'resId' are
used instead).
task-3502797
X-original-commit: 5cd7145a6a182c5d9bff68b0df7d825d4d932209
Part-of: odoo/odoo#138525
Steps:
- Install `sale_management`
- Go to `Discount & Loyalty`
- Create a new one and set a name
- Change default program type from `discount` to `buy x get y`
- Remove the default rewards
- Add a new one (the default one)
- Click `Save & Close`
- Trigger save
Rewards is reset to default `discount` instead of `buy x get y`
closesodoo/odoo#138523
X-original-commit: 798c69f44bfde2f66826775a5a11fe5e51adb9a8
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This fix is only a missing of the commit 7f5a0ccf9e5fdf3f7fece8a9.
As a reminder, in 7f5a0ccf9e5fdf3f7fece8a9, we check that the content of
the dialog is markuped. If not, we escape it.
So in this commit, we add the markup to the "props.preview".
closesodoo/odoo#138494
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Generalize the hr.employee activity plan to any model, allowing to create
activity plan that can be launched on any model.
The activity can now be created in batch by selecting multiple record in the
list view and then clicking on a "clock" icon in a row similarly to the batch
records update (selecting multiple records allows to change for example their
name in batch in the list view). We implement also that functionality for the
plan, allowing to launch a plan on multiple records at once.
We also centralize the launching of activity or activity plan through either
the "Activities" button in the chatter or the "clock" button in the view list.
Scheduling activity is now taken in charge by a wizard that can schedule a
single activity as well as a plan. We add/update tests for checking that the
wizard is launched with the right record selection (on a single record or a
batch) and add tests for checking the wizard itself.
The plan can be defined through an added menu in the technical admin menu but
also through configuration menu added in the module crm, project.
Technical notes:
In the added wizard, to determine that there is a error, we introduce the
has_error field because we cannot use easily the error field for that. Indeed,
to determine that there is no error, we have to compare it to "<p><br></p>"
(more precisely <p><br></p>) which is not handy and may
change in the future. This is because when we write False on field error and
read it after, we get "<p><br></p>". Instead, we centralize this weird
comparison in the model in the compute method of has_error.
The ActivityListPopover still displays the activity of the record on which it
has been triggered but the button to schedule activity will launch a wizard
that create activities in batch for the selected records if more than one was
selected. For that, the ActivityListPopover component receives now an
additional prop: resIds (selected records) on top of the resId prop (record on
which the popup has been triggered). Note that when the line that trigger the
popup is not selected, the batch mode is disabled to avoid confusion.
We convert the custom plan implementation to use the generic one. As the
generic one can define plans for multiple model. We use the check
dedicated_to_res_model == 'hr.employee' to activate the specific feature for
hr.employee. Indeed, that field contains the model name when the plan is
applicable only for one model.
Task-3390865
closesodoo/odoo#137969
Related: odoo/upgrade#5243
Related: odoo/enterprise#48599
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
We convert the custom plan implementation to use the generic one. As the
generic one can define plans for multiple model. We use the check
dedicated_to_res_model == 'hr.employee' to activate the specific feature for
hr.employee. Indeed, that field contains the model name when the plan is
applicable only for one model.
We also remove the 'launch plan' button as we can now launch a plan directly
from the activities button in the chatter.
Technical notes:
For the activity schedule wizard, we add the support for active_ids and
active_model as default values for res_ids and res_model because it is used as
link in the chatter to launch the wizard and we want to avoid a big migration
by keeping the link identical (and there are probably no simple solution to
keep the same behavior).
HR CONTRACT
Before the first contract date of the first selected element was chosen to
determine the planned due date if all first contract date were different
otherwise the minimum was chosen. So if the selection included 2 different date
among 3, the minimum was chosen but the first if the 3 were different.
With this change, the minimum is always used to determine the default planned
due date.
Task-3390865
Part-of: odoo/odoo#137969
To keep the git history, we rename the files related to hr plan to their new
name before doing the changes in the following commit.
Task-3390865
Part-of: odoo/odoo#137969
Generalize the hr.employee activity plan to any model, allowing to create
activity plan that can be launched on any model.
The activity can now be created in batch by selecting multiple record in the
list view and then clicking on a "clock" icon in a row similarly to the batch
records update (selecting multiple records allows to change for example their
name in batch in the list view). We implement also that functionality for the
plan, allowing to launch a plan on multiple records at once.
We also centralize the launching of activity or activity plan through either
the "Activities" button in the chatter or the "clock" button in the view list.
Scheduling activity is now taken in charge by a wizard that can schedule a
single activity as well as a plan. We add/update tests for checking that the
wizard is launched with the right record selection (on a single record or a
batch) and add tests for checking the wizard itself.
The plan can be defined through an added menu in the technical admin menu but
also through configuration menu added in the module crm, project.
Technical notes:
In the added wizard, to determine that there is a error, we introduce the
has_error field because we cannot use easily the error field for that. Indeed,
to determine that there is no error, we have to compare it to "<p><br></p>"
(more precisely <p><br></p>) which is not handy and may
change in the future. This is because when we write False on field error and
read it after, we get "<p><br></p>". Instead, we centralize this weird
comparison in the model in the compute method of has_error.
The ActivityListPopover still displays the activity of the record on which it
has been triggered but the button to schedule activity will launch a wizard
that create activities in batch for the selected records if more than one was
selected. For that, the ActivityListPopover component receives now an
additional prop: resIds (selected records) on top of the resId prop (record on
which the popup has been triggered). Note that when the line that trigger the
popup is not selected, the batch mode is disabled to avoid confusion.
Test are updated because the wizard is opened instead of the activity form to
schedule a new activity and as the form view is only used to edit already
existing activities, default_res_id and default_res_model are no longer passed.
We defines date_deadline and date_plan_deadline in the schedule wizard because
those date are managed differently (default value, required or not, ...).
Task-3390865
Part-of: odoo/odoo#137969
We move the filterable widget from loyalty to web to make it more widely
accessible to other applications. It will soon be used in the new activities
plan feature.
Following the move of the filterable selection widget to the web module, we do
some light cleanup.
Task-3390865
Part-of: odoo/odoo#137969
Purpose is to make it more widely available, as it can be used in other wizards
dealing with res_ids / active_ids.
Task-3390865
Part-of: odoo/odoo#137969
This commit removes usages of jquery in database_manager and adapts the
code accordingly. Also improve the alert messages.
task-3508327
closesodoo/odoo#137670
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
To reproduce:
1. Open the shop floor
2. Open assembly station 1
Current behavior:
The MRP timer immediately causes a traceback when being rendered in the
shop floor.
After the changes in [1], the duration was changed to a property on the
timer component.
However, the duration is set on multiple occasions, including in the
onWillStart function of the timer component, resulting in the traceback.
Expected behavior:
This commit addresses this by reverting the changes from [1] for the
duration on the mrp timer, and using useRecordObserver instead of
onWillUpdateProps.
[1] https://github.com/odoo/odoo/pull/135842
Community PR: https://github.com/odoo/odoo/pull/137561closesodoo/odoo#137561
Signed-off-by: Steve Van Essche <svs@odoo.com>
This commit prevents deleting worklocations if they are used as default of an
employee. In case the worklocation is deleted, exceptions using that
worklocation are also deleted.
task-3527196
closesodoo/odoo#137502
Related: odoo/upgrade#5260
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Homeworking changes the im_status of a partner if the employee is at the office
or not. So, im_status 'online' would become 'office_online' so that we can show
different icons to highlight that a person is at the office or at home. Since
the tests in test_discuss_full expect specifically 'online', it made the tests
fail. If we make the assertion using the partner's im_status, it prevents the
test from failing while keeping its value.
task-3527196
Part-of: odoo/odoo#137502
This commit changes how hr_homeworking deals with hr.employee.homework records.
Before this, an hr.employee.homework record was created for each day of the
week, even if it was the default location of the employee. This commit reworks
how homeworking deals with them to reduce the amount of records generated.
Now default employee locations don't generate records. They are rendered in the
calendar view as ghost events. For exceptions, we allow only creating a single
exception per day. If an employee sets an exception as 'weekly', it sets that
location as the default one for the employee on that day of the week. Not
having to deal with recurrencies makes the homeworking code simpler to manage
as well. Also exceptions are, by definition, not common. So we shouldn't expect
a lot of exception records to be created.
task-3527196
Part-of: odoo/odoo#137502
The current-month filter is not needed anymore since the
when we arrive on the work entries view, the current month
is already selected by default.
task-3510499
closesodoo/odoo#137369
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit removes the resource_calendar_id field on
the public employee, as this is giving information that we
don't necessarily want to be public. Additionnaly, it led
to the possibility for every user to access calendar forms.
task-3519805
closesodoo/odoo#137211
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In HR modules we have both hr.employee and hr.employee.public models and the
issue is that if a certain user doesn't have access to read the hr.employee
record, it will throw errors/avatar pictures won't appear. For this reason,
https://github.com/odoo/odoo/pull/116828 introduced a change in many2many
employee fields so that they always show hr.employee.public records. However,
we can improve this behavior by checking if the user has access to the record.
If they have access, the private record is shown (making it easier to navigate,
edit employee information) and if they don't have access, we show the public
record. In order to allow forcing a relation, it was decided to convert all
employee fields to accept a relation parameter in the options. If this option
is set, we use that as the relation.
This commit also changes the HR views using these widgets, removing the
relation option from fields that would benefit from this dynamic check for the
most suitable relation.
task-3524305
closesodoo/odoo#136786
Related: odoo/enterprise#48008
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Previously, creating a new report for the time off summary using studio
would lead to a user error. This commit addresses the issue by ensuring
that if there is no form data, the existing data is returned.
Task-3463512
closesodoo/odoo#135978
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit consist of adaptation of the pos_self_order module to send
orders to preparation display. The main changes consist of sending the
table stand number that the client put in to the backend to be shown
in the preparation display. It also consist of moving the tracking
number from the pos_self_order module to the point_of_sale module so
that every number has a tracking number.
closesodoo/odoo#134980
Task-id: 3495477
Related: odoo/enterprise#47203
Signed-off-by: David Monnom (moda) <moda@odoo.com>
Before this commit, If user want to change color of department the only way to
do that is by clicking on three dot menu in kanban view.
In this commit, added a color picker on department's form view and list view and
make list view editable so user can change color of department from form view
and list view. so it can be used for a hierarchy view.
task-3489447
closesodoo/odoo#134964
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before these commit :
field are not editable in the tree view when we click on
the field its open the form view.
After these commit :
Now the fields are editable through the checkbox in tree view.
task-3487625
closesodoo/odoo#134132
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
1. The "unsolved", "unanswered", "answered" were not translatable.
In another language, we would have "unsolved" appear in the middle
of the "sentence"
2. The sentences were chunked. Like "There are no" and "results".
This works in English, but in another language, maybe one needs
to translate this differently from "there are no" + "unsolved" + "results'.
If the grammar of that language is "There are no" + "results" + "unsolved"
translating each chunk directly and keeping them at the same place won't
be grammatically correct, if only it makes sense.
This will also have the beneficial side effect of making them more extensible.
Additionally, fix a typo.
task-3546506
closesodoo/odoo#138461
X-original-commit: 8eae73d806aec2f3b93c576ad4573b4d74510f2a
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Florian Charlier (flch) <flch@odoo.com>
The issue #128847 broke the fix of #124802.
Wysiwyg._generateClientId must be called before `Wysiwyg.resetValue`
as `Wysiwyg.resetValue` will call `Wysiwyg.odooEditor.historyReset`
which need to have the client id set to consider the collaboration
active and serialize the node accordingly.
task-3457120
closesodoo/odoo#138442
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The field l10n_pl_delivery_date should not be visible if we're not in PL.
In fact, delivery_date should have the standard behavior in Poland
closesodoo/odoo#138440
X-original-commit: 0056dcb17e212a627a83072bafd68af8e0b2c76e
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
The goal of this commit is to cause a recalculation of specialData when
this depends on a record value.
Currently, specialData are only calculated during onWillStart and
onWillUpdateProps. But the specialData of certain fields do not depend
only on the props, they can also depend on the values present in the record.
We therefore want to recalculate them when the value of the record changes.
How to reproduce:
- Go to a form view with a field "x" and
a field with specialData dependent on field "x".
- Edit the field "x"
Before this commit:
The specialData have not changed
After this commit:
The specialData have been recalculated.
closesodoo/odoo#138372
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Sortable uses the "enter" and "leave" events to handle the move of the
placeholder in the container. When the initial drag element is cloned,
the algorithm is more simple as the placeholder takes the same size as
the original one. When we use a custom placeholder (in our case, a small
line) and the placeholder change position, it triggers an "enter" and
"leave" events in loop due to the smaller size of the placeholder.
This commit ensures the placeholder to move only one time per pointer
event move ("enter" and "leave") and avoid flickering when we move one
element on the first/last element.
Note: a better solution to avoid this complexity is to use pointer
"move" event instead of "enter" and "leave".
closesodoo/odoo#138350
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Commit 4d1a1f1c introduced a systematic check on the kwargs passed to
transaction routes of modules integrating with online payments, but
failed to check the access token of documents whose ID is passed to
payment routes. This allowed retrieving the access token of such
documents by visiting a route that did not check the document access
(e.g., /my/payment_method) and passing an arbitrary document ID
(e.g, sale_order_id=123). The route's controller would reroute the
payment flow to the document's portal page and render the landing route
of the flow on the payment form, with the access token included.
This commit makes sure that we always check the access token of a
document before reading rerouting a payment flow.
closesodoo/odoo#138238
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
We removed CSS styling for these classes in
854083f70a,
but these were only used in the survey tour, and not
instrumental, so we can remove them.
Task-3525225
closesodoo/odoo#138095
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The purpose of this commit is to resolve two issues relating to the properties field:
Issue 1:
========
In a list view, when you edit a property and then select another field
in the same record, the edition disappears.
How to resolve:
--------------
Do not delete the changes linked to the property in record.update.
How to reproduce:
----------------
- Go to a list view with a properties field containing a property char
- Insert a value in the char property
- Click on another field in the same record
Before this commit:
The inserted value disappears
After this commit:
The inserted value is still present
Issue 2:
========
The fields/activeFields only take into account properties received
during the initial web_read and not those added by an update or an onChange.
How to resolve:
--------------
Generate property fields and activeFields during parseServerValue
(web_read and onChange) and during an update.
How to reproduce:
----------------
- Go to a form view with a properties field
- Editing a field with an onChange
- The onChange returns a new property for the properties field
Before this commit:
A crash is displayed
After this commit:
The new property is displayed correctly
closesodoo/odoo#137989
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Prior to this commit, lazy-loaded bundles weren't pregenerated,
potentially causing non-deterministic test failures when the
generation process took too long. Plus, each Python test loading these
bundles necessitated their regeneration.
With this commit, the lazy-loaded bundles are now included in the
pregenerated bundles.
task-3493014
runbot-24842
closesodoo/odoo#134464
Related: odoo/enterprise#46985
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When the stock module is installed some conditions changes in the sale orders
Here's the list and the implementation made to help this
Patched the kanban_record so that the asked_qty of a product cannot go below the delivered_qty
the delivered_qty is added in the productCatalogData of the record through the _get_catalog_info() hook in the following PR:
https://github.com/odoo/odoo/pull/132341/commits
Patched the sale_order_line xml to disabled removeProduct and decreaseProduct buttons when the quantity is equal to the
delivered quantity
if the user tries to remove an already delivered product it'll set to the delivered quantity instead of 0
if the user tries to set a quantity that is below the delivered quantity it'll set it to the delivered quantity
Added action action_product_forecast_report to the menuitem of the products
Task-3343547
closesodoo/odoo#127161
Related: odoo/enterprise#43469
Related: odoo/upgrade#4887
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
*: web_editor
This warning redirects users to the code snippets block and footer/body
code injection. We want to avoid editing the XML code for no good reason
because it complicates upgrades to the next version.
task-3229205
closesodoo/odoo#117051
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
odoo/odoo#136944 removed the log from website_event_track, but despite
noting the discontinuity I missed that *a new instance of the log line
had been added in 16.1* and that is likely why 16.1 was suddently
spammed with that: website_event_track (likely) only installs its PWA
when opening an event on website, but since odoo/enterprise#35322 the
web client tries to install its PWA *every time it's loaded*, which
can be up to once per test for qunit tests (if they need a webclient).
In odoo/odoo#133560 this registration was moved from enterprise to
community, so needs to be nuked here as well.
Follows the removal of this log line in odoo/enterprise#48831.
closesodoo/odoo#138469
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
