Purpose of this commit is to add potential groups but de-activate them by
default. Indeed each group require about 20 queries for rendering and
sending. If no specific behavior (access button, content) is made for this
recipient group it can be included in lower-version of the group.
Specifications
* de-activate portal group in mail as it has no additional rights compared
to customers;
* add follower group but de-activate it for the same reason;
* activate portal group in portal_mixin and include links to the record in
notification emails, using standard mail/view link. ACLs are managed in
each specific model, generally based on followers;
Update a test in test_mail as it was playing with public and portal users
that are now not really differentiated when sending notification emails.
Better have more real-life scenarios with portal and internal users.
Task-2739294 (Mail: Batch recipients fetch and improve its usage)
Part-of: odoo/odoo#82167
Purpose of this commit is to improve notification recipients computation.
Code cleaning
* make it batch enabled. Currently it works only for a single record. It
should evolve towards real multi computation, allowing to prepare post
and notification in batch;
* better manage multi users. Now when several users are linked to the same
partner, we try to find an internal user or fallback on share user. This
is cleaned compared to a distinct done previously;
* support recipients without subtype (pids + records) as a new case to
include follower computation;
Improvements
* include follower status if linked to records (is_follower can be used
notably in link computation to redirect to the portal);
* fetch partner lang directly in the SQL query. While fetching partner data
let us add its lang. That way it will be easier to improve lang support
in layouts;
Task-2739294 (Mail: Batch recipients fetch and improve its usage)
Part-of: odoo/odoo#82167
Add a constraint directly at db level ensuring no duplicated notification
exist on partner / message pair, if partner is set. Partner can be void notably
with SMS notification process which may target numbers directly.
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
Purpose is to have a white background like templates used in SO, invoices, ...
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
Purpose is to remove custom styling and use the 'Pay Now' notification layout.
Extra table is removed from template body (table with order name, 'sent by'
footer, ...) and only main content is kept. Some extra padding is removed.
Action now uses the 'Pay Now' email layout to add the access button, company
logo, footer, ... meaning it is now more standard.
An override of recipient groups and access button is also performed in order
to align header with email purpose. Link redirects to the /cart page (instead
of classic portal SO view for customers) and is labelled as 'Resume order'
(instead of 'Validate and Pay Order' used in portal).
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
* = sale, purchase
PURPOSE
Purpose of this commit is to improve the 'Pay Now' notification template
used notably when using the "Send by email" button on
* invoices
* sale orders
* RFQ and purchase orders
SPECIFICATIONS
Global specifications
* remove gray background that is around the white content (aka have an
email with an uniform white background);
* move button on top of email like other notification templates (top-left
and company logo is top-right);
* fix various small wording issues;
* fix signature usage;
Technical specifications
Remove custom definition of access links and labels in 'Pay Now' notification
template (``mail_notification_paynow``). It is now done at model level through
the ``_notify_get_groups`` that is generic to notification emails. This allows
to remove QWeb override in purchase and sale notably. Displaying access links
is now controller by the ``has_button_access`` value. Model computes links,
access and labels while view only displays what is requested. That way any
template can use those values instead of being defined in a template subject
to user changes.
Sale / Purchase
Overrides of those modules is not necessary anymore since button labelling
and URLs are managed at model level.
Purchase "specific" buttons for Accept / Update dates are now email layout
actions, like used in other modules like HR or Project.
Continuation of odoo/odoo#76418 .
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
This field is a duplicate of email_layout_xmlid and is actually never used.
Followup of odoo/odoo#76418 .
Task-2732660 (Mail: Remove duplicate layout field on composer)
Part-of: odoo/odoo#82167
* = account, purchase, sale
Purpose of this commit is to add signature only if really asked. A variable
is available for that purpose (``email_add_signature``, recently renamed from
``add_sign``). We also correctly check signature is not void or pseudo-void
using tool ``is_html_empty``. Indeed editor may generates pseudo-void content
like ``<p><br /></p>``.
As signature is not added when a template is used (see composer code) we ensure
it is defined in mail templates used in "Send by email" flows. Indeed we cannot
know if a template already has a signature or not. To avoid having twice a
signature no signature is added in email notification layout when a template
is involved.
Continuation of odoo/odoo#76418 .
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
In order to make fields a bit more explicit, let us rename "add_sign" to
"email_add_signature". It indicates it is linked to the email notification
process, adding the signature depending on the notification layout itself.
This is done on both mail.message and mail.compose.message models. It is
also updated as rendering value parameter used in notification emails.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
Purpose of this commit is to make ``get_access_action`` private as it is not
necessary to expose it directly. Website management is also made explicit
using a ``force_website`` parameter instead of relying on context key of the
same name. This allows to better understand the method code flow.
Contains also some code fix / improvements :
* Website forum: update code to better skip the frontend redirection if the
forum is not active and frontend is not forced;
* Website slides: respect force website parameter in redirection;
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
A method that actually runs on recordsets should not have a model decorator.
Even if there is no issue this is may be confusing.
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
Purpose is to support portal parameters in ``_notify_get_action_link``. This
method generates a ``mail/view`` link that may redirect to frontend e.g. with
portal. We already support parameters coming from auth_signup and tokens from
portal. Supporting pid / hash allowing to post on documents using the frontend
chatter is the next step to generic links. This is just adding them to the
accepted like, not changing any current behavior.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
If we call ``MailFollowers._get_recipient_data()`` with pids parameter being
set to None there is a crash that is easily solved( list(None), should take
list fallback before hand).
Task-2739294 (Mail: Batch recipients fetch and improve its usage)
Part-of: odoo/odoo#82167
Purpose of this commit is to add tests for recipients fetch. Purpose is to
assess current behavior before going into some cleaning or refactoring.
Notably when dealing with
* forced recipients (pids, aka 'additional recipients' in composers);
* subtype-based computation (internal, subtype follower);
* multi-users per partner (notably as a result of partner merge);
Future improvements will modify this method. Adding some low level tests
for it will ease development and checking differences.
Some tests are also regrouped in the same test class to lessen noise.
Task-2739294 (Mail: Batch recipients fetch and improve its usage)
Part-of: odoo/odoo#82167
Purpose of this commit is to add tests for language-based tweaks of email
notification layouts and composer usage. Purpose is to assess current
behavior before going into some cleaning or refactoring. Notably
* check layout content is translated;
* check "view document" button is translated;
* check action buttons are translated;
* check content based on templates is translated;
This is currently mainly available through the "lang" context key being
correctly set. Partial support of translations when posting based on template
is tested (content and model description but not notification layout).
Failing support in mass mail mode is tested. Future improvements will be
done in order to improve language support.
Note that ``MailTemplate.send_mail()`` email sending method language support
is tested in ``test_mail_template`` file. Those tests are updated to share
a common base with new tests about language setup.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
PURPOSE
Purpose of this commit is to cleanup flow of values going through message_post
and its sub methods until email generation for notifications.
SPECIFICATIONS
Ensure some values are given directly when creating message linked to post
methods to avoid browsing message when value is not known. Notably make
signature propagation (add_sign) more explicit in message_post and its sub
methods (notify, log, ...).
Prepare future language related improvements by allowing to force company and
lang values for rendering context. Also add ``is_html_empty`` tool method to
use it in notification templates. It will be used notably to check for empty
html blocks, e.g. user signature.
Rename some internal variables to better understand their purpose.
Finally update some outdated and/or badly indented docstrings.
Task-2726501 (Mail: Propagate message values in post methods)
Part-of: odoo/odoo#82167
PURPOSE
Purpose of this commit is to clean notification email values generation
while keeping possibility to override and tweak values. It now has clean
hooks on base mail value and final mail values.
SPECIFICATIONS
Base mail value are values independent from recipients. It allows notably
to tweak values depending on current record without having to browse and
access record for every recipient, saving unnecessary computation.
Final mail values are recipients-dependent and are the values that will be
use to create the final ``mail.mail``. With a mechanism of optional additional
values + hooks for base and final values it should be possible to keep any
custom behavior already implemented with a cleaner interface and code flow.
See notably odoo/odoo@b1a5bf95f8 for example of why some code exist just
for hook purpose.
As a side note, light variable renaming is performed (email -> new_email)
to avoid shadowing email.
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
PURPOSE
Global purpose is to rename some methods and add some docstrings to clean
API of notification methods used in mail thread. Notably use _notify_thread
prefix for main methods, and _notify_by_'mean' for tool sub-methods.
SPECIFICATIONS
Remove unused arguments coming from old implementation and usage. They were
introduced notably for performance reason when cache was more often invalidated
which is not the case anymore. Anyway when parameters are unused it is always
better to remove them.
Remove ``notify_by_email`` parameter in ``_notify_thread``. It is only used
in channels to avoid notifying people of some automated notifications. The
same behavior has been cleanly implemented at odoo/odoo@018820d .
Rename methods, starting with ``_notify(_records)`` to ease their grouping
and understanding. Add some additional prefixes like ``_notify_by_'mean'``
and ``_notify_get_recipients`` for recipients related computation. Add some
docstrings, notably when parameters usage is not clear.
Some linting is also performed in updated actions, just to lessen styling
issues notably on runbot.
This commit should not change anything functionally as it contains only
some renaming and docstrings updates as well as some outdated parameters
removal.
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
Purpose is to better isolate MailThread related methods in those huge files
containing lot of code. Better have them located in a sub-section in order
to have all mail code at the same place.
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
Update some counters at latest runbot results, just to have updated counters.
Note that some counters are somehow not deterministic, hence not updating
everything.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
Before this commit the step about the slider to adjust the padding was
only consumed on click, which does not happen if the slider is used in a
drag'n'drop operation as expected.
After this commit this step is consumed on mousedown so that the
drag'n'drop operation is also taken into account.
task-2728994 (was task-2675252)
closesodoo/odoo#83692
X-original-commit: 42ce224fbe97f8d99ca5feec6d271412ce0647e1
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Before this commit the tip of the cover selection step was drawn outside
the display.
After this commit the tip of the cover selection step is within the
display.
task-2728994 (was task-2675252)
X-original-commit: 04df7addb41600e458495caa512342e9840e1259
Part-of: odoo/odoo#83692
website{_*}: website, website_blog, website_sale, website_slides
Before this commit if several steps were referencing the same trigger
(e.g. "+New" button in website) only one was displayed, but all were
consumed when it was clicked.
Because of this the tour steps on "+New" were active even when its menu
was opened.
After this commit only the displayed step gets consumed if the step is
marked as 'consumeVisibleOnly: true'.
It cannot be done implictly on all steps because of [1].
This new marker is set on all steps referencing "+New".
The tour steps on "+New" now also require their menu to not be opened.
[1]: https://github.com/odoo/odoo/commit/5e888f8a6ccf9996b3231db6bf314d045619109e
task-2728994 (was task-2675252)
X-original-commit: 0fa40e37e596798665a098ee999f49749b6012a2
Part-of: odoo/odoo#83692
Before this commit the tour only proceeded if the first image was
selected.
After this commit the tour proceeds if any image is selected in the
media dialog.
task-2728994 (was task-2675252)
X-original-commit: 92d7ad6d1c0b773a4a400b84bfc8d93c6980850b
Part-of: odoo/odoo#83692
Before this commit tips could be revived after being destroyed if a
resize event occurred, because the resize was being debounced and could
trigger a request to rebuild the bubble mode of the tip.
After this commit the resize debounce is cancelled if the tip was
destroyed in the meantime.
However another unidentified reason still manages to trigger an
asynchronous re-creation of the tip after destroy() is called, even
though all timeouts are cleared.
The following remaining sequence has been identified:
- mouseenter.anchor is triggered: but this is disabled during destroy
- it calls _to_info_mode() which registers the timer_in timeout: but
this timeout is cleared during destroy
- it calls _build_info_mode() which registers the _transitionEndTimer
timeout: but this timeout is cleared during destroy
- it calls _onTransitionEnd() which calls _updatePosition() which
revives the tip
Therefore an additional guard is added to prevent _updatePosition() from
being executed if destroy() was called.
Note that the mouseleave > to_bubble_mode chain being symmetrical to
this one, it is likely that it could also happen.
task-2728994 (was task-2675252)
X-original-commit: 635675398c153e123e62dd30a35ba23a29503c70
Part-of: odoo/odoo#83692
The currency rate could be different if the invoice date is different that the accounting date
Steps to reproduce:
1- Install l10n_ar
2- Create two different currency rate for foreign currency (i.e: Dollar) with also different Date
3- Create an invoice setting the currency as foreign currency (i.e: Dollar)
Current behavior before PR:
In page "Journal Items" could see that each account line use the currency rate defined by the accounting date,
however the currency rate filed (which is not visible) is defined by the invoice date.
Desired behavior after PR is merged:
Use always the accounting date to set the currency rate
+ CLA signing Augusto Weiss
closesodoo/odoo#83689
X-original-commit: 21692f28fd1db7097e1d4c23ce7dcbaa76936449
Signed-off-by: Josse Colpaert <jco@odoo.com>
This reverts commit f22364c32ac1438ededd611578b64a69186d7c9c.
- go to a partner
- click on the button "Sale"
- Create a new order
--> Issue you see all product archived (and all the python logique run
with active_test = False)
Since the original issue would be reintroduced, this commit apply the
active_test:false only if the search field partner_id is used.
closes#83600closesodoo/odoo#83669
X-original-commit: 825bb5f770f3abccadd3db3c4a57b25c3d9c35ed
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Nicolas Lempereur <nle@odoo>
Current behavior:
When using variant in PoS the price was not always correct
Steps to reproduce:
1. Set up items with modifiers (Modifier type must be of type variant creation mode : never, where adding a modifier leads to a different price than with the base item e.g. base item is 10 USD, modifier is 5 USD, total price is 15 USD;
2. Activate Product configurator and make sure it's a Bar/Restaurant in the PoS settings
3. Select the items with the modifier;
4. Leave the table and come back to the table
5. Change the quantity of this product
6. The price is back to the base price without the modifier
opw-2696529
closesodoo/odoo#83444
X-original-commit: d959dfada11a72d6bc275b35f5eeb06b045a0dea
Signed-off-by: Masereel Pierre <pim@odoo.com>
While updating financial reports to help avoid misconfiguration,
slightly update the coa to fix some wrong account types or name.
Tax id #2585627closesodoo/odoo#83268
Related: odoo/enterprise#19835
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Change the type of the account 5585 to be current
liabilities instead of non-current as it makes more sense.
Task id #2585627closesodoo/odoo#83266
Related: odoo/enterprise#19833
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Before this commit we could print the product labels of a picking from a
picking, but we couldn't print only the lots/sns. This commit adds in
this ability. Because we want to be flexible with this label printing
(i.e. have the option to choose between printing zpl or pdf + 1 per
unit or per lot/sn), we include it in the general "Print Labels" button
with additional wizards.
Note that we assume:
1. If there are no lot_ids in the picking => default to only product
labels wizard (i.e. this also means if a picking that only creates
New Lots/SN, lots/sns will not be printable until picking is
validated.)
2. Lots/SN PDF labels will only be in the 4x12 label format
3. Batch pickings can also print lot/sn labels
Part of task: 2494740
Related ENT PR: odoo/enterprise#23323closesodoo/odoo#82389
Related: odoo/upgrade#3202
Signed-off-by: Arnold Moyaux <arm@odoo.com>
When printing a done MO with a non-tracked finished product that doesn't
have a product barcode, an invalid zpl file is created (i.e. there is
no end to the label in this case). Instead of an invalid label, we now
write "No barcode available" to have a valid ZPL and to match what
happens in the PDF version of this label.
Part of task: 2494740
Part-of: odoo/odoo#82389
Previously the PDF product labels were not printing to any standard
label size/format. This commit makes it so they match the 4x12 format
(same used by Product Labels). Because of the dynamic number of labels
that may be printed (i.e. units have 1 label printed per 1 unit), this
template is much more complicated than previous template. Note that we
expect these labels to ALWAYS print in a 4x12 format (i.e. we keep all
logic contained within 1 template to avoid custom report/wizard python
code).
Also, this commit removes the logic for printing labels for products of
not 'Done' MOs since this didn't seem to be a possible situation (report
appears to always print blank in this case).
Part of task: 2494740
Part-of: odoo/odoo#82389
When a product has a valid EAN barcode, we would like to include the qty
of the product + its uom in its GS1 datamatrix (dm). There are a lot of
hardcoded values in report in order to fit GS1 standard:
- GS1 UoM codes are ALWAYS 3 digits (to indicate which UoM) + 1 digit
(to indicate number of digits) EXCEPT for Units UoM. Because we cannot
update a dict in QWeb, we check for both whether it's a supported GS1
UoM or a Unit separately rather than 1 general check.
- We hardcode the GS1 units value as '30' in this case (there are 2
options) because the code is specific to qty of a product (not qty of
product within a SSCC GS1 dm, there is a different value for that).
There are some limitations to this implementation due to
incompatibilities between Odoo + GS1, specifically:
- some Odoo UoMs are not included as GS1 UoMs => won't be included in dm
- # of Odoo quantity digits can exceed the number of digits allowed in
GS1 (8 digits for Units, 6 digits for all other UoMs, including
decimal values from rounding precision, e.g. 1 cm with rounding
precision 0.000001 has 7 digits as 1.000000) => won't be included in
dm in this case
- Odoo treats "fl oz" (Volume) and "oz" (Weight) as separate UoMs but
GS1 does not => we only handle weight for now
- Odoo supports non-integer values for Unit UoM but GS1 does not => we
round quantity to an integer value.
Note that implementation includes flexibility for users so they can
add/remove UoMs from the GS1 nomenclature rules as wanted/needed. This
includes user created custom codes (e.g. 90, 92-99 + extra character -
code isn't required to start with these numbers, but it won't be GS1
compliant) to handle UoMs not included in GS1 specifications as long as
they are correctly configured as quantities if user wants to be able to
rescan quantities back in with barcode app and match the 6 digits or
less quantitiy requirement when printing.
Part of Task: 2494740
Related ENT PR: odoo/enterprise#23323
Part-of: odoo/odoo#82389
When a package name is a valid SSCC number, we prefer to auto-print the
datamatrix to be used by shippers, which includes:
- the SSCC number
- the pack date (i.e. when it was put in pack)
- the weight of the package (only when less or equal to 6 digits)
Pack date field was added to accomodate this and defaults to when
package is created (e.g. when buying packaged meat at the supermarket,
it's assumed the pack date is when the package of meat was created).
SSCC datamatrix will auto-print now in 3 package reports:
- Package with contents
- Package Barcode (PDF)
- Package Barcode (ZPL)
Note if ability to create datamatrix appears to not work (only in PDF
versions) then standard 1D barcode will be used.
Part of Task: 2494740
Related ENT PR: odoo/enterprise#23323
Upgrade PR: odoo/upgrade#3202
Part-of: odoo/odoo#82389
This commit adds a new print menu option for pickings so users no longer
have to click on picking form > Packages smartbutton > switch to list >
select all packages > Print "Package Barcode with Content" to have the
same result.
Part of Task: 2494740
Related ENT PR: odoo/enterprise#23323
Part-of: odoo/odoo#82389
When printing Lot/SNs barcodes, it's sometimes desired that we print a
GS1 compliant datamatrix with the following info (when applicable):
Product barcode,
Lot/SN barcode,
Best By Date,
Expiration Date
For flexibility, a setting has been added for when the GS1 datamatrix
should print instead of 1D barcode.
Note that datamatrix will automatically exclude invalid product barcodes
(i.e. non-EAN compliant) and datamatrix size can vary based on amount
of data in datamatrix (so size has been set to accomodate expected
largest gs1 compliant datamatrix possible).
If it appears that datamatrix cannot be created, then default to
standard 1D barcode. Note that zpl printer has built in datamatrix
creation command, so we can always assume they will print correctly.
Part of Task: 2494740
Part-of: odoo/odoo#82389
When a product's barcode is EAN compliant (i.e. EAN-8, EAN-13, GTIN-14})
and feature to create DataMatrix is fully installed then we would like
to print its GS1 datamatrix on the package content report.
Additionally, if the product is tracked, we would like to include its
SN/Lot if assigned one + any "use by"/"expiration date" to make the
overall usefulness of the report go up.
Part of Task: 2494740
Part-of: odoo/odoo#82389
Two updates:
1. Match the ZPL layout, i.e. remove text centering / horizonal lines.
2. Make layout match 4x12 format (same used by Product Labels). Note
that unlike the Product Labels, we expect the lot labels to ALWAYS be
printed in a 4x12 format (i.e. we keep it simple and contained within
1 template).
Task: 2494740
Part-of: odoo/odoo#82389
Adding GS1 rules for UoMs in Odoo. Also adding 'yard' UoM since it
was not already part of standard UoMs but does have a GS1 rule.
Unfortunately not all standard Odoo UoMs have a GS1 rule so we add what
we can and will probably have to figure out how to handle these
unsupported UoMs when scanning GS1 barcodes. Note that 'lbs' rule is
needed not only to read in UoM quantity, but also to read SSCC (i.e.
package w/extra info) barcodes when their package contents' info is
included in the barcode.
Small update to GS1 rules sequences as well to make it easier to add
more rules in the future without having to worry about overlapping seq
numbers.
Part of task: 2494740
Part-of: odoo/odoo#82389
reportlab package is already in use to print barcodes, but it requires
extra packages (pylibdmtx and libdmtx) to print Data Matrix barcodes.
Unfortunately the python3-pylibdmtx package is not currently in the
Ubuntu version being used by Odoo SaaS and odoo.sh => we cannot install
this package automatically. Therefore we leave both packages as optional
extra installs for users since pylibdmtx is available via pip3 and
additional libdmtx package can be installed at that time (libdmtx0b on
linux, other OS info in pylibdmtx pip page).
We default to Code128 to avoid blocking stacktrace in case
Reportlab cannot print Data Matrices.
Part of task: 2494740
Part-of: odoo/odoo#82389
The current behavior is that we are exporting the line subtotal as
chargeAmount of the line.
This is an issue as this field is expecting the unit price instead.
A bugfix was done for importing extern invoices properly that broke
importing factur-x files from Odoo as it doesn't support that custom
behavior anymore.
Thus, this will correct the export to properly store the unit price
in the GrossPriceProductTradePrice ChargeAmount.
At the same time, add the NetPriceProductTradePrice ChargeAmount,
which is required and should contain the unit price with discount
applied.
closesodoo/odoo#83647
X-original-commit: c93f7dba0720e5e4f7d0a26ce05a854094e6a279
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
Steps to reproduce:
- go to inventory report
- remove the "Product > Location" Group by filter.
Problem:
The buttons “Inventory at Date” and “Create” are like merged together because there is no margin right
opw-2721995
closesodoo/odoo#83453
X-original-commit: a33e04df672658c8306a1052b1db79f233f8c54c
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Italians do not always mention the country code in the VAT
number of the partner, but we can suppose in that case that
it is within Italy. Instead of IT0477472701, they would put
just 0477472701.
closesodoo/odoo#83324
X-original-commit: 91b4168b5481d57e6af6e0c64895e97e47303ae8
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
Issue:
Padding impacting all reports since css file imported in common
report assets.
Solution:
part revert of commit: https://github.com/odoo/odoo/commit/69a1289eca79272efe7e53f8b3ad70de6df3d96a
use .swissqr_title and .swissqr_content selectors for most of the CSS
instead of body.l10n_ch_qr that will not work for installation of l10n_ch
that happened with fix 69a1289eca (8 september 2021 up to this fix).
opw-2686597
closesodoo/odoo#83283
X-original-commit: 71ae792d63b57627cc15eadc1e63a7b7a7dfbe70
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Steps to reproduce:
- install only sale_project
- go to Project > Configuration > Projects
-> Warning in the JS console
Cause: sale_order_many2one widget is added by sale_expense which is not
a dependency of sale_project, so we should not use the widget in
sale_project.
OPW-2717655
closesodoo/odoo#83593
X-original-commit: d5f62067685503b6698d6b876a842512834027bf
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
Steps :
- Attendances > Kiosk Mode
- Log in or out several times
Issue :
- Interface slows down
Cause :
- When a kiosk is destroyed, poll is started
- Yet each time a kiosk is started, the old kiosk is destroyed, which starts a new poll.
Fix :
- Given that the kiosk mode can't be escaped from the interface,
it is not necessary to restart polling when destroying.
opw-2735324
closesodoo/odoo#83517
X-original-commit: b3e9b4b17a4b444372fe24f07ad3c947fba540fb
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Thibault Delavallée