During checkout, the user can create a new billing (only for public user as it
will create a 'normal' `res.partner`), a new shipping, edit its billing (that
will edit himself) or edit its shipping address.
All those cases will go through the exact same methods, public user and logged
in user included.
This previously led to multiple issues and multiple fixes to correctly set
`company_id` and `website_id` on the address (res.partner).
See 44372471ef that fixed the `website_id` part.
See 3a0f05f33 that fixed the multi-company behavior, but needed 2ba71140 to not
modify the company of an already created partner, but was still incomplete as
after that fix a logged in user would still have the admin (sudo) company
instead of the website one as supposed.
This commit will fix that bug and add some tests for all mentionned issues.
Related to #28853 as we want to backport the mentionned commit but needed to be
fix first.
closesodoo/odoo#34596
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Sending an email wasn't taking the outgoing mail server into account.
Adding it in the 'account_invoice_send_views' to use it in the wizard.
opw-2030717
closesodoo/odoo#34593
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When hr is installed, with 'private' type, you should be member of
hr/officer group to read them, or you'll face an access right error.
closesodoo/odoo#34587
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Before this commit, the report Leave Summary had hr.leave as its model
implicitly meaning that a report could be printed from an hr leave.
Since the report actually is a view which aggregates data, and not a document
representing a leave, it should have its wizard (the only entry point for that report)
as its model
OPW 2029699closesodoo/odoo#34507
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, action report had their model referenced only with a char field
which made impossible to elaborate domain based on the model
After this commit, a new computed field, depending on that char field allows to do that
OPW 2029699
The aforementioned commit prevented the creation of automatic xmlids for
custom fields, however this change is not exactly stable; if a database
already contains automatic xmlids for custom fields and the module to
which these xmlids belong to is upgraded, the xmlids would get deleted,
along with any records related to it because of the way that
`_update_xmlids` works.
This commit leaves existing automatic xmlids of custom fields while
preventing the creation of *new* ones.
closesodoo/odoo#34563
Signed-off-by: Christophe Simonis <chs@odoo.com>
In an attempt to ease the error reporting, some Google Error were raised
as UserError so they are shown on screen and the user can take immediate
action when the error is their side.
As shown by the different commits bellow, the introduced changes had
some bad side effects. Empty request body, empty response body, non-json
response. The resulting code got complicated.
Apart from the Google API itself, some Odoo module (i.e.
google_calendar) excepted HTTPErrors on some endpoints that are now
raised as incompatible UserErrors. There are no straightforward
solutions for those endpoints.
This commit reverts:
- da13c704
- 9c369a44
- 85ab9238
opw-2000950
closesodoo/odoo#34532
Signed-off-by: Richard Mathot (rim) <rim@openerp.com>
Using studio, add a file field on a form. Using the web form builder,
append that field on a form. Upload a file, `x_field_filename` is left
empty thus the filename is lost.
opw-2028071
closesodoo/odoo#34491
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Previous versions of this action were setting a domain. Removing the
domain field, instead of setting it to empty value, have not the same
result for upgraded databases.
closesodoo/odoo#34454
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The bank account field is set up by the default_get of invoice.
Similarly to the application of the onchange in the create,
we add it in the create if it is not already part of the given values.
This will set the bank account for invoices created e.g. from subscriptions.
Note that we extract it in a function to avoid duplicating the logic.
opw 2030562
closesodoo/odoo#34558
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Create a Binary field through the interface.
Try to import records through CSV like file, with a url as the value of that new image field
Before this commit, the url was saved in DB, leading to an error when trying to get
the image at read time (/web/image)
This is due to the fact that before 66f0e26f6f (saas-12.2) , Binary fields
were not attachments by default, thus did not enter the condition that db403e6dd7
introduced
After this commit, the special case of manual fields with url at import is correctly handled
OPW 2024822
closesodoo/odoo#34489
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
When an email is sent and is related to a record, there is a header with a
button link to access the record.
Before this commit, that button href was always linking to the base_url URL.
That was an issue on multi-website, since we need to use the website url and
not the base_url if the record is related to a website.
That's the case for a SO eg, after checkout you receive a confirmation email.
In a multi-website environment, we need to access the record website.
To do so, a previous imp/fix was done with c1be1993f9.
But this occurence still needed to be replaced.
Fixes#34309closesodoo/odoo#34397
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Future runbot improvement may share sources between build,
meaning that sources will be readonly to avoid any interaction.
_touch() was supposed to handle ro filesystem but
f7130556 introduced a new test that was not working
in this case.
Instead of trying to touch file and pseudomocking the result
if the filesystem is readonly, this commit add a real patch
on getmtime.
closesodoo/odoo#34710
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Follow up to:
- commit 4cdcab43ee
- commit cb4afb263b
- commit fb1839fa17
In order to be able to edit a done raw move after the production
and having a correct cost report with consistent values. The
simple rule that a done move should have its quantity equals to
its initial demand. Since report is based on initial demand it
should follow this rule and it's also a good practice because a
lot of computation are based on it (easier than quantity done
because it's already set on the correct quant uom).
opw-2033259
closesodoo/odoo#34695
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Steps to reproduce the bug:
- Create an invoice I
- Set the invoice date in the past and add payment terms
- Validate I
- Create refund from I
Bug:
The invoice date is set as today but the due date was set in the past.
opw:2033438
closesodoo/odoo#34692
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
If a test is failing with assertRecordValues, the comparison and the error
logging were not computed the same way.
The _compare_candidate was accessing the record via
record[field_name]
which uses the cache
While the _format_message was doing
records.read(...)
which queries directly the database.
If the test was failing (correctly) because of a wrong cache invalidation
(e.g. update the value directly in SQL without invalidating the cache),
the error message would look like:
AssertionError: Record doesn't match expected values at index 0.
Current values:
{'id': 42, 'name': 'Foo'}
Expected values:
{'name': 'Foo'}
closesodoo/odoo#34589
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
closes odoo/odoo#31520
---
backport of 8e2f9a4fe2
Initially a improvement, it is now backported in 12.0 to fix#34430closesodoo/odoo#34474
Signed-off-by: Christophe Simonis <chs@odoo.com>
Before this commit, when an address would be edited or created from checkout,
we would always add a website_id on it.
(values_postprocess -> _checkout_form_save)
That would be incorrect if the website has not 'specific user account' enabled.
It would lead to an error as the user would not be able to connect to another
website. Indeed, the billing address is stored on the partner directly. Since
the res.user website_id is a related to the partner one, the user would then be
restricted to that website.
Fixes https://github.com/odoo/odoo/issues/34308closesodoo/odoo#34396
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Parent commit moved needed functions into misc so this test could use those.
This test is for parent's parent commit which fix checkout billing address
edition.
Part of #34396
1. Set "Round Globally" on Invoicing settings;
2. Create a new vendors receipts and validate it;
There are an error messages that said : "Cannot create unbalanced
journal entry."
Fine turning of : 3e147220fd
opw-2026534
closes#32667closesodoo/odoo#34415
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Add record to the email values to allow the use of more complex
email layout as : "mail.mail_notification_paynow"
opw-2025099
closesodoo/odoo#34375
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
The terms were already exported but it was not in the configuration file
Courtesy of Erwin Van der Ploeg
closesodoo/odoo#34467
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
- Create 2 rates:
2019-05-01: 1.0
2019-06-01: 0.5
- Set-up a product A in AVCO
- Create a PO for A on 2019-05-15
- Receive the product after 2019-06-01
The AML are created with a rate of 0.5, but the product cost is updated
with the rate of 1.0.
This is because the stock move date is used when it is still assigned,
and not done yet. As described in:
https://github.com/odoo/odoo/blob/2f789b6863407e63f90b3a2d4cc3be09815f7002/addons/stock/models/stock_move.py#L36
The date is the scheduled date until the move is done, then it is the
date of the actual move processing.
We change the date to today's date, since it is the value used to update
the move date:
https://github.com/odoo/odoo/blob/2f789b6863407e63f90b3a2d4cc3be09815f7002/addons/stock/models/stock_move.py#L1143
opw-2006368
Note: the test has been slightly refactored to avoid an inconsistency
between `fields.Date.context_today` and `fields.Datetime.now`. Now, they
both return the same day. Moreover, the date is updated before each
action.
closesodoo/odoo#34444
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Configure two companies, add a bunch of attachments to each company so
at least one has more attachments than the default 80 search limit. List
the attachments of that company, only the 7à-ish firsts are displayed
and the pager is disabled.
The `_search` method is override in `ir.attachment` to filter the
original record set. If the original record set had reached the limit,
the filter may only return a subset whose length is lower than the
limit, this trick the different JS views making them think there are no
more records to return and disable the pager.
The fix has been to recursively re-search until the subset length is
equal to the limit.
opw-2025940
closes#34287closesodoo/odoo#34450
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Before this commit, all url of channel were using `web.base.url` instead of the
current website domain.
Fixes#32348
The override of `get_base_url` method should not be forward ported after
saas-12.4 as since saas-12.5 it is now a model method (f727cd2645).
closesodoo/odoo#34421
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Two different problems on the box and resulted in the crash of the Odoo
instance running on the IoT Box:
When `usblp` had troubles communicating with a printer, a NoDeviceError
was raised. The `printer` variable was still set from the last time the
loop was processed, so we tried to close it, resulting in an error.
The code handling generic execptions was broken.
closesodoo/odoo#34437
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
This popup shows in the rare situation where somebody has 2 payment
methods that use Mercury. It allows them to choose which one to use
when swiping a card.
It would show the amount due in the title of the popup however this
isn't correct when a "pending swipe" payment line has been added.
Fix it by removing this amount, it's clear what will be paid from the
information on the payment screen. Also use this opportunity to make
it translatable.
opw-2006596
closesodoo/odoo#34398
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
We have multiple ways of simulating a frontend context while running python
tests (mainly during TransactionCase):
- `MockObject` class from 8557bcfa30
- `simulate_frontend_context` method from a5a5a57e48
- `DotDict` from f8efc9a957
This commit moves `MockObject` to misc to be reusable and adapt it to be
accessible by dot notation with `DotDict`.
Part of #34396
Before this commit, when an address would be edited or created from checkout,
we would always add a website_id on it.
(values_postprocess -> _checkout_form_save)
That would be incorrect if the website has not 'specific user account' enabled.
It would lead to an error as the user would not be able to connect to another
website. Indeed, the billing address is stored on the partner directly. Since
the res.user website_id is a related to the partner one, the user would then be
restricted to that website.
Closes#34396Fixes#34308
Card readers act as barcode scanners, they produce barcodes in a
certain format (see pos_mercury.barcode_rule_credit). Update the label
of the option to reflect this.
opw-2006596
In case of failure at token creation, raise a proper UserError instead
of a generic traceback.
opw-2025723
closesodoo/odoo#34420
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Avoid crash at currency conversion when no company is set on the SO
opw-2009044
closesodoo/odoo#34408
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Install stock module
- Activate multi-company and variants
- Create a second company
- Create a product with 2 variants
- Create a picking with the product for both companies
- Add an attribute on the product with 2 values
- Save
An AccessError is raised on `stock.move`.
It arises because the field `product_qty` on `stock.move` must be
recomputed but is on a record in a different company.
The `try` / `except` clause doesn't protect against the recomputation.
Indeed, what happens is:
- try to unlink in batch => AccessError due to recomputation
- try to unlink individually => AccessError due to recomputation
- try to write individually => the field couldn't be recomputed before
(flagged as dirty), so try again to recompute => AccessError
We perform the operation as sudo, and take care of checking the access
rights beforehand.
opw-2009450
closesodoo/odoo#34369
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
There is no guaranty that both the request body and the response body
will contain JSON data. This fix corrects the logging by printing the
raw text in case of json decode error.
opw-2006561
opw-2024242
closesodoo/odoo#34221
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
The tags set for TVA déductible (achat) 5,5% TTC were for "TVA collectée"
opw:2026360
closesodoo/odoo#34410
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
1. Setup a few variants for a product;
2. Create a BoM for each of the variants with different
components/quantities, make sure to specify the product variant field;
3. Go to any of the variants and click Print BoM Structure.
Before this commit, it will print the BoM structure for all variants and
not only the one selected. Also, it will print in all the variants the
same BoM structure. If multiples BoM were selected to print, each
variant of the product was printed with each of the BoM structure
selected.
Now, if you select one BoM, only this is printed. If multiples BoM are
printed, each product, and product variant are correctly related to
their respective BoM structure.
opw-2007939
closesodoo/odoo#34353
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce the bug:
- Create a finished product P with a manufacturing BOM B
- Set two components on B C1 and C2
- Create a MO with P and process it(plan and produce it)
- Unlock the MO and set the consumed qty of C1 to 0
- Lock and click on Mark as Done
- Click on Cost Analysis
Bug:
C1 was displayed in the report with a qty = 1.0
opw:2010912
closesodoo/odoo#34351
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The `timesheet_uom` widget is a proxy to another widget (configurable
server-side). We need to ensure the widget registry is filled before
using it to avoid a fallback to `float_factor` widget.
closesodoo/odoo#34350
Signed-off-by: Christophe Simonis <chs@odoo.com>
In case a many2one field (let us say 'foo') is used
simultaneously as a groupby and a measure in the pivot view,
the values returned by a read_group for that many2one are of
the form [id, label] and the aggregated values (always 1) are
missing in the read_group results (datapoints).
Thus typically, a datapoint is of the form
{'foo': [1, 'Bar'], '__count': 4, ...}
and does not contain information on the 'foo:count_distinct'
value (this is a read_group bug).
As a consequence, a special processing of the read_group
datapoints is done in the pivot model to handle that
situation and the value for 'foo:count_distinct' is infered
correctly to be 1.
In the pivot comparison mode, datapoints comming from the
period and the comparison period (data and comparisonData
sets) are identified if they have same values for the groupby
fields and the measure values become small objects containing
information on the the measure values for data and for
comparisonData and on the related variation.
Thus
{foo: [1, 'Bar'], __count: 4, ...}
from data and
{foo: [1, 'Bar'], __count: 3, ...}
from comparisonData should become a single datapoint
{
foo: [1, 'Bar'],
__count: {
data: 4,
comparisonData: 3,
variation: {
magnitude: +33 (%)
}
}
fooAggregate: {
data: 1,
comparisonData: 1,
variation: {
magnitude: 0 (%)
}
}
It turns out that the code responsible for merging the data
and comparison datapoints made a mistake by mixing the keys
'foo' and 'fooAggregate', with the consequence that the
variations were not correctly computed in the situation
described above.
This is fixed in this commit.
closesodoo/odoo#33118
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Make the 'Custom Message' field translatable since it is supposed to be
used on the website and displayed in the language of the user.
opw-2008088
closesodoo/odoo#34344
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, when receiving a new message from a hidden chat
window, it was making it visible. Because of this, if we had focus
on any other window, the focus was lost. Even more annoying, if we
had focus on the left-most visible chat window, it moved to hidden
menu, so that new chat window takes its place.
This commit fixes the issue by keeping new chat windows hidden
on receiving new messages, in case there is not enough available
space.
Task-ID 2026101
closesodoo/odoo#34291
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Christophe Simonis