Reproduce the issue
- Install eCommerce
- Activate stripe, use testing credentials and select
Configuration > Payment Flow > Payment from Odoo
- Create a contact that has a trailing whitespace at the beginning
of the email
- Grant him portal access, and a password
- Open your browser devtools
- Login to the web shop with this portal user and buy an item using
stripe
1. Error Dialog: Server Error (HTTP 500)
2. The exception received by the front-end is not clear
3. When the 500 error is fixed, we still have a error dialog
=> bad UX
Cause
1. The raise was removed but we need to keep it because
it allows the true error to be raised (bad request)
2. The "invalid email address: x" is lost when we raise the
exception
3. In V13, all catch & guardedCatch open a error dialog if we
don't set preventDefaulted to true on the error's event
This commit changes restore the raise, change the error message and
disable the error dialog for this case.
OPW-2126196
closesodoo/odoo#41087
X-original-commit: b8d013285ba54c8d3ab4a3857604dfca3e479b39
Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>
This commit adds support for displaying 'VAT' field in a 'contact'
widget used in qweb views.
This commit also does the necessary changes needed for behavior
improvements of report editor in studio. For more information,
see https://github.com/odoo/enterprise/pull/6543 or task pad.
task-1904639
closesodoo/odoo#39722
Related: odoo/enterprise#6543
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Adapt calendar highlight option (that "highlight" event linked to the
record we come from) to current JS framework data structures.
note: this changeset also fixes the original `_compute_is_highlighted`
that was would trigger CacheMiss errors, and also adds back the CSS for
highlighting that was lost between 12.0 and 13.0 version.
opw-2131494
closes#40791closesodoo/odoo#41077
X-original-commit: da56e3e7036ecdb3905f4152778e853e080e0163
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
tax name suggest 10 but code 20, history tells 10 is right, fixed code
two children taxes are now orphans, kill the orphans
closesodoo/odoo#40825
X-original-commit: 28e74fafec4cec3179db330a1ededf4ef8677fbc
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Reproduce the issue
- Install eCommerce & Sales
- Create a quotation
- Preview
- Switch to french on the website page
- Click on "Signer & Payer"
There is a lot of things not translated.
Cause
On the website, the route `/website/translations` is called.
The route calls a method `_get_translation_frontend_modules_domain`
which teturn a domain to list the domain adding web-translations and
dynamic resources that may be used frontend views.
The missing translations are in the web module and the module is not
loaded by the method.
This commit adds the `web` module to the domain and a missing
translation for the portal module
OPW-2120397
closesodoo/odoo#41072
X-original-commit: 50c2ecbc9ef0e446af0a1d4010ec1d923aa41bec
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The invisible fields are not there for the fun...
closesodoo/odoo#41066
X-original-commit: e26946c5da9aa3a656e3368ec98e9806b2c7ba54
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The miscalleneous journal entries has displayed in the tree view with
a negative amount in amount_total_signed that has no meaning.
X-original-commit: 4a7dcb4027ee93448b2d15cc262b8c2fb5d531db
The reason is the invoice_payment_state is tracked by the chatter and displayed
when the field is recomputed during the 'post'. However, this field has no
meaning in a Miscellaneous Journal entry.
X-original-commit: e0a0d06c7aa0acbc3c37b9a108fa5d67042c0438
In the Mexican Localisation (l10n_mx), there is a "custom" behavior
made when there is more than one payment term lines.
Before the account-pocalypse, the receivable lines having a balance equals
to zero was ignored.
This commit aims to restore this behavior and then, fix l10n_mx.
--issue: 2121973
X-original-commit: 6a4f9a2666b7414d208248da52862428c04bb4a6
This commit applies the following ACLs rules:
C : nobody can create visitor (except system)
R : everyone that should access to this model
U : website_designer can update (even if only few fields are editable),
mainly useful for language (+ system obviously)
+ livechat users as they are the guys who directly speaks with the visitors
D : system + website_designer can delete, mainly useful to clean if necessary
Remove the no_create from all visitor views as handled by ACLs.
This fixes the 'can create' that should not be done by any users
except system + admin
Task ID: 2092502
PR #40439closesodoo/odoo#40865
X-original-commit: 23f3324830adf31edb0a12c7009fcb65b0f54614
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
{ As the SEPA BIC is no longer mandatory we simplify bank creation removing constrains about BIC }
As of 01/02/2016, the BIC is no longer mandatory, you can see the page 25 ==> https://www.febelfin.be/sites/default/files/2019-04/standard-xml-sdd-initiation-_v4.1a-en.pdf
As a result, in order to simplify both the code and the process, we don’t want anymore constrains about that.
task : https://www.odoo.com/web#id=2056370&action=327&model=project.task&view_type=form&menu_id=4720
> We don't need BIC for both the company iban bank account or customer/vendor iban bank account
> If a vendor bill is linked to a valid IBAN bank account without BIC, show the QRcode (remove the BIC constrains )
> CREATE A SDD mandate should be possible without BIC (for both the company iban bank account or customer/vendor iban bank account)
> Create a SCT payment should be possible without BIC (for both the company iban bank account or customer/vendor iban bank account)
> Add a country group for SEPA zone
> Add IBAN country codes for each country in base_iban module
> Only display qr code when making a payment to an IBAN account whose country code corresponds to a SEPA member
> in account's post init hook, install SEPA modules if the country of the company belgons to SEPA zone (instead of Europe, as it is now)
closesodoo/odoo#40356
Related: odoo/enterprise#6738
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
If Company Tax Representative of the seller is not having a VAT number,
which is mandatory, system won't allow to validate the invoice.
closes odoo/odoo#34511
Task: 1971512
Closes: #34511
Signed-off-by: Josse Colpaert <jco@openerp.com>
We have a problem about the opening journal entry because we set the account
move name to "Opening Journal Entry" and it's not compliant with our policy
about the account move name.
We often check the account move name to know if the move has consumed a number.
And we cannot check it correctly for the opening journal entry.
closesodoo/odoo#38957
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Purpose:
In V13, you can reset to draft a posted move if this move isn't in
a hashed journal. But it's little bit dangerous and we want to
track changes for some fields.
It works for editing in editable list view and form view.
Task ID: 2061399
Reproduce the issue
- Select a language (done by default)
- Install Project
- Create a project
- Create a task with a formatted date
- Reset the language
- Go on the project
Traceback
Cause
In 7e42c663, I format the date_deadline based on the user's language
but did'nt know that we could have no language selected.
This commit uses the `format_date` method from `odoo.tools.misc`
which fallback on the first language installed if there is no
language selected.
OPW-2146479
closesodoo/odoo#41057
X-original-commit: 7d06135712b6646816b0558a63e55bc10622e59c
Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>
- Create a picking type with specific default locations, for type
Manufacturing
- Go to Inventory, click on the 'To Process' button
- Create a MO
The default locations are not taken into account.
This is because the default picking type is not in the context.
opw-2128182
closesodoo/odoo#41049
X-original-commit: 6f7cbedd0ad252352209391501ba8971f7e90d00
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Enable units of measure from Settings.
Go to Point of Sale, enable "Invoicing" from the PoS, open the session,
sell something specifing customer and invoice. Close the session and
post.
Check the sale order, UoM is specified. Now check the associated
invoice, UoM is missing.
This is because the UoM is not propagated from the sale order to the
invoice. Adding the missing value
opw-2129428
closesodoo/odoo#41040
X-original-commit: 2d5f22f040e7d28a17191cd6cc512b58b929efa1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Exceptions were logged to stderr so we couldn't see them when Odoo was
running as a service on the IoT Box. We now redirect stderr to the logger
to see track errors in the log file too.
closesodoo/odoo#41028
Taskid: 2146835
X-original-commit: 54a1919cbc37f5832ce110605c29b222c7a5bfe9
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
Customer displays were all using the same URL and therefore could only
show the same products. We now use different URLs per screen.
Two screens connected to the same IoT Box can now display customer
displays from different POS.
closesodoo/odoo#41026
Taskid: 2123511
X-original-commit: 12569b0e7f7a9e447f8df908597131911c5cfef8
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
We now support the RPI4 which has 2 micro-HDMI outputs, while the
prvious driver only supported one display. We add support for a second
display.
Taskid: 2123511
X-original-commit: 5886c3a864c990fcd7b852baafab752e7da90494
Steps to reproduce the bug:
- Let's consider two companies C1 and C2
- Let's consider website W
- Activate multi-company
- Disable common contact book and common catalog
- Switch the superuser in company C2
- Activate pricelist
- Create a public pricelist PL for C1 and available on W
- Set up a pricelist with compute price = formula and based on = cost
- Go Sales > Configuration > tick Multiple Sales Prices per Product and tick Prices computed from formulas
- Create a portal user PU and set PL on him
- Create a product P with cost = 10$ and publish it on W
- Set up the product valuation as: automated
- Log as PU and go on the shop
- Put P on your cart
Bug:
The price of P was 0$ instead of 10$
opw:2092695
closesodoo/odoo#40981
X-original-commit: 40d3fa50e3d9a0e1cc0077cc8dcbe052ffa9820f
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before this commit, the export of translations was incorrect for code
and model translations:
For code translations, the field 'name' was used for the matching
while the _() method explicitly use None in the _get_source call to
only use the field 'src' for the search.
For model translations, the field 'res_id' was not used when searching
for a translation.
For instance, if a ir.model.fields did not have translated label,
exporting the translations was using the translations of the first
field having the same source.
While this could be convient during the import (to be discussed),
doing so in an export of translation is clearly an unexpected
side-effect.
closesodoo/odoo#40909
X-original-commit: 4534181f106cf5aa50c65c942c260eeec122d3d2
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When we add a user to employee, we can have problem with leave,
expense or coach manager. It's due to those compute fields.
closesodoo/odoo#40795
Related: odoo/enterprise#6865
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Create analytic account from fleet (and link it to vehicle) based
on the plate and the fiscal deduction rate (if l10n_hr_payroll_fleet
is installed).
Add on employee a Mobility Card number. This number is set on vehicle
when we put a partner linked to employee on a vehicle.
taskID: 2127641
Task 2092104
Accounts group Hierarchy should be automatically well done without to
have to specify the parent (based on the account group CODE)
Before, we had to set all the accounts in the correct groups manually
and it was cumbersome.
Now:
* No need to fulfill account group parent
* No need to fulfill account group id on account
We can still change the groups if there are exceptions; the groups are
only set at create and write time.
This commit adds possibility to select a layout for certification rendering.
User can choose among 6 predefined layouts carefully designed and that should
cover all use cases, therefore removing any need of allowing customization.
It also adds possibility to preview certification directly from survey.
closes odoo/odoo#32675
Task: 1967652
Pr: #32675
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Stefano Rigano <sri@odoo.com>
Co-authored-by: Quentin Mourier <qmo@odoo.com>
Changing a product type from consumable to storable and and vice versa can
make the quantity in stock confusing. As only storable product update the
stock quants, the amount on stock moves could be diffenrent that the one
on stock quant if the product type has been changed in the past.
This commit will make those changes saved in the chatter history in order
to easily track inconsistencies
closesodoo/odoo#40997
Opw: 2125124
X-original-commit: 7c330b4443043dede13f76c034e2a2c5e53cbdee
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
-previously, in the mobile view, while accessing Manufacturing
orders from the dashboard in inventory, the default view was
set to tree. changed it to be kanban instead.
-Same in case user tries to access WO from dashboard when there
are none and user is redirected to MO.
Task-2127508
closesodoo/odoo#40857
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Purpose
========
Change www.yourcompany.com default link for the 'Website'
field of the res.company and res.partner to 'www.example.com'
closesodoo/odoo#40727
Taskid: 2129147
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
A customer reported a problem when he deleted a language on the
website app.
In some cases, if you go on the odoo's generated website as a public
user let's imagine the following url: website.com/en_GB
The lang is saved in a cookie and sent to the context.
If you delete the language from the website languages (without
deactivating it) and you go on website.com as a public user,
the method will try to use the context or the cookie value which is
'en_GB' and it crashes.
This commit makes sure that the language is available
OPW-2129580
closesodoo/odoo#41007
X-original-commit: f3e9ca13f60ced0ec61cea0d13da45b2569da14e
Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>
- Set the computer TZ so that it is UTC day + 1. For example, set to
'Australia/Adelaide' and perform the tests after 3:00 pm
- Go to Account > Customers > Invoices
- Set the Invice Date to today in the TZ
You receive the warning 'This date is on the future...'
The comparison of a UTC date without time `currentDate` is inconsistent
with `moment()`, which is not UTC and has a time set.
After playing around with `.utc()` and `startOf('d')` with no luck, we
decided to give up the idea of making `getTZOffset()` enter the game and
simply compare the string formatted values.
opw-2093186
closesodoo/odoo#40984
X-original-commit: f9eec97cb128f71796fca0116841453555ab4684
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
If avaliable will use the stdnum.ar.cbu.validate functionality, if not
we defined our own validate method.
closesodoo/odoo#40998
X-original-commit: 9c389525e1c334505c8edf7276826c1b37ae0a1c
Signed-off-by: Josse Colpaert <jco@openerp.com>
Updating the quantity to produce in a production order will recompute
each raw move's unit factor. The issue was this computation did not
take care of the previously product quantity. The unit factor was wrong
and so the next created workorder lines get the wrong quantity.
Example:
- 1 components for 1 finished product (unit_factor = 1)
- Create a production for 2 finished product -> quantity to consume = 2
- Produce 1 then change quantity to produce to 3 -> quantity to consume = 3
and quantity done = 1 but unit factor became 1.5
closesodoo/odoo#40990
X-original-commit: 79976600df45afc6150150734eef405fd41a70a3
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When creating sale order lines from the matrix (sale_product_matrix),
the purchase_price weren't computed
No cleaner change has been found to ensure the cost is computed.
Triggering all onchanges from the server side is quite tricky and dirty
to do...
closesodoo/odoo#40986
X-original-commit: 5c15b1310729129e390b455b0d1e0ac367f8dd69
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
as we cannot do the test in product_matrix, add the purchase equivalent
in purchase_product_matrix to also test the matrix in this case.
X-original-commit: 9d7024a5327939de3c145928782936000d26bd33
Jason Van Malder