This commit removes the last low level legacy stuff (e.g. Widget,
mixins...) from the backend bundle, and from the webclient bundles
of mrp_subcontracting and project. They are no longer used in the
backend. There're still necessary for the frontend and for the
web_editor though, so we had to manually add them in the lazy
loaded bundle of the editor. Hopefully, the last widgets and
dialogs will be converted soon, and we'll finally get rid of all
those legacy files.
Part-of: odoo/odoo#139154
The select2 library is only used in the frontend, now that the last
backend usecase (AceEditor) has been removed. This commit thus
removes the select2 library from the backend assets.
Part-of: odoo/odoo#139154
Now that the last Component using that helper have been fully
converted to Owl (AceEditorWrapper -> ResourceEditor), we can
remove it.
Part of task~3439226
Part-of: odoo/odoo#139154
This commit refactors the website AceEditor to owl. The wrapper
around the lib was defined in web_editor, and extended in website,
where it was used (single usecase). This commit thus introduces an
owl Component to replace it, directly in website, and specialized
to the website usecase.
This thus allows to remove the legacy implementation.
This also removes the last usecase of Widget and select2 library
in the backend bundle, which will allow to trim it down.
Part of task~3439226
Part-of: odoo/odoo#139154
By default, the SelectMenu component alphabetically sorts the
choices. Before this commit, this wasn't avoidable. As there's now
a usecase of SelectMenu where we want to enforce a specific order
on the choices (the website AceEditor), this commit introduces a
props `autoSort`, which is `true` by default, but which allows to
disable the sort.
Part-of: odoo/odoo#139154
This props allows to specify the initial width of the panel, whereas
before the initial width was the minimal width, i.e. the user could
only expand the panel, not shrink it.
Part-of: odoo/odoo#139154
This component has been introduced in web_studio. We have now a
similar usecase in website, for the AceEditor component. We thus
move the component definition to web.
Part-of: odoo/odoo#139154
The `beforeEditorActive` props is a function, not a boolean. So
before this commit, there was a crash in debug mode when the
WysiwygAdapter was instantiated.
Part-of: odoo/odoo#139154
In the dashboard action, when switching from dashboard to dashboard, the
size of the control panel flickers. That's because the Share button is not
displays while the dashboard is loading and it takes some place, making
the control panel taller when it's displayed.
With this commit, the Share button is always displayed (disabled when the model
isn't loaded). In addition to fix the size flickering issue, it's also less
things appearing/disappearing from the UI (less sapin de Noël)
closesodoo/odoo#138816
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
When changing the grid gaps (see commit [1]) a grid preview is displayed
in order to visualize the changes. As it cannot be displayed in mobile
view (otherwise, the layout looks broken), some code prevents it to be
added in this case. However, a case has not been taken into account:
- In desktop view, change the gaps of a grid with the "Spacing (Y, X)"
option.
- Before the preview disappears, quickly activate the mobile preview.
=> The preview is displayed (before disappearing).
This commit prevents the grid preview to be displayed in mobile view. To
do so, its height is forced to 0. Note that `display` could be set to
`none` instead but since it prevents the animation to be played, the
preview would not be removed by its listener.
[1]: https://github.com/odoo/odoo/commit/4345df3aeeb83463d81bc24749856fef3a58fb3a
task-3555898
closesodoo/odoo#138795
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Adds in date type global filters a new category
"From / To" allowing to define a domain between
two dates.
closesodoo/odoo#138507
Task: 3516362
Related: odoo/enterprise#48855
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
* = bus, crm_livechat, hr, mail_bot, test_discuss_full, test_mail,
website_livechat
Now that livechat uses guest, we can write proper ACL for channel and
channel member to check if the current user/guest is a member.
This allows removing most sudo in code and to simplify search domains.
Remaining sudo in discuss folder have been reviewed and commented.
task-3394829
closesodoo/odoo#138330
Related: odoo/upgrade#5295
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before the commit:
A traceback was generated when clicking on 'View all' tags.
Reason:
Issue from PR:- https://github.com/odoo/odoo/pull/129123. In the search box
template, the action value for 'View all' tags was incorrectly formatted,
't-valuef' was used with python expression instead of 't-value' resulting in an
erroneous URI path and causing errors.
After the commit:
The traceback has been resolved by using correct string formatting ensuring the
correct generation of the string.
Task-3525236
closesodoo/odoo#137984
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
To reproduce the issue:
1. In Settings, enable "Multi Routes"
2. In Routes, unarchive MTO
3. Create a product P:
- Storable
- With a vendor
- Routes: MTO + Buy
4. Create and confirm a SO for 10 x P
5. On the delivery, set the done quantity to 12
6. Validate the delivery
Error: The state of the delivery is set to _done_ but the SM has
changed, its demand is 2 and the done quantity is 0. Moreover, a
backorder has been created
Since [1], extra moves are supposed to be merged with the initial
one. However, there is an issue with the above case. The initial SM
has generated a POL (the product is an MTO-buy one). However, since
the extra move is an MTS one, it does not generate any POL. As a
result, the SMs don't have the same value for the field
`created_purchase_line_ids`. This is an issue because for two SM to
be merged, this field must be the same on both SM:
https://github.com/odoo/odoo/blob/ef3c21255c6f2b1172be3b1f8f0dc83bc276d806/addons/purchase_stock/models/stock_move.py#L20-L24
As a result, the SMs are not merged, the method `_create_extra_move`
only returns the extra move, the initial one is lost and it leads to
an unexpected behaviour.
We should also copy the values of `created_purchase_line_ids` to
ensure the merged of both initial and extra moves.
[1] f9867a5fa5
OPW-3504138
closesodoo/odoo#137869
Related: odoo/enterprise#48547
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
LU tax report comprises of several sections and now we can restructure report,
so that the sections are split into different tabs, using the new sections
functionality.
This also allows for reusing one of the sections of the simplified tax report
in the full annual VAT declaration, thus avoiding a lot of duplication in the
xml files.
task-3074547
closesodoo/odoo#135783
Related: odoo/upgrade#5198
Related: odoo/enterprise#47525
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
account.report.line can have shortcuts for adding basic expressions
for various engines. This commit adds such a shortcut for external engine
so that reports with lots of external expressions (manual fields) can
be added easier and can be shorter.
Part-of: odoo/odoo#135783
Impacted = base, mail, mass_mailing(_sms), test_mail_sms,
test_mass_mailing
This PR adds support to receive sms delivery reports.
Before this PR, an SMS was considered 'sent' when successfully
handled by the third party. The user couldn't know if/when an
SMS was actually sent for delivery or delivered to the
recipient's device.
This was similar to the behavior for emails as delivery reports
are not commonly used (and not supported in Odoo).
With this work, the SMS `pending` state is introduced in mail,
mass_mailing, sms and mass_mailing_sms contexts although only fully
used in the latter two modules (+tests of course).
Because of the huge cost related to upgrading very large existing
databases, the following compromises were made:
1. An email and sms notification/trace SENT means DELIVERED.
Those that are sent but NOT DELIVERED are PENDING.
The difference between email and sms traces reinforced with this PR
is that an email sent will be counted as "sent" ~ "delivered"
unless an error is returned for emails while for SMS it can only be
reached if a delivery report is received.
2. The Link between an SMS uuid (shared with trusted parties) and
the tracking records (notifications or traces) is done via an
explicit relationship table (sms_tracker) instead of via a new field.
This however allowed to nicely concentrate the state update logic.
A `process` state is added to represent an intermediate
step in the sending process, such as held at IAP for SMS.
Additionally, we propose the removal of sms foreign keys
with `mail.notifications` and `mailing.trace` records as they
are not useful in the flows and prevented us from deferring
the deletion of potentially many records with a cron job.
In the last commit, we refactor the SMS to not be a model (in env) but a
"regular" python class.
Task-2560666
closesodoo/odoo#133392
Related: odoo/enterprise#46996
Related: odoo/upgrade#5164
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Also impacts test_mail_sms.
Purpose: let a cron do delete records to end the
sending transaction sooner.
Removing the foreign key between sms_sms and mailing_trace
is necessary as traces may have to be updated due to
delivery reports.
This is why we do it here and not with notifications
because only traces will trigger updates of a possibly
massive number of records and repeated concurrent updates.
We also replace the now obsolete "sms_sms_X" prefix as there
are not many "sms_id" to distinguish from.
Task-2560666
Part-of: odoo/odoo#133392
Also impacts mass_mailing_sms, test_mail_sms,
test_mass_mailing
This PR adds support to receive sms delivery reports.
Before this PR, an SMS was considered 'sent' when successfully
handled by the third party. The user couldn't know if/when an
SMS was actually sent for delivery or delivered to the
recipient's device.
This was similar to the behavior for emails as delivery reports
are not commonly used (and not supported in Odoo).
With this work, the SMS `pending` state is introduced in mail,
mass_mailing, sms and mass_mailing_sms contexts although only fully
used in the latter two modules (+tests of course).
Because of the huge cost related to upgrading very large existing
databases, the following compromises were made:
1. An email and sms notification/trace SENT means DELIVERED.
Those that are sent but NOT DELIVERED are PENDING.
The difference between email and sms traces reinforced with this PR
is that an email sent will be counted as "sent" ~ "delivered"
unless an error is returned for emails while for SMS it can only be
reached if a delivery report is received.
2. The Link between an SMS uuid (shared with trusted parties) and
the tracking records (notifications or traces) is done via an
explicit relationship table (sms_tracker) instead of via a new field.
This however allowed to nicely concentrate the state update logic.
A `process` state is added to represent an intermediate
step in the sending process, such as held at IAP for SMS.
A few adjustments are also included to update for IAP api v3.
Also, adapts and includes new tests.
Task-2560666
Part-of: odoo/odoo#133392
Before this commit, if you had a working schedule with half days and
you took multi-day leaves, those half days would be counted as full days
so you would not use your allocated days to their full potential. The
work-around was to take these half days separately, so they would be
correctly counted as half days.
With this commit, the duration of these periods with half days included
is computed correctly. Additionally, if the leave type request unit is
'day' and the employee can therefore not take leaves with half day
precision, a warning will be displayed on the leave form view that
explains the employee is potentially losing out on their full allocated
potential.
task-3131517
closesodoo/odoo#133145
Related: odoo/upgrade#5238
Related: odoo/enterprise#46280
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, conversion between worked hours and days in
resource_calendar_attendance was calculated but in reality there is no
unambigous way to do this. Eg in Belgium the morning working period is
4 hours, the one in the afternoon is 3 hours 36 minutes, while both of
them are still counted as half days.
To mediate this, the duration in days is explicitely added to
resource.calendar.attendance, with sensible default being provided
(half a day for morning and afternoon periods, 0 for lunch).
task-3131517
Part-of: odoo/odoo#133145
Add in feature to auto-print reception (allocation) report when the
MO is done. Note that only MOs with an allocation will be printed
otherwise the form will only have the MO name/barcode and nothing
else in it (i.e. not very useful).
Part of task: 3046178 - general auto-print goal
closesodoo/odoo#126791
Related: odoo/enterprise#43362
Related: odoo/upgrade#5298
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Add in feature to auto-print reception report at validation of picking.
Note that only pickings that have an allocation will be printed
otherwise the form will only have the picking name/barcode and nothing
else in it (i.e. not very useful).
Part of task: 3046178 - general auto-print goal
Part-of: odoo/odoo#126791
Add in feature to allow auto-printing of lot/sn labels when the
`action_generate_serial` button is pushed.
Part of task: 3046178 - MRP behavior auto-printing
ENT PR: odoo/enterprise#43362
Part-of: odoo/odoo#126791
Add in feature to allow auto-printing of lot/sn labels when MO is done.
Note that this includes byproducts and does not consider the qtys done
since that is already printed as part of the product labels (which
auto-fills in their lot/SNs as their barcodes)
Part of task: 3046178 - MRP behavior auto-printing
Part-of: odoo/odoo#126791
Add in feature to allow auto-printing of reception report labels
when MO is done when there are lines assigned in the reception
report (i.e. any MTO linkages/move_dest_ids).
Part of task: 3046178 - MRP behavior auto-printing
Part-of: odoo/odoo#126791
Add in feature to allow auto-printing of Production Order report at MO
completion. Note that existing backorder view actions had to be adjusted
because lack of `views` param did not work with specialized client
action to chain actions.
Part of task: 3046178 - MRP behavior auto-printing
Part-of: odoo/odoo#126791
Steps to reproduce:
- toggle setting `mrp.group_mrp_reception_report = True`
- create a new 'mrp_operation' operation type and activate
`auto_show_reception_report` for this operation type
- create a delivery of a product (qty > 1)
- create 2 MOs for the product to deliver, one with the new operation
type and one with the built in operation type
- try to "Mark as Done" both MOs (from the list view)
Expected result:
MOs are marked as done, only 1 of the MOs shows up in the allocation
report for the delivery
Actual result:
Singleton access issue
Noticed during task: 3046178
Part-of: odoo/odoo#126791
Add in feature to allow auto-printing of product and lot labels at
picking validation.
Note that the `product.label.layout` (wizard) has a default picking
quantity value for how many labels should be printed out for each
product that makes sense for the auto-print case, whereas the
`lot.label.layout` (wizard) allows the the user to choose whether or
not to print out 1 label per lot/SN or the qty done of each lot/SN, and
both are valid options for auto-printing. Therefore the selection choices
for `product_label_format` matches it's corresponding wizard's choices
exactly, whereas the `lot_label_format` combines the `print_format` +
`label_quantity` of its corresponding wizard. Hopefully no additional
print formats are created for the lot labels...
Part of task: 3046178 - general auto-print goal
Part-of: odoo/odoo#126791
The default behavior of report_action() is to check if the currently
selected company has their document layout configured. The product
labels do NOT depend on this layout at all though, so let's make it so
the configuration never pops up when product/lot labels are being
printed.
Discovered during task: 3046178
Part-of: odoo/odoo#126791
In previous versions (v14 and earlier) there was only 1 PDF product
label that was easily customizable by users. Then we became super
fancy and created 5 PDF product label formats that are called via 2
different report actions.
Unfortunately we were too fancy and the design of the new reports was
incompatible with user customization. To remedy this, this commit:
- makes it so you can actually open the report label in studio (i.e.
`_prepare_data` in `product_label_report.py` adjusted to handle studio
case + hardcode some values that used to be required from the
`product.label.layout` wizard)
- splits out the non-dymo labels into separate report actions so they
can be individually customized more easily (i.e. individually loaded
from studio)
- splits out the show 4x12 price/no price templates so they can be
separately modified without unintentionally affecting the other
Note that we expect users to be OK with:
- the barcode auto-magic (i.e. clicking on the barcode within the label
will NOT be product.barcode as some of them may expect) since we still
want to cover the use case of SN/lots printing instead of the product
barcode for pickings
- the user will take responsibility if they overlap/delete the
`extra_html` layout wizard value from the label (since it's not
visible in studio without lots of clicking)
Task: 3046178 - split product label templates
Upgrade PR: odoo/upgrade#5298
Part-of: odoo/odoo#126791
Add in feature to allow auto-printing of reception report labels
at picking validation when there are lines assigned in the reception
report (i.e. any MTO linkages/move_dest_ids).
Note that a little fix hack was necessary for this feature (i.e.
override of ir.actions.report to ensure that the doc_ids/docs are
correctly set) since this report was originally designed to be called
ONLY from the JS + using the report link to pass the correct parameters,
which cannot be done in the same way via the standard
ir.actions.report.report_action method
Part of task: 3046178 - general auto-print goal
Part-of: odoo/odoo#126791
Add in feature to allow auto-printing of package label when "Put in
Pack" button is pushed. Note there are 2 choices for package labels and
these choices are hardcoded in as selection options to avoid complexity
of finding all relevant reports (i.e. custom report labels won't be
auto-printable) and exclude the irrelevant reports.
Unfortunately since there are different flows for "Put in Pack", a
separate "_post_put_in_pack_hook" method is needed to manually be called
in some of these cases and additional future use cases will also require
it to be called if this feature is desired in that case.
Additionally clean up _put_in_pack() since it was only called by methods
with ensure_one(), but was semi-designed to handle multiple pickings
(but only returned 1 package in the end, which didn't make sense + had
other errors in it).
Part of task: 3046178 - At package creation (put in pack)
Part-of: odoo/odoo#126791
This commit adds two linked features:
1- the ability to chain (report) actions
2- the ability to auto-print delivery report at picking validation
Because feature 2 results in the possibility of 2 actions to be returned
at picking validation (due to pre-existing auto-open reception report at
validation option), feature 1 is required to support it. It is expected
that chaining will primarily occur with report actions since chaining of
the other action types does not currently have an applicable use case.
Since this feature is only needed within stock for now, it is
encapsulated within a custom client_action for now that is a lot of copy
paste of action_service.js
This is the first commit to support a series of potential
auto-printable reports.
Part of task: 3046178 - Operation Type
ENT PR: odoo/enterprise#43362
Part-of: odoo/odoo#126791
steps to reproduce:
- activate Settings > Reception Report
- Create new storable product
- Create + confirm planned delivery of 5 of the product
- Create + confirm planned receipt of 2 of the product
- Open reception report (Allocation button) in receipt
- Assign the 2 products to the delivery
- create +confirm a new delivery with 2 products
- create + confirm a new receipt with 2 products
- Open reception report in new receipt
Expected result:
The stock.move in the original delivery will be split into 2 moves, with
Demand qtys of 2 and 3 respectively. Opening the new receipt's reception
report will allow you to assign to the remaining 2 in the original
delivery
Actual result:
Only the new delivery is displayed rather than the old delivery
Issue was due to the `reservation_date` not being copied into the newly
split move even though we would expect it to be the same (instead it is
`False` since the default reservation method for operation types is
`at_confirm` and the new move does not have `action_confirm` called on
it, so the date is never set). Since we usually don't want this date to
be copied, we only manually do it in the reception report splits.
Part-of: odoo/odoo#126791
Previous to this commit, only the return labels had a consistent prefix
for their filenames. This meant that all other shipping related
documents had their filenames manually + inconsistently created as
strings in every shipping connector. This lead to difficult to
distinguish documents across different records' chatters.
This commit adds a consistent method for the shipping connectors to use.
Part of task: 3046178 - harmonize shipping label names
ENT PR: odoo/enterprise#43362
Part-of: odoo/odoo#126791
In time off, someone can be set as a time off manager for another employee
without needing any rights on the time off app. In order to
make it so they only have access to what's needed, this commit
applies the following changes:
- addition of a new default filter "Waiting for me" in the time off
management menu, which only displays the time offs that the user needs
to approve.
- removal of the menuitem "allocations" for those managers without time off
rights since they're not allowed to modify or create any.
- addition of the employee(s) choice for the time off if that user decides to
create a new time off from the management view.
task-3329715
closesodoo/odoo#122517
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
The avatars coming from the TagsList component could not differentiate
if the `Many2ManyTagsAvatarField` was in readonly. Displaying an hover
state style when in list view.
This commit checks if the tag.onDelete is defined to render the span
containing the hover effect.
task-3514404
closesodoo/odoo#139455
X-original-commit: ac1757d96ab9ddda934b9b49ad41d83c9567e5b8
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
1. Install stock
2. Go to Inventory > Products
3. Cog wheel > Import records
4. Make a xlsx document where:
5. the first sheet has at least 2400 records (with header)
6. the second sheet only one record (with header)
7. Upload the document
8. Select the second sheet
9. Set batch limit at 2000
10. Click on import
11. 2 records successfully imported
Cause of the issue:
When initially uploaded, this.state.fileLength
is set to the length of the first sheet
And isn't refreshed when changing sheet
opw-3507544
closesodoo/odoo#139470
X-original-commit: 27f0a0253bc9b44854e5d6436d6e550429cdb93c
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Signed-off-by: Antoine Demany (ande) <ande@odoo.com>
In commit `2495bfa7259dcbd482b10c95a55313f86d594fcb` we introduce a fix
to adapt the kanban_card border using the border bottom of the prior
kanban_card as a border top allowing to display the outline effect.
This fix works for o_kanban_grouped but breaks the border in views that
are o_kanban_ungrouped. This commit fixes this by removing the
border-top only in the o_kanban_record that are o_kanban_grouped.
The :not(o_dragged) has been added as well to bring back the border when
the element is dragged.
task-3488451
closesodoo/odoo#139453
X-original-commit: 2be67ee122546273d12710c1c9bc3b7e11533b5d
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Currently the Send & Print wizard is stored as regular model
and not a TransientModel.
This cause multiple problems including concurrency ones.
This PR switches the wizard back to a regular transient one.
We instead store the values of the wizard that needs to be
processed asynchronously in the related move.
closesodoo/odoo#139311
Task-id: 3415101
Related: odoo/enterprise#49310
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Some layout change of res_config_settings_views.xml to make it more
readable.
Now, important parameters are on the top of the page.
closesodoo/odoo#139287
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Previously, QR codes could only be obtained by printing an A4 page.
The problem The problem was that some customers would want to create a
specific design and get the raw image of the QR code directly.
A button has now been added to the settings to download a zip file
containing all the QR codes in PNG format.
---
A change has been made to the restaurant table form to enable editing of
the access ID. editing of the access ID. This is useful if a customer
has reset his QR codes and wishes to put them back.
---
Previously, the "close" button in the table selection popup didn't work.
This has been corrected with this PR.
---
Small design change to the display of products that don't have an image
in the selfOrder.
Part-of: odoo/odoo#139287
Issue:
-------------------
In the lead forward mail template, there are some broken links, when we click on those links they are appended to the current url and redirect to a non-expected page.
Steps to reproduce:
-------------------
1. Go to CRM -> Create a new opportunity
2. Click on this new opportunity -> Assigned Partner
3. Select an assigned partner and click “Send Email”
4. Go to Settings -> Technical -> Emails
5. When clicking on “Partner Portal” it redirects to a non-existing page
Cause:
-------------------
The issue is happening because the urls are badly formatted and not using the correct tags
OPW-3074049
closesodoo/odoo#139267
X-original-commit: 55cd29c5f2cb7787752d77103dbcc4c4007ff504
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Current behaviour:
When making a xmlrpc call without fields using:
models.execute_kw(
db,
uid,
password,
'account.move',
'search_read',
[[['name', '=', "INV/2023/00001"]]])
the client receives a traceback ending with:
TypeError: cannot marshal<class \'odoo.api.res.partner\'> objects\n'>
Steps to reproduce:
1. install any of the l10n_de_... modules
2. Make a xmlrpc call like stated above
3. Traceback like stated above
Cause of the issue:
The field l10n_de_addresses is used to store
(_("Invoicing Address:"), record.partner_id)
Which isn't serialized correctly:
record.partner_id is not repr
(is python object instead of (6, 'something'))
Fix:
Applied a fix similar to https://github.com/odoo/odoo/commit/602b3f3d39db29fbcd90e3f734bdcc73e67f175d
opw-3248887
closesodoo/odoo#139095
X-original-commit: 46adfb32567ac364b5f3916f50ad47af4142163b
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Antoine Demany (ande) <ande@odoo.com>
Co-authored-by: Julien Castiaux <juc@odoo.com>
Aaron Bohy