This commit will change the label to avoid the clash with account audit trail
module.
Also updating the pot of the localisation.
closesodoo/odoo#145149
Task: 3627720
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
In the context of the bookkeeping act in denmark, we need to record all the
modification and delete of all the input, so we should by default install the
audit_trail module.
Since they need this in 17.0 we will make a bridge module.
Task: 3627720
Part-of: odoo/odoo#145149
Since 857c485175, rates are
not truncated anymore.
The stored rate value on SO, between SO currency and company currency
was not adapted and was still truncated, leading to invalid values
after rates conversion.
See also 5a621cea4c5a16998a3b83890144f81a3880244b where the same solution
was appied to pos orders.
opw-3638199
closesodoo/odoo#152592
X-original-commit: 6291424bd49a55f446f87c09af71fd13a1c13851
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps:
- Go to website and edit
- Add an event block
- Change the template of the block from picture to card layout.
- Replace the image of one card by a 4k image.
Issue:
The custom cover is blurry.
Reason:
By default the custom cover is resized to 256x256 (but not the default one because
it uses a static image path).
opw-3390459
closesodoo/odoo#152278
X-original-commit: d6d24ceb2a5b6e735ffb2fe1d5cea1f8f945f288
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
Issue:
Possible to reproduce in 17.0: when adding a new field to the website
form of the "Extra Info" page in the eCommerce, a traceback is raised
(`OwlError: Missing template: "website.form_field_json"`) when the user
selects "Delivery Point Address" (`sale.order.access_point_address`).
Explanation:
JSON fields (which exist since [1]) are not supported as selectable
types in website forms, and they should not be because customers would
not be able to properly fill them out.
Fix:
Filter out all JSON fields from the list of authorized fields in website
forms; they will not appear in the list of selectable types anymore.
[1]: https://github.com/odoo/odoo/commit/7eeba9d205d2dace571b5d0895ddba6290a512db
opw-3596713
closesodoo/odoo#152545
X-original-commit: 28c3eb5878ad6f3d40a096803f3ba4aef5ef7937
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Steps to reproduce the bug:
- In Website edit mode.
- Drag and drop a "Cover" snippet into an empty page.
- Sets the "Height" option of this snippet to "100%".
- Drag and drop a "Media List" snippet into the page.
- Drag and drop a "Popup" snippet into the page.
- Save the page.
- Scroll quickly the page to the bottom before the popup appears.
- When the popup is open, resize the window to trigger a "resize" event.
- Close the popup.
- Scroll the page to the top.
- Bug: the height of the "Cover" snippet is a way too high.
This bug occurred because the height of the snippet with the "Height:
100%" option enabled is calculated based on the scrollable element it is
in (since this commit [1]). However, when a popup is opened, the
detected scrollable element was incorrect due to the "overflow: hidden"
rule added to "#wrapwrap" by the "modal-open" class on the <body>.
[1]: https://github.com/odoo/odoo/commit/b371cb42cb67115692464c102813b7ebd54785d9
opw-3643498
closesodoo/odoo#152402
X-original-commit: 35b3f676820f7a19e842b3403a5ebcf956714a70
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
we execute a subprocess without checking if an error occurs
so we place the subprocess.call() in a try except
closesodoo/odoo#152331
X-original-commit: 4adda36260f3ba0fdf75688b419593006b80adb7
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Prevent an infinite loop when the cycle in the parents does not contain
the starting id: `3->2->1->2->1...`
Example:
```
>>> m=self.env['ir.module.category']
>>> c1,c2,c3 = map(m.browse,[1,2,3])
>>> c2.parent_id = False
>>> c3.parent_id = False
>>> c1.parent_id = c2
>>> (c3|c2).parent_id = c1 # this never ends
```
With current patch the call to `_check_recursion` successfully detects
the new cycle.
closesodoo/odoo#152080
X-original-commit: e7c6445dd1896bb182b44af768814f297027d3a4
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@odoo.com>
Before this commit:
- When a banner was inserted at the first line and Ctrl+A and backspace
is performed, nothing happens.
After this commit:
- Now, all the content except banner will be selected and removed.
task-3432167
closesodoo/odoo#151735
X-original-commit: 530f102720458e5e1c224bf38073cd763309bf0a
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit:
- Performing ctrl+a and backspace inside a banner would unintentionally remove
its first element, which could be a block tag
After this commit:
- Now performing ctrl+a and backspace inside the banner will no longer remove its
first element if it's a block tag.
task-3432167
X-original-commit: ddc8587f8a712fdddaa714bee2931cb149c03a38
Part-of: odoo/odoo#151735
Before this commit:
- Inserting a banner did not set focus inside the banner; instead, focus
was placed after the banner.
After this commit:
- Now, upon creating a banner, focus is now correctly set inside the
banner.
task-3432167
X-original-commit: 7327d20626ec9164f47e00f7094a36b8794db5de
Part-of: odoo/odoo#151735
Before this commit:
- Inserting a banner after already existing content it's impossible to
go to the next line of the banner.
After this commit:
- It's now possible to navigate to the next line of the banner.
task-3432167
X-original-commit: 05a879f81ac59d47b718abbb5966fd4f8214e1de
Part-of: odoo/odoo#151735
Steps to reproduce
==================
- Use a laptop with touch or apply the following patch
```diff
diff --git a/addons/web/static/src/core/browser/feature_detection.js b/addons/web/static/src/core/browser/feature_detection.js
index 21c6294b1b0e..64c4bc9b899c 100644
--- a/addons/web/static/src/core/browser/feature_detection.js
+++ b/addons/web/static/src/core/browser/feature_detection.js
@@ -62,6 +62,7 @@ export function isDisplayStandalone() {
}
export function hasTouch() {
+ return true;
return browser.ontouchstart !== undefined || browser.matchMedia("(pointer:coarse)").matches;
}
```
- Enable debug mode
- Go to contacts
- Hover the mouse over a question mark next to a field
=> Nothing happens
Cause of the issue
==================
The function `shouldCleanup` returns true when the device has touch and
the popover has been triggerd with the mouse
opw-3694156
closesodoo/odoo#152629
X-original-commit: 27242a0f1070b6b16c16e479e22dc0ccad0d9659
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
The root of the issue:
The external identifiers are not guaranteed to be unique on their `name`
alone, the unique constraint is on the `name` and on the `module` fields.
Before this commit:
If a user or third party app were for example to create an external identifier
"project.autovacuum_job" and point it to an `ir.cron` record,
then that `ir.cron` would also be kept activated, which could cause
major issue if it makes calls to external systems, sends mail, etc...
After this commit:
All the crons are deactivated by the neutralisation, except for
the autovacuum
closesodoo/odoo#152535
X-original-commit: 0cc89a026d05b37714864e7ebb695e77ef2d1e7d
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Signed-off-by: Alexandre Moens (mao) <mao@odoo.com>
Some of the translation needed to be done or updated,
especially the ones about the warnings.
closesodoo/odoo#142596
Signed-off-by: Josse Colpaert <jco@odoo.com>
All the pre-sending checks that were done on the invoices before sending are now split by model, so that there's more separation.
ActionableErrors is used to show all the errors and give the user a quick action to fix the problems.
"These partners have an incomplete address, please verify xyz"
-> View partners ----> <partners view>
- Tooltip for IT XML export when readonly
We relied on the Italian xml export field's help tooltip before.
Now like other export options we have a dedicated <i> tag only shown when the field is readonly.
- Cannot change to test/official if you don't register
If you have Demo edi_mode, and you change to Test/Prod but don't register,
the EDI proxy user won't be deleted, and the edi_mode won't be saved.
So you think you changed to Test, but you haven't.
For compatibility in 17.0
- `l10n_it_edi_warning_message` must be maintained for the old view to work and make sense.
- Modified `l10n_it_edi_warning_message` becomes then `l10n_it_edi_actionable_errors`
Part-of: odoo/odoo#142596
`Model_get_actions_record(**kwargs)` helps building `ir.actions.act_window`
actions based on a certain model on very simple cases.
It opens a form if there's just one record, a list,form if there's more than one.
Given keyword arguments will overwrite those in the action.
This change serves as a base for the `actionable_errors` widget,
where it's used extensively to remove boilerplate code.
Part-of: odoo/odoo#142596
The new widget is meant to be a warnings header for wizards and forms,
where flows like EDI can list a series of errors and actions for
the users to fix the roadblocks.
The HTML result is an `<ul>` list with a point for each warning
and a link to a given action. Clicking the link will fire the execution
of a Python method on the backend, also passing back to it a series of
parameters the component has stored on setup time.
During setup, ActionableErrors accepts this structure as incoming data:
{
'error_key' : {
'message': _("Description of the warning"),
'action_text': _("Text of the link"),
'action_model': 'model.on.which.the.method.is.called',
'action_name': 'action_python_method_name',
'action_params': [...],'
},
...
}
A map is used instead of an array, so that the Owl framework
could be more precise in rendering changes in future development.
(i.e. remove a warning after clicking the action link
without re-rendering the whole widget)
This Widget will be used both for `l10n_it_edi` and `account_intrastat`
and can be embedded in many other occasions.
Part-of: odoo/odoo#142596
Before: When a user receive a mass_mailing and click on the
unsubscribe button, he arrives on the unsubscribe webpage where
the first sentence stay in english whatever the website language
Step to reproduce:
- Create a db with the email marketing and web module
- Create a mailing list with at least one recipient
- Send the mailing (catch the email with an email catcher, ex: mailhog)
- Click on the unsubscribe button
Now: The first sentence is in the website (or portal) language
opw-3538873
closesodoo/odoo#152579
X-original-commit: 6ba3dc277b9bf6b093eeefe889f20734ae4d135b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Slot params are dynamic content, similar to props, and are not
translated.
There is no point in adding untranslated content to the .pot files; so
this commit prevents the content of slot params from being exported for
translation.
Task-3718993.
closesodoo/odoo#152606
X-original-commit: b839faf09be259ffdccf9d872e646e4ebe4a8bcb
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
To reproduce
=============
- Go to shop page
- Edit the page
- select a product
- add a ribbon
- modify the ribbon (background or text color)
the ribbon is not updated
Problem
=======
the default ribbon are using the bootstrap class "text-bg-*" to set the
background color and the text color. But the editor expects the ribbon
to have a class "bg-*" and color css style. That's why when editing, the
class "text-bg-*" is never removed so each time it's taken instead of the
added style.
Solution
========
remove the class "text-bg-*" from default ribbons and use the fields
"bg_color" and "text_color" to set the background and text color
opw-3674520
closesodoo/odoo#152604
X-original-commit: 2bd09b4b41b27780ec20820cac76051ae20b7f4d
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
Problem
---------
Currently, when importing a UBL/CII xml, the bank account details remain
empty while we usually have the bank account number and the BIC code
provided in the XML.
Objective
---------
Autofill the partner_bank_id field on the invoice using the values
provided in the UBL/CII XML.
Solution
---------
Currently, UBL XML are organized as such:
PaymentMeans(0..n)
|-PayeeFinancialAccount
|-ID
|-FinancialInstitutionBranch
|-ID
And CII as such:
SpecifiedTradeSettlementPaymentMeans(0..n)
|-PayeePartyCreditorFinancialAccount
| |-IBANID (for SEPA)
| |-ProprietaryID (for national payment)
|
|-PayeeSpecifiedCreditorFinancialInstitution
|-BICID
We first fetch the account numbers from the XML (several may be
present) and store them in a list.
This list is sent to the edi_common which will attempt to find one
account that match the given values. If none are found, we create one
bank account for each piece of bank data found in the xml. We then set
one account that was freshly created.
task-3636150
closesodoo/odoo#152559
X-original-commit: 63a32be1e3b32762bc489e17eea634a071a597b9
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: Antoine Boonen (aboo) <aboo@odoo.com>
Before the current PR, the version of Odoo along with the git branch of
the IoT Box and the associated image were never logged. Adding this
information to logs allow to to debug / inspect issues more easily
task-3716879
closesodoo/odoo#152558
X-original-commit: 8bf1c8984948b003544427eb81f66514ed783bd0
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Create an automation rule for a field for which there's no onchange
yet. The rule type is "on_change" (on UI change).
This type of automation rule adds an onchange method on the
selected fields, which thus involve the onchange mecanism: the
"on_change" attribute will be set on that field nodes in views,
s.t. when the user changes it, onchange rpcs are done.
However, views are cached, and creating such a rule didn't clear
the cache. So if the view was already in cache, the rule seemed
not to work, because the client still received the old version of
the view, without the "on_change" attribute.
This commit clears the cache when such a rule is created, s.t.
after a client reload, the feature gets enabled as expected.
opw 3701125
closesodoo/odoo#152498
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, it was possible for users to drop website snippets
(e.g., the "Badge" block) inside the inline form of payment acquirers.
At least for Adyen, it would prevent payments because the payment inputs
within the inline form wouldn't load anymore.
As inline forms are part of the payment form widget, which itself is not
customizable by users, this commit blocks the website editor inside the
entire payment form and its children elements.
opw-3607719
closesodoo/odoo#152469
X-original-commit: 814ee63956fce740b8cdae0a235351d8a9e6028d
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Summing discount percentages doesn't mean
anything.
This commit makes sure the operator used to
compute discount on group of records is 'average'.
It won't always be meaningful, but in some cases,
e.g. when the solines only hold one product,
and the lines are grouped by product.
opw-3649377
closesodoo/odoo#152455
X-original-commit: bf4aa3fdfcb6b2b3a5b4411130321e154fa098aa
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The opportunity is taken to fix an issue where removing a record from
assign would not update the inverse.
closesodoo/odoo#152442
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Steps to reproduce the bug:
1. Create a storable product "P1."
2. Create a quant for P1 with a package and apply.
3. Navigate to the package.
4. Attempt to unpack.
Problem:
A user error is triggered:
"Quant's editing is restricted; you can't perform this operation."
This occurs because when accessing the package from the quant, we are
in inventory mode. And as the "package_id" field is on the forbidden
list, the error is raised.
Solution:
During the unpacking process, ensure that we are not in inventory mode.
opw-3687164
closesodoo/odoo#151826
X-original-commit: 6d38d26de994e25b3b552c341bae27799ac63b38
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Currently, if a customer wants to edit his/her information from the
Portal access, they cannot modify the information linked to EC.
This commit aims to support Ecuadorian companies needed information when
editing the portal contact information:
- added "Identification Type" field
- renamed "VAT" to "Identification Number"
- make those 2 fields required
closesodoo/odoo#142730
Task-id: 3620196
Signed-off-by: Josse Colpaert <jco@odoo.com>
Currently the eCommerce workflow in Ecuador lacks some information
needed to issue EDI invoices.
The main adaptions needed are:
* Identification type and number in the checkout process (in the billing address)
* SRI Payment Method in the eCommerce Payment Method
SRI Payment Method
* The SRI Payment Method value is required for the EDI
* In the payment method form view the SRI Payment Method field is hidden
if the list of fiscal countries of the selected companies does not include Ecuador.
* Payment methods which do not have an associated SRI Payment Method
cannot be used in the eCommerce checkout of an Ecuadorian company.
* A (default) SRI Payment Method has been addeded to some payment methods to simplify the setup.
* When creating an invoice from a sales order we try to compute the SRI Payment Method as follows:
We consider all the SRI Payment Methods of the payment methods of the payment transactions associated with the sales order.
If there is exactly 1 such SRI Payment Method we use this on the invoice.
This should ensures that we can always set the SRI Payment Method on invoices created through the eCommerce flow.
task-3585823
Part-of: odoo/odoo#142730
In Ecuador, the ZIP code is not a required field to create invoices.
Customers usually don't even know their ZIP code as the street number,
city and state (province) are mostly used for delivery (and not the
ZIP code).
task-3585823
Part-of: odoo/odoo#142730
Confirming a repair order with parts assign moves quantities.
Ending it without any of the picked flags automatically pick them.
But ending it with some non-picked parts does not cancel the moves.
Now they are.
closesodoo/odoo#149157
Task: 3679247
Signed-off-by: Steve Van Essche <svs@odoo.com>
Before this commit, there was a race condition with the statusbar
field, and more specifically with useRecordObserver.
The issue could be reproduced in the form view of project.task. In
an existing task, belonging to a project with some stages, change
the project to another project with its own stages. It might happen
that the displayed stages weren't the ones of the newly set project.
If this didn't happen directly, this happened upon saving (i.e. the
correct stages are displayed just after switching the project, but
as soon as the user saves the record, the former stages are back).
This happens because useRecordObserver used an outdated version
of the props to get the domain (i.e. the props of the component
have been updated, but useRecordObserver still used the old version,
in particular the old props.domain).
This commit fixes the issue by ensuring that we always use the last
version of the props.
opw 3693113
closesodoo/odoo#152433
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Purpose
=======
From O.6 to 0.04 seconds to call get_allocation_data_request (15x faster)
and 574 to 25 requests for an employee with 10 years of XP in odoo.com.
Part-of: odoo/odoo#152311
Before this commit, discrepancies between
leaves and allocations for an specific employee
and a specific time off type would have prevented
the employee from taking any time off for that
time off type.
It would also affect their dashboard.
__How to reproduce the issue:__
- time off type without negative amount
- create 2 allocations: last year and this year
- create a leave last year
- remove last year allocation from DB
- you cannot take leaves this year
- dashboard amount is affected by last year's leave
__Changes brought with this commit:__
This commit keeps the logic identical for negative
time off types. However, for the others, the
check ensuring the allocation validity for the
leave will now check the discrepancies before and after
a time off creation or modification. The error
will be thrown if the discrepancies have changed, meaning
that the leave had an effect on it. This way, any
other issue will not prevent leave creation.
Those leaves are still noticeable through the warning
though, meaning that they can be noticed and dealt with
accordingly.
Part-of: odoo/odoo#152311
The address displayed as 'Invoicing address' was
the main SO address and not the invoicing one.
Also, the pencil icon link to update the customer main address
was always displayed next to the invoicing address, even if:
* the so does not belong to the customer
* the invoicing address is different than the
customer main address
This commit fixes those two issues.
opw-3653190
closesodoo/odoo#152298
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The total amount is computed by adding the order amount and the delivery amount. The order
amount was provided as a string, and the computation didn't convert it to a number before
adding it to the delivery amount. As a result, the amounts were concatenated instead of
added, yielding an incorrect result.
opw-3614909
opw-3664682
closesodoo/odoo#152416
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Appending strings within a `t-out` for a website template makes it so
that it can never be translated. Instead the string should be written
like normal text so that it is correctly seen as to be translated and
`t-out` only the next step so that it's also correctly matched as to be
translated.
opw-3700815
closesodoo/odoo#152312
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Steps to reproduce:
1) Try to make a payment with the amount less than 0.50$ (minimum amount
required in Stripe)
2) Stripe inline form fails to load
3) One can still click pay and see the traceback
After this commit the error are handled and displayed on the form
loading and on the form submit.
opw-3634316
closesodoo/odoo#152307
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
In order to better analyze profitability, we added an extra measure to
the Invoice Analysis report to show the "Margin" on every invoice line
based on the product cost price.
In order to have a simplified inventory valuation without fully using
the Inventory app, we also added an "Inventory Value" measure that also
uses the product cost price to show the change in inventory value based
on incoming and outgoing accounting documents.
An extra filter "Inventory Valuation" was added as well to show the
"Inventory Value" values per storable product and per month.
task-3708415
closesodoo/odoo#151805
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
With Kenya localization installed
Create an invoice
Send&Print
Issue: The sytem will issue the final pdf before the invoice has been
send to the fiscal device, so the legal information is actually missing
Solution:
1. If the allow_fallback_pdf is True (in case of transaction from the
e-commerce for example) we generate a proforma pdf invoice.
2. Else we raise an error to prevent the user to send invalid invoice.
Also added a warning to let the user know that a proforma will be
generated because the invoice was not sent to the Fiscal Device.
opw-3599869
closesodoo/odoo#151751
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Co-authored-by: Claire Bretton (clbr) <clbr@odoo.com>
Force post does not work in the validate account move wizard.
Steps:
- Create a move in the future and set it to be auto post
- On the list view, select the move and select action "post entries"
- On the wizard, check "force" and validate
-> UserError "This move is configured to be auto-posted ..."
closesodoo/odoo#152396
X-original-commit: f85f3bcc026882b2a088fcd46ca8e6dc59d6f2f0
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Thanks to changes in 82314364c6029a83 the auto-lock settings
also works for public users. But, going from self.env.user to
self.create_uid to check the group lead to a traceback when
self.create_uid is not a singleton. This is because has_group expects
a single record.
To fix that, this commits checks the group of the create_uid of the
first record in self. Because sale.group_auto_done_setting is an
implied_group of a res.config.settings parameter, it's enough
to only check for the first record in the recordset.
To reproduce:
- Install sale
- Create a quotation as Mitchell Admin
- Create a quotation as Marc Demo
- Create a cron that searches on all draft sale.orders and confirm them
in batch
- Run the cron
-> Singleton Error
closesodoo/odoo#152338
X-original-commit: dfb2eaaaf5c08c0aa46cc5eb0defdc97b35953b0
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Aurélien van Delft (avd) <avd@odoo.com>
Maximilien (malb)