Steps to reproduce:
- Create a new purchase tax and archive it
- Create a new PO
Bug:
the archived tax is still sugested on the PO Line
Fix:
apply same logic as for sales
opw-3701429
closesodoo/odoo#153156
X-original-commit: 79e0c4383fe72b5d04af8a81b57a65044a91d273
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Currently, the user does not get any feedback if the printer couldn't print.
This can happen when the printer identifier is not the same on CUPS and on the IoT box due to this RegEx:
https://github.com/odoo/odoo/blob/5b62e301b91a3f39857c2c7f18729e10796ef194/addons/hw_drivers/iot_handlers/interfaces/PrinterInterface.py#L55
After this commit, an error message is displayed in the IoT box logs so the user is informed that the printing failed.
Also, the '-' character has been added to the RegEx as it is a commonly used character in printer's identifier as CUPS doesn't allow spaces.
opw-3458347
closesodoo/odoo#153148
X-original-commit: 722a7db800b66db2d0b735ced1b9f4074ddac611
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
How to reproduce
1. Log in as Mitchel and go to a Subscription dashboard
2. Copy the URL and paste in incognito
3. Log in as Marc (which does have access to the subscription dashboard)
--> Traceback
closesodoo/odoo#153143
Task: 3581647
X-original-commit: 1c4b6b0a491d63d1f1b6c7a21089a42d4bfd64ab
Related: odoo/enterprise#56107
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
It appears that some user need to have the german translation on the dutch
localisation. This commit will translate the following files:
- COA
- Taxes
- Fiscal position
- Tax group
- Tax report
closesodoo/odoo#151296
Task: 3682464
Related: odoo/enterprise#55207
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
If translation of '__export__' module record's source and translated value in
'en_US' language is different. In that case, record's value of en_US lang is
translated value. Also in most of the case export module records are set as
noupdate false due to this while upgrading the database to version 16 from lower
version, the record's value is changed to their source value for 'en_US' lang.
To avoid this problem of updating a record's value, this PR will not considering
'__export__' module records for translation updates. Hence,'__export__' module's
records translation remain same as per original database.
Task : 3626386
closesodoo/odoo#148757
X-original-commit: 29341902bd6b6b7ff84eede2651251f6d2ce2faa
Signed-off-by: Raphael Collet <rco@odoo.com>
This commit fixes the problem of selection change on colorpicker fast
hover.
Before this commit, hovering too fast on the colors of the colorpicker
unselected text that would be on the edge of the selection and
uncolored. This is fixed by deep ranging the selection at the moment we
limit it to fonts. This improves the accuracy of the history as, in case
the font tag has been removed, it saves the text node as the current
selection. And since hovering updates rely on it, it prevents losing the
selection when unhovering fast (which is the cause of the bug).
We noticed two behavior when dealing with this bug. When hoving on a
color cell and exiting out of the colorpicker altogether, no bug
appears. But when switching between two cells, multiple selection issue
happen. After analysis of the performance graph, we believe that this is
due to the fact in the first case, onSelectionChange events are fired
and the handler is called, whereas in the other case it doesn't happen.
That handler particularly reacalulates the latest selection. And this
doesn't happen in our pathological case. After testing this theory, we
view that the problem is solved.
task-3295858
closesodoo/odoo#153212
X-original-commit: 9e3ee2563021b70ce64e7ec010b149820014bf8d
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Co-authored-by: Hamza Maimoune <hmai@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Previously, sanitize would remove the `<p>` tag if it was a child of an `<li>`
element. This commit makes sure that the `<p>` tag which is a child of `<li>`
with class `nav-item` does not get removed.
task-3609500
closesodoo/odoo#153211
X-original-commit: bbc980637bd104b69fcbe0452fad9be0d92288d2
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
The mega menu templates on the website, like `s_mega_menu_multi_menus` and
`s_mega_menu_menu_image_menu`, contains a `text-center` class within the `div`.
This div has multiple block type anchor nodes. When a list is added to the mega
menu, the anchor node is added inside the `LI`. Now clicking on the `A` tag then
adds the `oe_edited_link` class, resulting in the centering of the A tag due to
the `inline-block` display of the `oe_edited_link` class. This commit fixes the
issue by adding display `inline-block` when not with nav-link.
task-3609500
X-original-commit: d2d9e53b9165ab51078a9035850182132fa4a75c
Part-of: odoo/odoo#153211
Commit [1] implemented an approach to preserve all the attributes when
converting to a list. This is beneficial for `p` elements since they will no
longer be in the DOM. However, elements other than `p` will always remain,
requiring only dir attribute and not other attributes like href, data-name,
describedby, etc.. to transfer to the list.
[1]: c422db596d909efc5ae0ba049f8f9f5b80a90883
task-3609500
X-original-commit: 3b1cd38bf69cb91789d2b66070effab465a2a6c6
Part-of: odoo/odoo#153211
When inserting a list to a mega menu, the closest `LI` is a nav-item within the
navbar. We aim to prevent the toggling of this list. This commit ensures that
lists with class nav-item in the navbar are not toggled.
task-3609500
X-original-commit: a64a37aeeb5c6f6eb838cf5b9c4221e8522721cf
Part-of: odoo/odoo#153211
__Current behavior before commit:__
The `find` jQuery method calls at some point `apply` on the results.
Sometimes however the number of results can exceed the maximum number of
arguments given to a function.
In such case `RangeError: Maximum call stack size exceeded` is thrown.
__Description of the fix:__
Instead of selecting all children with `find('*')` and filter them
afterwards with the selector, we find all the elements that match the
selector in the closest `<body>` parent and then we keep only those
contained inside `$from`.
opw-3703963
closesodoo/odoo#153161
X-original-commit: 2667c8d42c5ac18257975e166a2aea254416e3fa
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Julien Launois (jula) <jula@odoo.com>
Before this commit, if a public holiday was created on dates overlapping
an existing validated leave, the timesheet entries for the public
holiday would not be created as they already existed for the leave. If
the leave was then refused or cancelled, the timesheet records linked to
it would be removed and the employee would have missing timesheet
entries for the public holiday.
This commit fixes this behavior by recreating the public holiday
timesheet records for the affected employees when refusing their leave.
opw-3550523
linked to com: https://github.com/odoo/odoo/pull/145522closesodoo/odoo#153118
X-original-commit: 47b4763ad948686e0e7155b3c0b3d0dc4d970963
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Adds a test following a fix done in odoo/odoo#143381
That fix ensured that the public leave used to
compute leaves intervals for the resources are
in the same company as the resource.
task-3668605
closesodoo/odoo#152827
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Steps:
- Create a draft mailing based on a theme that has the snippets menu
(the "Event Promo" theme, for instance).
- Create another draft mailing, this time based on the basic theme
("Plain Text").
- Switch from the former to the latter using the form view pager.
The editor for the basic theme record is not supposed to have a sidebar
(snippets menu), as it uses the floating toolbar instead. But when
switching between records like described above, the basic theme gets
replaced by the theme of the preceding record, and the snippets menu is
added to the UI.
This happens because [1] patched the `setValue` function to handle the
case where the element for dropping snippets (.o_mail_wrapper_td) is
missing, in particular if it gets removed via the codeview. Such fix
most likely had in mind the scenario where the codeview is toggled on
and off, but not the call to `setValue` that also happens when switching
between records via the form view pager. As a result, the html content
of a record based on the basic theme, in which such "dropzone" is
absent, is added as a child of the previous record's .o_mail_wrapper_td
element. This is certainly not the desired behavior, as it ends up
overwriting the basic theme by the one from the previous record (the
theme is defined by a class in the .o_layout div, which is a parent of
the .o_mail_wrapper_td element).
This commit, besides fixing the described issue, takes the opportunity
to add a comment with the presumed reasoning behind commit [1] and
extends the test tour in order to prevent regressions.
[1]: https://github.com/odoo/odoo/commit/9be2cb538f937645be4650af1031c8a1445bb48b
task-3573951
closesodoo/odoo#151065
X-original-commit: ed4727d922107745482dbbeb068d4bd6eba788dd
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Issue:
======
Adding a new block in mailing in email marketing raises an error.
Steps to reproduce the issue:
=============================
- Go to email marketing
- Create a new mailing
- Create one from scratch
- Drop any block
- `TypeError : Cannor read properties of null (reading 'parentElement')`
Origin of the issue:
====================
When we drop the block in the iframe's document we trigger the `click`
event but we don't have any selection yet in the document so
`anchorNode`will be `null` thus the error.
task-3724551
closesodoo/odoo#152814
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
This commit addresses a problem in CRM where it was not possible to send emails directly from the preview window.
The issue arose when returning to the chatter interface from the preview window,
as the thread object was not properly passed back (to the chatter).
This fix ensures the thread object is reintegrated into the chatter interface, resolving the email sending issue.
Issue was traced back to the commit
5d99de10ec [FIX] mail: do not reload chatter when not needed
https://github.com/odoo/odoo/commit/5d99de10ec09244e10e4130573ad2e0c38e8600
[reproduce]
- install crm
- create activityTypes AT with an email template specified( crm/configuration/activityTypes)
- open a Lead, ( crm/sales/MyPiepline)
- schedule activity with activity type AT
- click "preview" on the activity
- click "send" or just close the preview -> BUG traceback
opw-3680600
closesodoo/odoo#152698
Signed-off-by: Andrzej Pietrusiak (pian) <pian@odoo.com>
Versions
--------
- 15.0+
Steps
-----
1. Go to product variants;
2. select a product;
3. add a new Vendor line in the Purchase tab;
4. save;
5. add another Vendor line;
6. save.
Issue
-----
Previous line disappears from view.
Cause
-----
In 93bc96047ff684cb66b69186822493815cf37982 I added logic which sets
the `product_tmpl_id` in `product.supplierinfo` if a `product_id`
gets written without accompanying `product_tmpl_id`. Adding lines from
the Product Variant views add `{'product_id': False}` to the values for
every vendor in the list without a Product Variant, so their
`product_tmpl_id` gets overwritten with the `product_tmpl_id` of an
empty product.
Solution
--------
Only overwrite `product_tmpl_id` iff `product_id` gets written to a
non-falsy value by changing `if 'product_id' in vals` to
`if vals.get('product_id')`.
opw-3664524
closesodoo/odoo#153168
X-original-commit: 03d4be7b8804863a7e7e9af29a8ec61c65d6dab3
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Levi Siuzdak <sile@odoo.com>
When using Peppol Bis 3 with a partner without VAT, use the
`peppol_endpoint` to fill the `PartyTaxScheme/CompanyID` and
`PartyLegalEntity/CompanyID` to avoid errors like:
"[BR-E-02]-An Invoice that contains an Invoice line (BG-25) where the
Invoiced item VAT category code (BT-151) is "Standard rated" shall
contain the Seller VAT Identifier (BT-31), the Seller tax registration
identifier (BT-32) and/or the Seller tax representative VAT identifier
(BT-63)."
"[BR-CO-26]-In order for the buyer to automatically identify a supplier,
the Seller identifier (BT-29), the Seller legal registration identifier
(BT-30) and/or the Seller VAT identifier (BT-31) shall be present."
Also adapt the tests, as the rules for the supplier's identifier are
stricter than for customers.
closesodoo/odoo#153046
X-original-commit: 2044a11dd6ec493eb020b6067cad1d216e565687
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Steps:
- Install project module
- Activate customer rating from settings
- Create new project with out company
- Add stages, then in final stage set in rating email template
to 'Project: Task Rating Request'
- Create a task and move the task to that final stage then
- Check the emails in settings, the subject line is look like
': Satisfaction Survey'.
Issue:
- When there is no company set on the project, on that time company name
is missing in subject line.
Cause:
- In task satisfaction survey email template only set the company
name based on the project only.
Fix:
- By adding the current user's company name to the template subject line,
the problem will be solved.
task-3626702
closesodoo/odoo#153103
X-original-commit: 8cf35cb51d97c0259e98765f899e3f2f8b98f52e
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
According to https://docs.python.org/3.7/library/xmlrpc.client.html :
When passing strings, characters special to XML such as <, >, and & will be
automatically escaped. However, it’s the caller’s responsibility to ensure that
the string is free of characters that aren’t allowed in XML, such as the
control characters with ASCII values between 0 and 31 (except, of course, tab,
newline and carriage return); failing to do this will result in an XML-RPC
request that isn’t well-formed XML.
This commit implements the removal of control characters from strings. As we
convert binary data to a string and return it, the resulting string should not
contain forbidden characters neither. The modification of dump_unicode function
now fulfills this requirement and can be applied to dump_bytes, contributing
to a more consistent behavior overall.
steps to reproduce:
- create a product with an ASCII control character in its name (ex: \x03)
- read the product name using XMLRPC
before this commit:
- client can't parse the response, an error is raised
after this commit:
- we make sure the string is free of those characters
opw-3617458
closesodoo/odoo#153084
X-original-commit: 3fa92ff58daef0dd2464beadeafef208871deca6
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Nicolas Danhier (nda) <nda@odoo.com>
This commit fixes an issue caused by the way we use onInput props in Knowledge to
fetch articles depending the current search value. Since we start from an empty
string in the input again, it make no sense to display the choices previously
fetched with a search value no longer displayed in the UI. The only way to display
the correct items is to update the input value, then put an empty search to fetch
accordingly.
This is clearly an issue, when the onInput props is used to fetch the content of
the SelectMenu, depending of the search value. The UI obviously display an empty
search, and filter accordingly, but without fetching the items corresponding to
the empty search value.
A test was added as well to assert SelectMenu can be used for this purpose without
forgetting to call onInput again when clearing the search value in beforeOpen.
closesodoo/odoo#153072
X-original-commit: ca417f171b1bd2dd567beed7bc0e1fcaba6c8a4c
Signed-off-by: Bastien Fafchamps (bafa) <bafa@odoo.com>
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
This commit fixes the style applied to the o_select_menu_sticky elements. Since the
fix from commit (1), the text cursor is shown when hovering those elements. This was
without considering the fact that this class is mainly used to display elements on
top of other elements of the component.
This includes usages with the bottomArea slot, that can be used with a DropdownItem.
Because of the changes from the commit previously named, the focused color was no longer
applied, and it was showing the wrong cursor when hovering.
1) 53466e152bb819524b2890866bea4cbdd9091275
X-original-commit: 8ecc6f2a960494f01a745f21a24c3cc57614ad86
Part-of: odoo/odoo#153072
Do not take into account "retención" type taxes in the sum of the total price of the invoice lines,
these taxes are of retention types and are declared in RetencionSoportada XML node.
Add amount_retention in invoice values and change template_invoice_factura to activate RetencionSoportada xml node.
Before this commit:
Invoices with "retención" type taxes are not declared correctly, validation errors in the response of the tax agency.
With this commit:
Invoices with "retención" type taxes are declared correctly and accepted with no validation errors in the response of the tax agency.
closesodoo/odoo#152978
X-original-commit: ff961775d7f175c4f71f33f9b3955c04a234db55
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steps to reproduce:
- Create a product with two variants A & B
- Create a BoM for this product and create the following operations:
-- ope_A that applies only on variant A with a duration of 10
-- ope_B that applies only on variant B with a duration of 30
-- ope_common that applies to both with a duration of 60
- Set an employee cost (e.g. 120) on the chosen workcenter
- Open the Overview of the created BoM
Issue:
The column 'BoM Cost' will be completely incorrect, as the `zip()` will
try to associate all operations on the BoM (including operations that
doesn't apply to the selected variant) with all operation lines
generated for this variant (already filtered).
This will end up trying to add the wrong duration costs to the wrong
operation line on the report.
Instead, we can simply compute the value once and override its
computation in `mrp_workorder_hr` to include the employee costs.
closesodoo/odoo#152901
X-original-commit: 04b5b5d45265de0cf374c1295a679f38febfe5ca
Related: odoo/enterprise#55973
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Current behavior:
The column : "To Consume" is not aligned with the values.
Cause of the issue:
There is an html anchor with a t-else close that should not be there.
Fix:
This anchor is removed.
opw-3692098
closesodoo/odoo#150891
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
After the commit added by odoo/odoo#152513, it was not
possible anymore to create a new time off from the
management view in situation where the default leave type
wouldn't be defined.
This commit adds a falsy value so that the variable exists
even if no default leave type is set.
closesodoo/odoo#153066
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
**Current behavior:**
Confirming a sale order containing an order line associated
with >1 products which are tracked via serial number creates a
single repair order.
**Expected behavior:**
A repair order for each individual product in the line is
created.
**Steps to reproduce:**
0. Create a storable product which is tracked via serial number
and has create_repair set to True. Update on hand stock so
there are at least two available and assign them each a
serial number.
1. Make a new sale order with one order line for that product
with the product_uom_quantity equal to the quantity
created in step 0
2. Confirm the order and open the newly created repair order
3. Select a serial number for the repair order, start the
repair, then end the repair to raise the exception
**Cause of the issue:**
Multiple products will be associated with one serial number. In
stock_quant.py, the check_quantity() method checks the quantity
of product_ids associated with a particular lot_id and
location_id. In this instance, quantity will now be >1 which
results in the ValidationError exception.
**Fix:**
Make a discrete repair order for each product in the order
line when the product has serial tracking. This is more logical
than asking a user to select one serial number for many
products.
opw-3688072
closesodoo/odoo#151041
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
ba1a550#diff-36973ac6e1f20b32a00fbcdc1f811c923bbb44ca15a0e068018e904ff565644fR97
The previous PR added some constraints on what can be used on the
context of views. The key word 'force-email' is no longer relevant and
will be removed from the context before reaching the next view/python
code.
This commit's purpose is to remove the force_email that were forgotten.
In order to still open the simplified partner form view, the ref of the
view is given in the context instead. While at it, we also fix the
create option given on the partner_ids field that was inconsistent.
affected version 17.0 - master
task - 3538000
https://www.odoo.com/web#id=3538000&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=form
Please enter the commit message for your changes. Lines starting
closesodoo/odoo#149806
Related: odoo/enterprise#54549
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Since [1], the websocket worker is started when a transient thread is
added to the mail store. This occurs because this PR introduced a call
to the `addChannel` method of the bus service when the current user
was not member of the thread.
Since transient threads are not yet created, they have a partial state
that does not necessarily include channel members hence the impression
that the current user is not member of the channel.
This PR prevent starting the bus service for transient threads.
[1]: https://github.com/odoo/odoo/pull/146800closesodoo/odoo#153000
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit:
After commit f7147b36da0b3963e5bafb09cb585f130dcbfcf0
on changing partner gst treatment, it makes GST treatment
on posted invoice False
After this commit:
It resolves the issue due to commit f7147b36da0b3963e5bafb09cb585f130dcbfcf0
closesodoo/odoo#152997
Signed-off-by: Josse Colpaert <jco@odoo.com>
Restrict collaborator portals to:
- Change unallowed fields on subtasks
- Create/Update/Delete tags.
They can only link, unlink tags to tasks.
task-3698146
closesodoo/odoo#152992
X-original-commit: 32c21d651c32c978f3cf67105e1c2eca9de2334d
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Before this commit:
When creating a nested checklist within another checklist and subsequently
changing the direction of the parent list, the direction of the parent element
would reverse alongside the pseudo element. However, in the case of nested
checklists, only the content's direction would change, while the pseudo
element's direction remained unaffected.
Afte this commit:
When altering the direction of the parent checklist's content, both the content
itself and the associated pseudo element's direction is changed alongwith the
nested checklist.
task-3461806
closesodoo/odoo#152890
X-original-commit: f46e1f0c5b00f2e289feef5e35f3fea6fb477104
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Avoid specific changes of l10n_in invoice report to affect other
countries.
OPW-2504287
closesodoo/odoo#152862
X-original-commit: 87a1fa6f49f1dc1824cfcdc2701d92d0382fa652
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
When user gives wrong domain in any account report of report line and tries
to access the same report similar error is generated.
Steps to Produce:
- Install 'Accounting'
- Go to Accounting > Configuration > Accounting Reports
- Open any account report and click on add a line
- Now add a line in the report line
- Create an expression select 'Computation Engine' as Odoo Domain.
- In Formula add this domain [('code', '!=like', '620.%')]
- And add Sub-Formula as 'sum'
- Save the expression and also the report
- Go to Reporting and select the above report
Traceback will be generated
ValueError: Invalid leaf ('code', '!=like', '620.%')
When user applies invalid values in domain or invalid domain format it leads
to the traceback because of this line:
https://github.com/odoo/enterprise/blob/16.0/account_reports/models/account_report.py#L1510
sentry-4358342635
closesodoo/odoo#152910
X-original-commit: a41c9ef79a71230422eeb6c561f7f217c513bb30
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Steps to reproduce:
- Install `crm` module (for test purpose)
- Create a new lead
- Set an email address, phone number, company name and contact name
- Save the lead
- In the chatter, send a mail (with the default recipient checked)
Issue:
- The partner has only the email address set (also set as name).
- The `contact name` on the lead is updated with the partner name
(who is the email address).
Cause:
When sending a mail with the default recipient checked, the partner
is created based only on the email address (therefore, name is same as
email), and when assigning the new partner on the lead, the
`contact name` is updated with the partner name (who is the email
address).
Solution:
Alter the route `/mail/partner/from_email` and `/mail/message/post`
so it can take or manage additional values for the creation of the
partner.
opw-3512045
closesodoo/odoo#152780
X-original-commit: 92916985b72ff1cda2021900f0aa9476f7283576
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Google has removed the feature that allowed sitemap submissions. Now,
it's standard practice for Google to crawl the /sitemap.xml. This commit
permits to show a notification message when the user clicks on the
button to submit a sitemap.
task-3323849
closesodoo/odoo#152700
X-original-commit: fb842f682bb8b2600d861a5e0bb92503857bd2de
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
There are multiple types of Identification Numbers in Romania and if you invoice
to a natural person, you are also required to send an electronic invoice.
Thus, we will add a check to allow the two TIN numbers that needs to be correct.
Example of valid tax number 'RO1234567897 or 'xyyzzaabbxxxx' or '9000xxxxxxxx'.
-Tin1: For xyyzzaabbxxxx, 'x' can be any number, 'y' is the two last digit of a
year (in the range 00…99), 'a' is a month, b is a day of the month, the number 8
and 9 are Country or district code
-Tin2: 9000xxxxxxxx, start with 9000 and then is filled by number (range 0 to 9)
Also stdum also checks the CUI or CIF (Romanian company identifier). So a number
like '123456897' will pass.
This commit will remove some test that are not relevant anymore since we can't
apply a vat number that don't follow the legal convention.
closesodoo/odoo#152649
Task: 3716671
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
The express checkout button is handled by Stripe, so we have no control over it. Upon
inspecting Stripe's code, it looks like the button simply fills the available width. The
button just above Stripe's button ("Sign In"/"Process Checkout") sets the available width,
so if it's narrower, Stripe's button gets truncated.
This PR sets a minimum width on the container around Stripe's button. This seems to work
for different screen sizes and locales. The problem with this fix is that it could break if
Stripe's button content gets wider. Unfortunately, since the button is displayed in an
iframe, there's no better fix AFAIK.
opw-3430099
closesodoo/odoo#152510
X-original-commit: 75b6fe71896f1dcce5ed6ebca0e096a45aa891e9
Signed-off-by: Louis Tinel (loti) <loti@odoo.com>
Steps to Reproduce
===================
1. Create an event (e.g. starting at 9:00 AM)
2. People arrive early and attempt to scan a badge at 7:30 AM
--> An error occurs: "Not part of an ongoing event"
Technical Reason
=================
-> Before this commit we were considering both date and time due to this
is_ongoing was set as false.
-> So to support early entrance we remove the old condition and added a
new condition.
After this Commit
=================
It will let you scan badges and verify attendee as long as event is not
finished.
Task-3596660
closesodoo/odoo#151703
X-original-commit: https://github.com/odoo-dev/enterprise/commit/3a2e4f123f1b3ff2eb1c444d14891eddd7e7ebac
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
You should be able to create analytic plans with analytic group.
But currently, you need Access Right's group.
We should put a sudo there.
closesodoo/odoo#151328
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
The generated facturae files do not pass the FACe platform checks. The
platform itself didn't give us any useful information.
A feedback from the Spanish government said though:
> We detected inconsistencies with the field `<ds:DigestValue>` from the
tag `<xades: SignaturePolicyIdentifier>`
Although not explicitly mentioned, we should apparently use SHA1 for the
digest value of the Signature Policy instead of SHA256.
opw-3673349
opw-3716276
closesodoo/odoo#152720
X-original-commit: e5d69a73e2e781d00f67c0590a8fc13b09a06ebf
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Issue:
When using a mercado pago invalid access token with extra tabs, we get 403 response from mercado pago without a body
which raises and exception while handling this exception we fail to parse the response as it has no body.
line causing the issue: https://github.com/odoo/odoo/blob/9764e6f7fe39a10f3b04e1764110d8c274d0431a/addons/payment_mercado_pago/models/payment_provider.py#L70
Steps to reproduce:
1- Enable mercado pago as a payment provider
2- Set a valid access token for mercado pago with extra tabs
3- Go to website
4- Fill the cart
5- Checkout with the cart using mercado pago
6- You see error message of unhandled json parsing error
Solution:
We should wrap parsing the response in a try statement to handle the responses without body
opw-3654133
closesodoo/odoo#152858
X-original-commit: 952a64423e7cabf7cd3ef700dff7be2bfba1b56a
Signed-off-by: Omar Abosamaha (abom) <abom@odoo.com>
The iot build fails following the installation of the new
linux-image-6.1.0-rpi8-* packages
The base image is recent enough to skip the upgrade during the build
The "apt upgrade" command is therefore removed from the build
closesodoo/odoo#152828
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
The compatibility was broken in a couple of points, clients
are required to update the `l10n_it_edi` or cannot send invoices
to the Italian EDI. Updating the module fixes the errors.
These two errors may appear:
```
[...]
File "/home/odoo/work/odoo/odoo/fields.py", line 1216, in __get__
raise ValueError(f"Compute method failed to assign {missing_recs}.{self.name}")
ValueError: Compute method failed to assign account.move.send(<NewId 0x7ff2da360eb0>,).l10n_it_edi_warning_message
[...]
File "/home/odoo/work/odoo/addons/l10n_it_edi/wizard/account_move_send.py", line 57, in _compute_l10n_it_edi_warning_message
action = error_data['action']
~~~~~~~~~~^^^^^^^^^^
KeyError: 'action'
```
Original broken PR: odoo/odoo#142596closesodoo/odoo#152824
Signed-off-by: Josse Colpaert <jco@odoo.com>
Commit [1] moved (almost all of) the code of formatFloat from
views/fields/formatters.js to core/utils/numbers, to make it
accessible in the frontend. A formatFloat function was kept in
formatters.js to handle the false case, which makes no sense in
number utils, but is useful for fields. However, a lot of imports
have been updated to use the numbers.js instead of formatters.js
(i.e. they no longer benefit from the support of false), whereas
they are actually formatting field values, so they should have
kept using the formatFloat from formatters.js
This commit adapts the places where the formatFloat to use must
come from formatters.js, not numbers.js.
[1] https://github.com/odoo/odoo/commit/054ca0a19aaf297f420a1b478b93ae26f1b943b8
task 3722043
closesodoo/odoo#152810
Related: odoo/enterprise#55919
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
When filtering column had too much attributes, scrollbar
would appear. Scrollbar was deleted but ability to scroll
is left.
task-3609062
closesodoo/odoo#152769
X-original-commit: 1be3fa46062d83ca8438dc2e44ba3904467c6710
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: anko-odoo <anko@odoo.com>
sebrahim