Before this commit:
When we click on 'send' and 'log,' the left border disappears for
a short while.
After this commit:
The left border on the 'send' and 'log' buttons is visible even after
clicking on them.
task-3549138
closesodoo/odoo#138513
X-original-commit: ec42f19ad2996f1c471ea520ce0211f4d9e2ab0a
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit replaces the RecordsSelector component by the MultiRecordSelector
component in the global filters of the spreadsheet and the spreadsheet
dashboard. Thus, the RecordsSelector component is not used anymore and
can be removed.
Part of task-id 3433922
closesodoo/odoo#138464
Related: odoo/enterprise#48857
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Currently, the newly created component `MultiRecordSelector` (https://github.com/odoo/odoo/commit/bd0f2c6d799961b0a41222652eae7214c01dc5fe)
does not support the keyboard navigation between its tags (selecting or
deleting a tag). This behavior is currently implemented in the
`Many2ManyTagsField` component. This commit extract this behavior from
the `Many2ManyTagsField` component into a new hook that will be used by
the `MultiRecordSelector` component.
Part of task-id 3433922
Part-of: odoo/odoo#138464
permissions) edit information at /my/account
Issue:
Internal user cannot edit their information (email, street,...) at
portal without permissions in the accounting
Analyze:
Because the method `can_edit_vat` has a search from the account.move
model, it causes an error
Fix:
Use sudo to avoid error when searching
closesodoo/odoo#138291
X-original-commit: eb9505375483d18cf21fbaf8e5a60398d5c041c5
Signed-off-by: Laurent Smet (las) <las@odoo.com>
- Remove "channel" field in thread formatter.
- Pass `type` for all persona formatters.
- Remove some snake_case to camelCase conversions.
- Add support for inverse fields in discuss JS models.
Details:
1. [REF] mail: remove field 'channel' in thread formatter
This field was used for channel-specific fields, which made
sense when there was a dedicated Channel model that was modeled
with composition with Thread.
To simplify formatter of threads, it's best to flatten props
so that channel-specific fields are immediately available on
thread model. This will improve insertion of data with Threads.
This commit also makes the following other changes:
- remove `discuss.channel/legacy_insert` to use
`mail.record/insert` instead.
- Introduce `toData()` on record, which is helpful to have record
in data format e.g. to pass as a JSON.stringifiable object.
2. [REF] mail: slightly simplify Message.insert from notif
The handling of `mail.record/insert` for Message was handling
transition from starred non-empty message to starred empty message.
To simplify all record insert from server formatted data, the notif
data is just inserted in Message. The adjustment of starred counter
is managed at model level.
This is a prerequisite to significantly simplify all
`mail.record/insert` handling.
3. [REF] mail: rename 'res.users.settings' notifications
Before this commit, notifications related to changes of user
settings were using named notification `mail.record/insert`.
This named notification should be only used for Discuss data that
should be inserted in models. `res.users.settings` is not integrated
in Discuss model, thus it has no reason to use this named
notification.
This commit rename the notification name to `res.users.settings` for
these specific notifications. This prepares simplification on
handling any `mail.record/insert` notifications that should simply
call `Record.insert()`
4. [REF] mail: make dedicate notif for Thread/fold_state
This was using named notif "mail.record/insert", which should
be used to immediately insert data in models. This is however
a dedicated notification to imperatively manager chat window
state based on timing of receiving thread data.
This may eventually become a `mail.record/insert` in the future,
but right now it's much simpler to define it as its own named
notification, in preparation to simplify `mail.record/insert`
notifications handling.
5. [REF] mail: remove Channel in mail.record/insert
This is replaced by `Thread`, so that these data can be
immediately inserted in Thread model.
6. [REF] mail: simplify slightly Attachment.update()
Now that data containing commands is supported, we could
just assign with the command rather than destructure and pick
the dict data part.
7. [REF] mail: introduce assignIn() utils
This function helps reduce LOCs from using the "in" conditional
in sequence:
```js
if (a in data) {
this[a] = data[a];
}
if (b in data) {
this[b] = data[b];
}
if (c in data) {
this[c] = data[c];
}
```
To simply:
```js
assignIn(this, data, [a, b, c]);
```
8. [REF] mail: remove snake_case to camelCase conversion in models
They exist for the sake of keeping Python code snake_case and
JS camelCase. While it's good that each language have a community
that prefer syntax convention, when a codebase uses both languages
and they should work with the same data, it's not great to convert
snake_case to camelCase and vice-versa all the time.
Since server has authority over the data, the server chooses the
format for the keys. Most of them are snake_cased, therefore this
is usually the one we pick.
9. [REF] mail: rename Message.messageReactionGroups to Message.reactions
Easier to read, and matches relation name in JS model
10. [REF] mail: remove explicit assign of some many relations in Message
This reduce amount of custom code in insert(), in preparation to make
all models behave the same in response to inserting data.
11. [REF] mail: rename Thread.customName to Thread.channel_custom_name
To match server data field name, and avoid useless conversion in JS.
12. [REF] mail: simplify Message.insert for recipients
Have formatted data contain `type: "partner"` so it can be assigned
in relational field without adding `type: "partner"` manually in JS.
13. [REF] mail: introduce inverse field in discuss models
With this commit, fields in different models can be linked
together, so that one is mirror of the other field.
This simplifies some `onAdd`/`onDelete` that were added to
sync such fields, and this also simplifies insertion in
relational fields for discuss models that are identified
by records, such as the `MessageReactions` that is identified
by the message and the emoji.
14. [REF] mail: rename CannedResponse.name to 'source'
To make JS model and server data more alike.
15. [REF] mail: remove assignDefined in Persona model
So that eventually all model inserts use `Object.assign()`.
16. [REF] mail: remove 'last_message_id' from channel_info
At some point it was used to display last message in messaging menu.
This is already covered by `channel_fetch_preview` when opening the
messaging menu for the 1st time, so passing `last_message_id` in
channel_info is obsolete.
closesodoo/odoo#137750
Related: odoo/enterprise#48484
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Changed _onChangeCountry and _changeCountry from
website_sale.js to make them inheritable by
returning the value of the promise instead of
returning nothing.
closesodoo/odoo#137480
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, In time off if we got to dashboard and open list view then
information related to employee is missing.
In this commit,
we have added invisible employee, department, time-off type
in my time menu of the list view
task-3482508
closesodoo/odoo#134453
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When l10n_dk is installed, the tests on the peppol fields (EAS/Endpoint)
fail. This is due to the `_compute_company_registry` being overriden,
which will assign the VAT number as the company_registry.
To fix this, we simply use another country that currently hasn't any
loca module in Odoo (so we ensure the VAT/company_registry will not be
affected in any unexpected way).
Linked to runbot error 25700.
closesodoo/odoo#138588
X-original-commit: 64559fe8df9f32bd41b7e79ca501b9d1363378c5
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Before this commit, there was a huge gap between Uom and duration in time off
wizard.
In this commit, moved the Uom closer to duration.
task-3482508
closesodoo/odoo#138571
X-original-commit: 56b9243bc583b5f9b681b7c34355b505d892e313
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit https://github.com/odoo/odoo/commit/a9980477048e4adffda4a71a72ff1cc8490637f9 wrongly impeached to generate a SEPA QR-code on the invoice when l10n_ch was installed and the company and customer were in Switzerland. This was too restrictive, and broke the previous behavior, which allowed manually enabling the SEPA QR invoice by invoice if necessary. We restore the old behavior with this commit.
OPW 3516380
closesodoo/odoo#138395
X-original-commit: d5fe06d75369716925ff65cf3f34928e890fc932
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
This commit removes all the legacy envs (common_env, env, public_env)
as well as the files used to set up them.
task 3439226
closesodoo/odoo#138348
Related: odoo/enterprise#48781
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
State code is shown instead of state name
in company details for Thailand companies.
opw-3493307
closesodoo/odoo#138576
X-original-commit: 6a47980364e4ceeb5a77b4f7e2f2a9475872275e
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
The `insert` command was splitting the selection's starting text node
only if the selection was collapsed. But after deleting the range, the
selection is inevitably collapsed and therefore the same should be done.
closesodoo/odoo#138549
X-original-commit: 06a375db7e6250b388d410010a3d1c50e8af1326
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Test HTML being inserted for the utils tests was not cleaned at the end
of the tests.
X-original-commit: 092cee52b343665ea3ca90e4f4aa302318a763b5
Part-of: odoo/odoo#138549
This adds a few tests for `getState`, `restoreState` and
`enforceWhitespace`, regarding the handling of space visibility. Each
test handles equivalent cases for all three functions.
X-original-commit: 2f28f42640a7322eec35a4d48a1ec7ce287b77b3
Part-of: odoo/odoo#138549
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
maad-odoo