This commit fixes an issue where the "No records found" helper text is
wrongly positioned below the sample data's records (i.e. not visible)
instead of over them.
This is basically a revert of 9407383a56
due to the changes in the DOM and styling made in the meantime.
But actually we can go further and ensure we always have the ListView's
table present in the DOM. This change allows to simplify the positioning
of the helper and the implementation of the Purchase's dashboard.
Steps to reproduce:
- create a new database **without demo data**
- install "Planning" and "Sales" apps
- with a mobile-like screen size, open Planning
- switch to Gantt view
- in a cell, click/tap on the magnifier button (which is on hover...)
- the many2x view doesn't contain data
=> action helper "No records found" isn"t visible (scroll to bottom to
find it)
closesodoo/odoo#112878
X-original-commit: 766498a36b322ffe9c647616f56f3ba04cc51d96
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Let us have records with values 1, 0, 77, 3 for a float field 'foo'.
read_group allows to get those values in an array with the aggregate
function array_agg:
read_group([], ["foo:array_agg", ...], []) will return
[{ __count: 4, foo: [1, 0, 77, 3], ... }]
We now support the use of array_agg for integer and float fields in
the mock server.
closesodoo/odoo#112825
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
mockReadGroup should not count the value false for a many2one when
aggregating a many2one field with the aggregate function count_distinct
and should always return a number. We fix that.
Part-of: odoo/odoo#112825
Let us have records with values false, 1, 2, 1, 1 for a many2one 'm2o'.
read_group allows to get those ids in an array with the aggregate function
array_agg:
read_group([], ["m2o:array_agg", ...], []) will return
[{ __count: 5, m2o: [null, 1, 2, 1, 1], ... }]
We now support the use of array_agg for many2ones in the mock server.
Part-of: odoo/odoo#112825
-The stock valuation, input and output account were wrong. Now correct accounts are set
-Removed the 6% VAT. Is not used for years now in the Netherlands. It is now 9%
-Removed the "BTW overige" for sales/purchases within EU and outside. These taxes do not exist. "BTW overige" is only domestic
-Renamed 'EU landen privaat' for better name B2C (that is what it is used for)
-Added valid TAX Identification number on company
-Changed the state to a state within the Netherlands and not in the Dutch Caribbean
closesodoo/odoo#112493
Signed-off-by: John Laterre (jol) <jol@odoo.com>
This commit is a refactoring of the domain selector to simplify it.
The component DomainSelector now uses less sub components.
Consequently, the code is centralized in fewer files and more readable.
closesodoo/odoo#110978
Task: 3149707
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Following up https://github.com/odoo/odoo/pull/112692 that avoided the use
of the 'Number' javascript function in the 'product_discount_field' widget, the
call to that function was left in the code. It is useless and can be removed
since the value of the new field used, the property field 'props.value', is
already a float.
closesodoo/odoo#112891
X-original-commit: fb8b217f8bd2323d33bbeb949f35cd1620557960
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
`handle_error`'s docstring states that it returns a `Response`, but in most case `HttpDispatcher.handle_error` returns an `HTTPException`.
After discussion, the implementation is correct, `handle_error` should be documented to return a WSGI Application (a callable taking an `environ` and a `start_response` callable) instead.
closesodoo/odoo#112889
Forward-port-of: odoo/odoo#112690
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
If you have a lot of attendance spread accross various employees and various dates,
the report takes ages to load (or your browser freezes and you can't access reporting).
And if it loads, the report is unreadable anyway. Use a default filter to always
display user friendly graphs. Since we group by day, a default period of a month seems
like a good compromise.
To reproduce the issue:
- install hr_attendance
- use a script to create some attendances (ex: create 300 employees and 30
attendance for each, spread randomly in the last 3 years)
- click on "Reporting"
opw-3167099
closesodoo/odoo#112879
X-original-commit: 59bf5d4c5e7c95c6f561140f71634d84a12568a0
Signed-off-by: Kevin Baptiste <kba@odoo.com>
To be able to compute the taxes offline, the POS JS code mimicked the
`compute_all` function in `account_tax.py`. At some point, the POS added
an extra field on `account.tax` (see:
https://github.com/odoo/odoo/commit/8fb53c53c3128e8cea7ef20b9ab4946ac2f9b7d9):
`real_amount` which is defined as:
real_amount = tax.amount * sum(tax.repartition_line.factor)
Then, when fetching the data from the server to the client, the
`real_amount` was passed in place of the `amount`.
But then, the `amount` field in the JS is no longer the same as in the
python code and it is very error prone. In addition, it's easy to get
rid of this extra field by using the sum of the factors from the
repartition lines.
Now, we pass the sum(tax.repartition_lines.factor_percent)/100, which is
equivalent to sum(tax.repartition_line.factor) to the client, and use it
in the `compute_all` as done in the python function, and leave
`tax.amount` untouched.
Both `compute_all` functions now operate using the same `tax.amount` and
we get rid of the `real_amount` field.
closesodoo/odoo#112063
Related: odoo/upgrade#4307
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Before this commit, the field's description was stored on the
component and this component was then registered.
Now, an object describing the field is used on registration the same way
as it is done for views since https://github.com/odoo/odoo/commit/b828cfc72c587d0b73fcc5459695705640437671.
This split the component's description (props, template, ...) of
the field's description (displayName, supportedTypes, ...) and makes
it clearer.
closesodoo/odoo#112498
Task: 3171520
Related: odoo/enterprise#37105
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When validating a confirmed picking, if in the meantime the user
added an SML with a kit, the done picking will have some not-done SM
for each kit component.
To reproduce the issue:
1. Inventory > Operation Types, edit Receipts:
- Show Detailed Operations: True
2. Create three products:
- P_kit
- P_compo
- P_other
3. Create a kit BoM
- Product: P_kit
- Components: P_compo
4. Create a planned receipt R
- Operations:
- 1 x P_other
5. Mark R as todo
6. Add two detailed operations:
- 1 x P_other
- 1 x P_kit
7. Validate R
Error: The SM for P_kit has been replaced with its component, which
is correct. However, the done quantity of the new SM is 0, it should
be 1
At some point, because the done quantity of SM_kit is gerater than
the demand, we create an extra move:
https://github.com/odoo/odoo/blob/24f2e3f73498e5eb180a6793de6c25efd414aadb/addons/stock/models/stock_move.py#L1529-L1534
So, the goal is to create a second SM_kit_02 with the expected
demand. Then, we merge this new SM_kit_02 with SM_kit:
https://github.com/odoo/odoo/blob/24f2e3f73498e5eb180a6793de6c25efd414aadb/addons/stock/models/stock_move.py#L1491-L1493https://github.com/odoo/odoo/blob/5f8da70b5b1f313e9b676846e55e84621f55e734/addons/mrp/models/stock_move.py#L239-L242
As shown above, we explode SM_kit_02 which gives SM_compo. However,
we don't explode SM_kit. Thefore, we will not be able to merge
SM_compo with SM_kit. In such situation, we should also explode
`merge_into`.
For the explode method to work with SM_kit, we need to change few
lines: as said at step 4, the receipt is not an immediate one.
However, we still have a case here where the SM has a quantity done
without any demand and only the done quantity matters (as we are
validating the receipt)
OPW-3015933
X-original-commit: 35a5b83b93fceac4073689edd74d680bed09a143
Part-of: odoo/odoo#112814
When manually setting a discount on the first line of a sale order having more than 3 displayed lines, the product_discount_field widget prompts the user if he would like to apply the same discount to all the lines.
This fails to apply when the localization uses a comma as decimal separator instead of a dot or uses a digit grouping symbol. This is because the widget calls the JS function Number() on the string that was entered by the user in the discount field, after it was formatted according to the localization.
Taking the number 1500 as an example, different cases are:
- Number("1500.0") gives 1500
- Number("1500,0") gives 'NaN'
- Number("1,500.0") gives 'NaN'
- Number("1.500,0") gives 'NaN'
This result is then used to apply the discount on the remaining lines of the sale orders. Using 'NaN' will result in a 0% discount.
The use of Number() can be avoided by using the property field 'value' of the product_discount_field widget.
opw-3127690
closesodoo/odoo#112734
Forward-port-of: odoo/odoo#112692
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
By adding an explicit order to the queries within `existing_accounting` the PostgreSQL query cost drops to `cost=0.84..1.78 rows=1 width=4` from `cost=13061.20..18895.19 rows=1 width=24` (on my local dev machine).
closesodoo/odoo#112842
X-original-commit: ab34d6b0273c6766757f0596ca5f62458a9d5ab5
Signed-off-by: John Laterre (jol) <jol@odoo.com>
The date from would not be formatted on leaves spanning multiple days.
closesodoo/odoo#112830
X-original-commit: 7a392e9af999084d9dddf0f82affd6d539f5d907
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Werkzeug 1.0 colorised some outputs on POSIX IFF `click` was
installed.
Since 2.0 (pallets/werkzeug#2012) werkzeug unconditionally colorises
the log on POSIX. This is annoying when using output redirection (let
alone logging to a non-stream), as werkzeug will dump ANSI color codes
to the non-term stdout and thus the logfile.
Werkzeug provides no official knob to control this behaviour, but it
does have a secret flag which is normally used to check if colorama is
available on windows (so the ANSI codes are not output if colorama
won't be interpreting and stripping them on the way out). Since
`werkzeug.serving` is available in pretty much all versions, we can
just (un)set this flag if not logging to a tty, and versions 2+ should
pick it up and disable colorisation.
closesodoo/odoo#112829
X-original-commit: 7c9f883dc508a7a8a45bf7bf7e900da0be9b34be
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
*: base, http_routing, mass_mailing, web, web_editor, website_slides
In some situations `werkzeug.wrappers.Response` are used instead of
`odoo.http.Reponse` that extends it.
This is a problem because since [1] the calls to `set_cookie` expect it
to accept the `cookie_type` parameter, which is not the case in the base
werkzeug implementation.
This commit replaces the `werkzeug.wrappers.Response` by
`odoo.http.Response`.
[1]: https://github.com/odoo/odoo/commit/2cbda6c98ee947cea1d06c09880eee8c758304a8closesodoo/odoo#112827
X-original-commit: 28da08292b7028575e628c5ad846fc05d30498f2
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Since commit (1), the write/writeText were no longer correctly called,
because the browser native functions couldn't be called. Sometimes, it
raised the "Illegal invocation..." error, or could have an unexpected
behavior, preventing the value to be copied in the clipboard, which made
the button pointless.
No additional test was added, since it is difficult to test the clipboard
API programmatically, and the current test coverage is all that we can do,
without using the real clipboard object.
(1): 9cdcd1c1f7219030386d2c90205ea083eb835a13
closesodoo/odoo#112843
X-original-commit: 767922d43334a6cbccdb4be64f207813240fd314
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
repro steps:
1) in any kanban view that is not grouped, use the arrow key to focus the last card
2) use the up key to focus the previous card
3) use the TAB key to focus any element inside that card
4) use the down key to try to navigate to the last card -> traceback
The error comes from the fact that `focusNextCard` assumes that the
focus is exactly on the card element and not on any of its children.
closesodoo/odoo#112797
X-original-commit: 76434f4959cd0fade41ad02f790226f1a8046fea
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit removes the legacy CustomCheckbox and the backward
compatibility layer for the systray items. Both of them are no
longer used.
closesodoo/odoo#112718
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
This commit fixes the wrong label that was displayed when options
are defined inside groups. Since displayValue was only looking for
a label on choices set using the choices props, the getter was only
returning the technical value for choices defined in groups.
A test has been modified to verify that the correct label is shown,
also on choices present inside of a group. This test previously
asserted that, but only on choices given by the choices props.
closesodoo/odoo#112766
X-original-commit: 176e61d5c25111a1e9339a0687bb526d1d430790
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Luca Vitali <luvi@odoo.com>
Bug
===
The unlink of the <mail.mail> in the CRON is problematic because we
accumulate a lot of records, and the CRON timeout.
In particular, when we sent a mailing, we receive the "opened" event
(blank image in the email), and so we need to update the mailing trace.
But, if we unlink the mail at the same time, it locked the mailing trace
table and we couldn't write the new value.
The reason for that is that before, the unlink took more queries, but
it was done one record at a time, so we could commit the change and
release the lock between each unlink.
Task-3179157
See odoo/odoo/pull/73271
closesodoo/odoo#112331
Related: odoo/upgrade#4320
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The PR #105579 introduce the call of `setupCollaboration` in
`resetEditor` but did not remove the instructions in `resetEditor`
that will be called in `setupCollaboration`.
`this._getNewPtp` should be called by `setupCollaboration` as it is
called after an asynchronous call.
Additionally, `this._peerToPeerLoading` has to be awaited to prevent
concurrency issues.
closesodoo/odoo#112253
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
With this commit, we add the shipping address
to the invoice report when it is different from
the invoicing address.
We do the same way as in l10n_din5008_sale/models/sale.py
and l10n_din5008_purchase/models/purchase.py,
by adding the computed field l10n_din5008_addresses
in account_move.
Steps:
- Insltall l10n_de and sale
- Set Customer addresses in settings
- Ensure that DIN5008 is set as document layout
- Create and confirm an invoice with delivery
address different than invoicing address
- Print or preview invoice
-> Shipping address does not appear on report
opw-3090418
closesodoo/odoo#112740
X-original-commit: 36731269ccd4ae8ca6d6078f7f9d6760381a5beb
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Bug
===
The unlink of the <mail.mail> in the CRON is problematic because we
accumulate a lot of records, and the CRON timeout.
In particular, when we sent a mailing, we receive the "opened" event
(blank image in the email), and so we need to update the mailing trace.
But, if we unlink the mail at the same time, it locked the mailing trace
table and we couldn't write the new value.
The reason for that is that before, the unlink took more queries, but
it was done one record at a time, so we could commit the change and
release the lock between each unlink.
Task-3179157
See odoo/odoo/pull/73271
closesodoo/odoo#112703
X-original-commit: 57ae1b9b8b61f5f4719a8a81e9d0d21fab58cfda
Related: odoo/enterprise#37069
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Steps to reproduce the bug:
- Get the website module.
- Go to Settings > Website > Shipping.
- Activate "On Site Payments & Picking" and save.
- Go to the same setting again and click on "Customize Pickup Sites".
- Pick the only delivery method that exists.
- Inside the delivery method, select a warehouse of the current company
and try to save.
Issue:
We won't be able to add a warehouse as the hidden field of the
`company_id` is not set.
Solution:
We modified the if statement inside `_check_warehouse_company` in order
to accept companies.
opw-3097424
closesodoo/odoo#112696
X-original-commit: dc8c24a5ace17382f54ad256b0ef585e24bca7ca
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
The redirect function in the router exists only for the wait option.
This option is only used in one case (client action home). We have
therefore decided to remove the redirect function and to call
browser.location.assign(...) directly.
We will also remove the "wait" param for the "reload" and "home"
client actions. Because no call to "reload" needs it (1) and all calls to
"home" want it wait=True. So we will move the code that was executed
if wait=true to the "home" action client.
(1) In the POS, wait=true is used for a "reload" but this has no impact.
Wait=true was intended to wait for the server to restart before reloading
the page. In the case of the POS, there is no restart of the server, so
wait=True is useless.
closesodoo/odoo#112621
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Previously, the resize behaviour and the draggable behaviour were
completely separate, even though a lot of the logic for both behaviours
is common to both. This commit replaces both of these behaviours with a
hook: useMovable that lets the user drag an object around, but lets the
caller customize the behaviour on drag: when dragging a table or the
debug menu, we want to move the object around by setting its position in
its container, but when dragging a resize handle around, we want to
resize the table while keeping the handle position in the table the
same.
This commit also makes a bunch of popups non draggable as it doesn't
make sense for them to be draggable: you cannot interact with the
content behind the popup for as long as the popup is open (unlike the
debug menu), and serves no functional purpose, and may occasionally
confuse users.
closesodoo/odoo#112610
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Some changes were made to the default/demo/test data to be more
consistent:
- Duplicates of "Paid Time Off" time off types are consolidated into
one type (inluding year specific versions, ig "Paid Time Off 2019"
- Annual Time Off is renamed back to Paid Time Off (both for the
work entry type as the time off type) to be consistent everywhere.
- All mentions of years in work entry types and time off types have
been removed, as this is no longer relevant with the new allocation
rules.
- Time off types in the default data have been explicitely made
company agnostic, in order for them to be available to all companies
and not just the one company that was select when installing
hr_holidays. This was already the case for the be_payroll data, but
not for the standard hr_holidays ones.
- Various small cosmetic / functional fixes and simplifications
(eg deduplication of data)
- expense_other_input has been made country agnostic, in order for it
to be available in all countries.
task-2978513
closesodoo/odoo#112208
X-original-commit: dcc8bbf
Related: odoo/enterprise#36819
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit, when obtaining link URL suggestions, both the
specific and the matching generic page were suggested.
After this commit, only the most specific ones are kept in the suggested
list.
This commit also adapts the sitemap in the same way.
In stable, a condition on a dedicated context key is used in case those
methods were called with the goal of obtaining both generic and specific
pages.
In 16.0, those methods will always filter duplicates pages as it was
supposed at first.
Steps to reproduce:
- Edit Contact Us page (to create a specific view)
- Edit the Contact Us menu
- Type "/" in the URL
=> "/contactus" appeared twice.
task-2968292
closesodoo/odoo#112746
X-original-commit: c5a50362ef55ced373c53c7af069fd5534043ae2
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
With this commit, when importing an account,
we post the opening move only when importing
opening balance field.
Steps to reproduce:
- import a coa template
-> an opening move has been created and posted
- import an account
-> Error: The entry MISC/XXXX/XX/XXXX (id XX) is already posted
Issue happened because we try to post the opening move
when entering in the account_account.load method.
With this commit wemodify and post the opening move only
if we try to import this field.
opw-3105083
closesodoo/odoo#112739
X-original-commit: 27ef0b93770c4e358a8cf4082afcfeb2da96f6c6
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Current behaviour:
In the eCommerce, if you add a product that has a sale description
(properly translated) in a website that is set in another language
than the default for the company, the description of the product in
the shopping cart was the default for the company, not the one set
on the website.
Expected behaviour:
Product description language should follow the website's language,
in both the eCommerce, and in the shopping cart.
Steps to reproduce:
- Install eCommerce
- Add a second language of choice and add it to the website
- On a product add a sale's description in both languages
- Logout, go on the e-shop on your product, switch the website to
language 2
- Observe that the language of the description is indeed language 2
- Add it to cart, go in the cart.
- Observe that the language of the description is language 1, not 2.
Reason for the problem:
Since the cart is a `sales.order`, and each item in it is a
`sale.order.line`, we use the language of the partner for the
description. But by default the language of the public user is the
same as the company, not the one from the current context, which
would be the one from the website.
Fix:
We don't take the language of the partner, if that partner is the
`public user`.
Affected versions:
- saas-15.2
- 16.0
- saas-16.1
- master
opw-3142666
closesodoo/odoo#112738
X-original-commit: 2b0c52e08c35607c9ad75b491978231037a1340c
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
The employee should be subscribed to their own record in order to
receive communication send to them.
closesodoo/odoo#112736
Taskid: 2749585
X-original-commit: 43d99b06a792a39aa14b7afb8b48aa79c2da2737
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Very similar to the usecase in commit dafe732e6874fbdd15dfd213b5c5c0cde93e534e
Steps to reproduce:
- Install Accounting, Sales, Stock
- Create a product category PC:
- Costing method: FIFO
- Inventory Valuation: Automated
- Create a product P:
- Type: Storable
- Product Category: PC
- Create a Sales Order SO with 1 x P at cost 10
- Confirm delivery
- SO > Create Invoice > Post
- SO > Return the delivery
- Change product price from 10 to 6
- SO > Create Invoice (!!)
- The invoice will be marked as a credit note automatically
- Post the invoice
Issue:
The product is listed in the journal items, which is correct,
but its value is 6 while it should be 10.
If we create the invoice from the Sales Order instead of adding a
credit note, then the move lines will not be considered reversed,
since they do not have an associated invoice.
Solution:
Consider the move type when deciding if the move line is reversed or not.
opw-3077772
closesodoo/odoo#112673
X-original-commit: c1e8e4fbbe369615733298a1dfe18ead566eb310
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
The user can use arrows up/down to change the value of an input in the
editor (inputs that handle numerical values). Unfortunately if this
input does not trigger a preview (data-no-preview="true"), the
modifications made by the user with arrow up/down are not saved. This
commit solves this problem by notifying that the value has changed at
the input blur (or on ENTER key press) if arrow up/down has been used.
Details:
Since we use text inputs in the editor, (even to manage numerical value)
the management of arrow up/down is done manually, so Javascript does not
consider the value of the input has changed and therefore does not
trigger the change event. Another solution would have been to say that
when we know that the input is going to manage a numeric value, we put
the type="number" on it but in this case, the change event is triggered
at each arrow up/down which breaks the fact that some inputs do not want
to have a preview.
Steps to reproduce the problem:
- Drop the Products block in a page
- Use arrow up/down to change the value of the Slider Speed input
- Save and Edit again
=> The change made with arrow up/down has not been saved.
task-2765868
closesodoo/odoo#112145
X-original-commit: 2e668f9c33e80ad9a78d5c0648d595a698936c81
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
The goal of this commit is to disable sample data mode when creating
a record using an on_create action in an empty kanban view.
How to reproduce:
- Go to an empty kanban view with an on_create and sample="1"
- Click on the create button
- Validate the creation
Before this commit:
The kanban view is still in sample data mode.
After this commit:
The kanban view deactivates the sample data mode.
closesodoo/odoo#112732
Taskid: 3176939
X-original-commit: b5909daaa16466321a0ad85aaf013155c0bcf5b2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The error:
> You need to add a line before posting.
was never raised anymore because a payment term line was always created
with a value of 0 if there were no invoice lines.
This commit checks that there are invoice lines before creating payment
term lines.
closesodoo/odoo#112745
X-original-commit: de328c2f7c6f06e3978ffcee462e2dcb2e12f564
Signed-off-by: William André (wan) <wan@odoo.com>
There is a check that prevent to set "internal" (meaning from the current company) partners on invoices/bills created via a journal alias.
When the "from" email is the email of the company, the check previously failed to recognize it as internal.
This could happen in this scenario :
If a customer/vendor sends a invoice/bill to the company email.
If then, someone forward this email to the journal alias. The "from" field is now the company email address.
closesodoo/odoo#112737
Task: 3145287
X-original-commit: b66f88870d78a22d0213aa70765f73f0de9e6252
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
We must force the access rights to the installation folder to "FullAccess"
because in some environments these rights have been restricted by customers.
And so the iot windows does not work properly
closesodoo/odoo#112735
X-original-commit: db3dff5150a638ed00d16109176853503326cd7f
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Before this commit if you would call phone_parse() but not pass along a
country code it would crash. This is reproducable by calling the phone_parse
function and not setting a country on the contact. In this case you would get
the following traceback:
AttributeError: 'bool' object has no attribute 'upper'.
This happens because the phonenumbers library tries to upper() the region but
if Odoo doesn't have a country set it passes along False. By doing a fallback
to 'None' the phonenumbers library will natively handle this and the user in
the UI does not get a traceback.
Task-2852953
closesodoo/odoo#112699
X-original-commit: 9b75d7ac1a912ff3d15c393a6a23018a18b3b9bb
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Thibault Delavallee <tde@odoo.com>
Pierre Paridans