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>
This commit makes the arrow of `.css_attribute_select` fields in the
product configurator modal match the color of the text of the input.
This ensures that the arrow is always visible with any background color
task-3559424
closesodoo/odoo#139051
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit:
Fixes margin issues between buttons and inputs inproducts_header.
We are now using a gap instead of individual margin per element
Fixes an issue in the left filters where input's were cropped
when focused. We fixed this issue by using paddings and negative
margins to compensate.
task-3559384
part-of-3097005
closesodoo/odoo#139043
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
We used to have two libraries (Bootstrap and jQueryUI) providing
tooltips.
Since the removal of the jQueryUI implementation in commit [1], adding a
image-like block in the wysiwyg editor throws an error telling that
`$().tooltip()` is not a function.
Actually, this issue happens when the wysiwyg editor is used in an
iframe and the jQuery instance used is the one from the iframe.
In a nutshell, Bootstrap 5 - even though it doesn't require jQuery
anymore - has a compatibility layer which bind the current components'
implementation to the v4-like jQuery based methods (in this case
`$().tooltip()`). In the tooltip's case, both libraries have the same
method signature.
When removing the jQueryUI implementation, most of the calls to this
method naturally fallback to the Bootstrap's one... But not in our case,
as the wysiwyg editor uses its own window/frame's jQuery and not the
parent one (in the iframe's case).
Amusingly, the way Bootstrap bind its compatibility layer relies on the
`onDOMContentReady` event being dispatched... which is not the case in
the iframe, resulting to having a jQuery version without the said
compatibility layer.
This commit fixes it by removing this dependence on an external library
and use our own (existing) Tooltip component instead.
Steps to reproduce:
- Open Email Marketing app
- Create a new mailing
- Choose a template
- Drag&drop an image-like block
- Click on the newly inserted block
=> Error about $target.tooltip not being a function
[1]: odoo/odoo@25d0783b59closesodoo/odoo#138847
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit reworks and simplifies the `getIFrame()` method in the
following way : instead of trying to find/guess the targetted element
ancestor's document and then looking in this parent for the iframe
containing the targetted element, it now uses the popperEl as parent for
the iframes who may contain the targetted element.
In practice, the only caveats is that it won't support multiple nested
iframes (which we shouldn't use anyway in our codebase).
Part-of: odoo/odoo#138847
As a step to simplify model insert from python. All data are
formatted in a way to make data insert trivial in JS models.
closesodoo/odoo#138760
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
- `__invs__`/`RecordInverses` have been renamed to
`__uses__`/`RecordUses`, so that it's more clearly separated
from inverse fields. While they are some overlap in concepts,
they require different datastructures so it's best to keep
different implementations for the time being.
- `list.__addInverse__(r)`/`list.__deleteInverse__(r)` have been
replaced to `r.__uses__.add(list)`/`r.__uses__.delete(list)`.
Again change of wording "inverse" to "uses" like before, but
also it feels more natural for uses as low-level concept to
expose function on object where the uses are tracked, i.e. on
the record, rather than functions in RecordList like before.
- Remove useless `__` prefix/suffix and/or only keep `_` prefix
for `store` and `__addNoInv`/`__deleteNoInv`, for improved
code readability
- Renamed `__list__` and `__map__` datastructures to `data`,
again for improved code readability.
- Replaced some `Map<>` to `Object<>`, so that accessors are
easier to read in code with `[]` rather than `.set()`/`.get()`,
especially with code formatter that produces more LOCs than
necessary with the latter. Note that the affected dict,
`__computes__` and `__rels__` are set up at model and record
setup, so they do not change shape after that, so using Object
should not be a performance issue.
Part-of: odoo/odoo#138760
Some test coverage on model with inverses, especially on deletion
that are not frequently functionally covered by tests.
To make test coverage on very specific on models and relational
fields with inverses, store service has been refactored so we can
test the store without Persona/Thread/Message models and all related
services and behaviours.
Part-of: odoo/odoo#138760
Name was hard to grasp what it means, when in practice it refers to
showing discuss failures in messaging menu. The "group" part just
refers to a failure being conceptually uniquely defined so that it
sometimes group notifications together as a single failure entry
in the messaging menu.
This rename will help simplifying insert flow with this model.
[REF] mail: slightly simplify Notification.insert()
Format `persona` so it can be immediately inserted in JS model.
[REF] mail: simply Notification/Failure.insert
[REF] mail: introduce computed fields on discuss models
Some models have no concept in server, so the formatted data require
specific handling to make some client-side specific models. This is
notably the case with `Failure` model, which is used to group
failure notifications per model for the specific showing in UI.
In order to simplify update so they consists to simply adding data
from server, these models should be inserted automatically depending
on changes from inserted data. Since these models come from
relational fields that must be computed outside of server data, we
add support to computed fields: such relational fields can have their
value automatically computed based on the state of the current
record.
[REF] mail: remove Record.atomically and Record.onChange
These were added to reactive seeing intermediate state in models,
which were caused by `RecordList.sort()`.
This commit removes them and adapt specifically `RecordList.sort()`
so intermediate states during sort is not exposed in the actual
value of the many field.
Part-of: odoo/odoo#138760
Most tests that need the user id simply use `uid=7`, which will fail
if the default user id ever change in the tests. This commit replaces
it by `sessuin.user_context.uid`.
closesodoo/odoo#138733
Task: 3553122
Related: odoo/enterprise#48965
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Re-inserting a pivot that had a contextual domain would fail because
the data source would try to fetch the data with the domain as a string,
but the domain should be a list at this point.
Task: 3553122
Part-of: odoo/odoo#138733
In this PR we've revamped the calendar module as well as the calendar view for it to look cleaner. We also took the opportunity to add onboarding steps for the calendar app to make the configuration for integration with third-party calendar services more intuitive. On top of that, some general changes to the calendar views were made, allowing scales and sidebar state to be saved in the session storage, so that the user always lands in a familiar mode of the calendar. For the calendar module, a lot of changes were done in the UI of the calendar event form view to make it more intuitive.
Enterprise PR: https://github.com/odoo/enterprise/pull/48941
task-3455051
task-3389317
closesodoo/odoo#138670
Related: odoo/enterprise#48941
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Co-authored-by: Leonardo (lpr) <lpr@odoo.com>
This commit fixes breaking calendar view tests after the revamp done in
task-3455051 and task-3389317.
task-3455051
task-3389317
Part-of: odoo/odoo#138670
This commit adds the feature of saving the calendar state in the user’s
session storage. This allows the user to refresh the page and the sidebar will
be hidden/shown depending on what is saved in the session storage.
task-3455051
task-3389317
Part-of: odoo/odoo#138670
Currently the popover service is closed when you click away from the popover.
However, it’s not expected that the click event that closes the popover,
triggers another click event. This was causing a frustrating issue in calendar
where you would close the popover by clicking on the calendar, and it would
open the “new event” form view. The solution is to prevent default when
closing the popover.
task-3455051
task-3389317
Part-of: odoo/odoo#138670
This commit adds date information in the calendar header depending on the
scale that is being rendered. E.g. in yearly view, we show the year; in
monthly view, we show the month and year; in weekly view, we show the month,
the year and the week number; in daily view we show the day, the month and the
year.
task-3455051
task-3389317
Part-of: odoo/odoo#138670
The attendee tags list which is used in the calendar event's popups
needed adapting because the backdrop was being cropped.
Also, in the popups, these tags aren't clickable but seemed to be so
with the backdrop appearing on `:hover`.
task-3389317
Part-of: odoo/odoo#138670
The attendance dropdown is a switch button and "Needs Action" is no
longer visible on the popover (instead none of the buttons are selected)
The popovers are larger and the icons aligned. Their headers are the
color of their event.
The year view's event links inside the popovers have the same styling
as their event in the calendar.
task-3389317
Part-of: odoo/odoo#138670
We replaced the customized checkboxes with the original input element
with `.form-check-input` whilst still using the custom colors for more
consistency accross modules.
Avatars have the .o_avatar class added to them which allows us to resize
them with the CSS variable.
And SCSS has been replaced with utility classes where possible.
This commit has been moved here from
PR https://github.com/odoo/odoo/pull/127532
task-3389317
Part-of: odoo/odoo#138670
What's new:
- The overall style is softer, the borders lighter
- The event's colors are less bright
- In month view: The AllDay events and multiple day events are block
colors while the events with start/end times on a single day have a
colored circle.
- A header hosts the date title and navigation buttons (which were in
the sidebar)
- The sidebar is narrower and collapses
We've fixed the height issues giving us double scrollbars in some views.
The sidebar, when long, was pushing the content beyond the frame giving
us extra scrollbars. This has been fixed with a CSS grid and
`overflow-y` on the proper elements.
task-3389317
Part-of: odoo/odoo#138670
Events for time-off created with robodoo (demo data) wouldn’t invite the
partner related to a time off event as that partner didn’t have an user
counterpart. However, since he is an employee, he has a partner and can be
added to the event. This commit changes the check to fallback to the employee
partner if the user does not exist.
task-3455051
task-3389317
Part-of: odoo/odoo#138670
Currently in time off, we show the year view of calendar with the configuration
that shows the week number beside each week row. However, it starts as week 52.
This is a bug in fullcalendar that should be fixed by setting the option
firstDay as 0, according to this issue
https://github.com/fullcalendar/fullcalendar/issues/7026.
task-3455051
Part-of: odoo/odoo#138670
Currently, when showing the attendees of an event, we show a border to
highlight the response of that attendee in the event. However, the border is
quite small and difficult to see if the avatars are small. This commit changes
this so that we show badges instead of borders in the attendees.
task-3455051
task-3389317
Part-of: odoo/odoo#138670
In some modules at Odoo we want to have custom headers for calendar. Since
fullcalendar accepts a function callback that should render the header, it was
decided to have this method exist in the calendar_common_renderer. So any
other apps that want to add something to the header, can just extend this
method. This commit also changes how homeworking changes the header so that it
complies with this change.
task-3455051
task-3389317
Part-of: odoo/odoo#138670
In google calendar, events in the past are shown with a reduced opacity. This
makes it easier to differentiate which events are past or not. This commit
implements the same feature.
task-3455051
task-3389317
Part-of: odoo/odoo#138670
This commit fixes some google_calendar tests as they use keys that don’t exist
in the google calendar API. In google calendar, we don’t receive a status, but
a responseStatus.
task-3455051
task-3389317
Part-of: odoo/odoo#138670
Tiffany Chang (tic)