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>
Before this PR:
Canceling an activity linked to an event produces error because of non provided
thread.
Steps to reproduce:
- Create an activity with event (call or meeting) in chatter
- Try to cancel this activity
- There is an error about undefined thread and activity remains on the chatter
After this PR:
- Thread is provided in `onUpdate` method to use in `load()` in chatter
- `activityService` deletes the activity with event in `unlink` patch
closesodoo/odoo#152737
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, printing a receipt would result in an additional
empty page being printed. This not only wasted paper but also caused
issues. The problem was related to the notification element on the
print page. By removing this element, the issue has been resolved.
opw-3706233
closesodoo/odoo#152731
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Trying to call the get_lines() method of the stock.traceability.report
model was failing using the external API, due to the response containing
None values. Making sure that False is returned instead of None fixes
this.
The XML-RPC client error is the following:
closesodoo/odoo#152712
Typeerror: cannot marshal None unless allow_none is enabled
X-original-commit: 76ba5fc08e76c3163cd21ccfa710cdcc82340c89
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Current behavior:
If a customer has no email set, creating an invoice for that
customer and clicking on send and print will not generate a snailmail
for the invoice, even if, the checkbox (checkbox_send_by_post) is True.
Expected behavior:
A snailmail should be sent to the customer.
Steps to reproduce:
Using module_account from saas-16.2 to 17.0.
Create a customer invoice for a customer without email > print and
send > check "By Post" > send and print.
Cause of the issue:
The action action_send_and_print defined in account_move_send.py
filters the moves that trigger a mail creation in the var "success".
This variable filters out all moves without a partner_id.email.
This makes perfect sense for emails but not for snailmails.
However, creations of both types of mails are triggered by the
_hook_if_success method taking "success" as an argument.
Fix:
To allow snailmail creations and correctly trigger email creation,
we filter the moves with a partner email after the _hook_if_success
method and only for email creation, not for snailmails.
opw-3668487
closesodoo/odoo#152506
X-original-commit: b17a2c594aed08248c30842c62d2030de3087b51
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
This shouldn't change anything regarding SEO, but is worth a try.
It will also impact the link suggestion when creating a link in the
editor, but having pages listed first also have sense there, or at least
it won't be worst.
The idea for the SEO part is that if the sitemap order (if too long)
would have some impact as crawlers might have a limited crawling budget
for your website and it will only crawl the first pages it finds.
Are those "first pages" impacted by the sitemap order? It's almost sure
it's not, as Google definitely knows how to crawl on its own, and is
even probably ignoring the sitemap most of the time.
Also, pages:
- Are probably always important content since you created manually a page to
write something, while (some) controllers might just be content you
care less about. Pages are probably always important while we can't
say that for controllers.
- Should be fewer in number than controllers most of the time
- Have a lastmod set, as opposed to controllers
- May be created at any time, meaning a new crawler visit is needed,
while controllers are almost never added in production, installing a
new module is something very rare. Exception is about record's
controllers which are "created" at any time like pages (eg a new
product controller page)
For all those reasons, this commit reverse the pages vs controllers
order in the sitemap.
This is coming from our prod where some pages are yet not indexed while
they have been published months ago.
closesodoo/odoo#152350
Signed-off-by: Jérémy Kersten <jke@odoo.com>
DeepL translated "false" as "ложный" (the adjective form), but
we expect it to be "ложь" (noun form) when importing xml. This
fix will ensure that the string is correctly converted into a boolean.
I have recorded this as a separate commit for posterity and so it isn't
accidentally changed again in the future.
closesodoo/odoo#152285
Related: odoo/enterprise#55637
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
For a first iteration, Russian translations were done using DeepL using
1 large .pot file of all the standard modules to translate (e.g. no
localizations, no test modules, etc). Unfortunately for some reason
doing a msgmerge with the existing ru.po files didn't seem to work, so
old "Translators" metadata at top of files were lost (maybe they will be
re-added during next Transifex sync?)
Part-of: odoo/odoo#152285
The module `pos_viva_wallet` was added in v17 stable and it's
translation file/configuration was forgetten when that happened.
Therefore we add it in now because it should probably be translated
Part-of: odoo/odoo#152285
The table linked to analytic items can be pretty huge, and searching by
account needs to be fast.
For instance, this index can be used when deleting an account because of
the foreign keys.
closesodoo/odoo#151366
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
**Issue Description**:
Users encounter a misleading confirmation page when a payment is canceled or fails in version 17.0 and higher of our website. Specifically, upon a payment error, users are directed to /payment/status with an error message. However, selecting the "Skip" button redirects them to a confirmation page titled "Thank you for your order", suggesting successful payment. This misleading information can lead to confusion, especially since it results in the card being cleared for public users despite non-receipt of payment.
**Steps to Reproduce**:
1. Navigate to the 'Shop' section of the website, add a product to the cart, and proceed to checkout.
2. Click the "Pay with demo".
3. Select "Canceled" as the Payment Status and then "Pay".
3. Click the "Skip" button during the payment process.
4. Observe redirection to a confirmation page with the title "Thank you for your order", implying successful transaction.
**Proposed Solution**:
This issue, present in versions 17.0 and later, is due to a modification in the <template id="confirmation">, where the "Thank you for your order" title is now displayed regardless of the payment state. To resolve this, we propose introducing a conditional check to display this title when the payment state is "pending" or "done", ensuring accurate representation of the transaction status.
opw-3688785
closesodoo/odoo#151304
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
On a big database, the search for journal entries is basically not
usable.
This is because there is a missing index on the reference, as well as a
complex OR generated by the clause `('move_id.partner_id', 'ilike', self)`.
This commit will of course add the index, but will also remove the
clause because it is almost always possible to find the journal entry
via the partner by using the right filter instead, and since it is not
really an easy to discover "feature" it is most likely not even used.
On the test database, queries went from over 2 minutes to less than 1
second.
closesodoo/odoo#151222
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Dossogne Bertrand