This adds an option to log information in prepareUpdate flows for
convenient debugging.
X-original-commit: 3ec104d57e9b6bbe210f45354f160d982a9c6254
Part-of: odoo/odoo#138549
This adds a label to the prepareUpdate function to be able to easily
track which update is being restored when debugging.
X-original-commit: 5bb8a5a9b5d54ebe93c473087981e3464cd61368
Part-of: odoo/odoo#138549
When pressing delete on "[a] b c" the result is " b c" instead of
" b c". As result, text is rendered as "[]b c". The cause lies in
`deleteRange`: it ensures trailing spaces remains visible, but does not
take care of eventual invisible leading spaces. This adapts it to make
use of `prepareUpdate` which is made to handle this sort of issues. In
so doing we need to adapt `getState` and `prepareUpdate` to handle the
special cases brought by `deleteRange`. An option is introduced in
`prepareUpdate` to prevent its reentry until the update is complete (as
otherwise we may restore invalid intermediary states in the middle of
the deletion process).
task-3143042
X-original-commit: 8fd69afa591d11afe07da803ec550f052402713f
Part-of: odoo/odoo#138549
Preparations for the rework of the Knowledge `/file` command (see [enterprise PR])
- Extract basic props needed by the `FileViewer` for `files` instances in a
reusable `Mixin`.
- Allow providing a custom `MediaDialog` class through `openMediaDialog` to
allow Knowledge custom behaviors.
- Export the rendering part of `save` for the `MediaDialog` so it can be
overridden.
[enterprise PR]: https://github.com/odoo/enterprise/pull/43488
task-3172056
closesodoo/odoo#127021
Related: odoo/enterprise#43488
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Allow providing a custom `MediaDialog` class through `openMediaDialog` to
allow Knowledge custom behaviors.
- Export the rendering part of `save` for the `MediaDialog` so it can be
overridden.
task-3172056
Part-of: odoo/odoo#127021
We remove the is_paid field and based the logic on the payment_status
as these two fields are a bit redundant. It is also in preparation
to the removal of the field auto_confirm on the event.event model.
The goal is to ease and simplify the management of registrations.
Remove autoconfirm logic and simplify the flow of event registrations. Now a
registration is by default considered as confirmed and the draft state is
not used anymore by default. It is used in combination with sales before
a registration is considered as paid. It allows to avoid blocking seats
in an event while registration fees are not paid.
task-3061849
closesodoo/odoo#126431
Related: odoo/upgrade#4836
Related: odoo/enterprise#47982
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Following the removal of the auto_confirm field on event
and the payment_status computation, we improve the design
and flow of the event module.
- Adapt and simplify the kanban view for event
- Add the payment_status on graph view
- Improve the payment_status field in registration views (banners)
- Fallback on the registration page if there is not enough seats
after filling the registrations info with an error message.
task-3061849
Part-of: odoo/odoo#126431
Remove autoconfirm logic and simplify the flow of event
registrations. Now a registration is by default considered
as confirmed.
The draft state is kept for registrations with
a payment pending.
These registrations are no longer counted
as expected attendees for the seats computation.
To match the behavior of events, we also add a seats_expected
computed field on event tickets.
The registration status is now based on the sale order state.
So the payment_status field is renamed sale_status.
We consider now that a registration linked to a SO in a sale
state should be confirmed and reserved.
A sale order is in the `sale` state when manually confirmed
or when the transactions done match the amount_total of the
sale order.
We also rename the seats_expected field into seats_taken to
better match the process. It was a bit weird to have expected
in the name when the registration attended were counted into it.
UPG PR: odoo/upgrade#4836
task-3061849
Part-of: odoo/odoo#126431
We remove the is_paid field and based the logic on the payment_status
as these two fields are a bit redundant. It is also in preparation
to the removal of the field auto_confirm on the event.event model.
The goal is to ease and simplify the management of registrations.
UPG PR: odoo/upgrade#4836
task-3061849
Part-of: odoo/odoo#126431
Steps to reproduce:
-------------------
- create a project;
- set project visibility of project as
'Invited portal users and all internal users (public)';
- share that project with a portal user;
- create a task in that project and set one of user in 'Assignee' of the task;
- login in website as that portal user;
- from kanban view of task, open a task.
Issue:
------
The 'Assignees' are not visible in the opened form view.
The `portal_user_name` field will be empty, with the result
that no assignees to the task will be displayed in the project task form view.
Cause:
------
In the business flow, we first perform a `read` (with portal rights)
which will set the value:
`project.task.user_ids: {project_id: ()}` in the cache.
After, we try to get `user_ids` inside the `_compute_portal_user_names` method.
The `insert_missing` method of the cache does not overwrite existing values in cache.
Note:
fetch method uses `_determine_fields_to_fetch` with
parameter `ignore_when_in_cache` equal to `True`.
Solution:
---------
It is necessary to invalidate the cache for this field for the recordset
to make sure the value is updated.
opw-3536187
closesodoo/odoo#138557
X-original-commit: e533daf44c7946fae1e4467e70f9363f675dad07
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
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>
Antoine Guenet