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>
The read permission on `hr.employee` has been removed from the public
and portal users; replaced with read access on the public employee
profile.
closesodoo/odoo#34508
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Previously to commit [1] notification emails were send using the after commit
hook (see [2] for related code move and [3] for original code). That commit
changed the parameter default value without any reason, meaning this mechanism
is not used anymore. This commit fixes that behavior.
[1] See commit 581a74143e: code cleaning
[2] See commit 7a6269719f: code move
[3] See commit 38e181ee2c: use of post-commit hook in mail
closesodoo/odoo#34645
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Since commit 632fa044c3, polib is used instead of a custom pofile
reader. The setup.py file was forgotten in packaging, leading to a
faulty source package.
closesodoo/odoo#34585
Signed-off-by: Christophe Monniez (moc) <moc@odoo.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>
Detected with OPW 1920765
Reproduce : set multi-companies, install accounting. The due amount for all companies is the sum of the due amount for every single company
Cause : the context for company_id is not set in account.move.line:_query_get
Solution : set it in res.partner:_credit_debit_get in case _query_get is used elsewhere
closesodoo/odoo#30463closesodoo/odoo#34486
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Let contacts be shared in a multi-company setting.
Make a filter on 'Total receivable', e.g. greater than 0.
All contacts that correspond to this clause are show,
even if their Total receivable is nonzero in another company.
It follows that a partner can be shown by the filter with a value 0.
The inconsistency was created by 017184331b, which adapted the compute method
to the multi-company setting, as before the two were summing all companies.
opw 2028660
Steps to reproduce the bug:
- Create two variants V1 and V2 for procuct template V
- Set supplierinfo on V
- For V1, assign "vendor X" with a minimum order quantity= 10 and price = $10
- For V2, assign "vendor X" with a minimum order quantity= 2 and price = $1
- Create a RFQ for vendor X
- Set V1 on a PO line
Bug:
The minimum quantity of V2 was automatically set (10) instead of the minimum quantity
of V1 (2)
opw:2028527
closesodoo/odoo#34523
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
1. Create a purchase tax of 24 %;
2. Set rounding to "Round globally";
3. Create a new purchase receipt with two lines; unit price $115.98 and
unit price $69.98 and add 24 % tax on both lines.
Before this commit, the total was wrong $203.60, which generates also an
error message when trying to validate the receipt.
Now, the total is correct $203.59 (115.98 + 69.98 + tax 44.63).
opw-2031731
closesodoo/odoo#34560
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
In the editor, when you write a letter at the end or beginning of a link
it is written outside the link. But if you press "Enter", we get on a
newline with an empty link duplicated on the new line.
This is caused by the custom code handling "Enter" keypress.
With this changeset, in this situation we place the range just before
the beginning or after the end of a link.
opw-1724606
opw-2042097
closes#35188
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Running the following 12.0 tests: https://github.com/odoo/enterprise/blob/b7768337d88990e403338c39e461ecb1796413ab/l10n_mx_edi_landing/tests/test_landing.py#L126
raise the following error using anglo-saxon:
```bash
File stock_account/models/account_invoice.py, line 60, in invoice_validate
File stock_account/models/account_invoice.py, line 89, in _anglo_saxon_reconcile_valuation
File 10n_mx_edi/models/account_move.py, line 12, in reconcile
File account/models/account_move.py, line 957, in reconcile
File account/models/account_move.py, line 948, in _check_reconcile_validity
odoo.exceptions.UserError: ('Account Mercancías en tránsito (115.05.01) does not allow reconciliation. First change the configuration of this account to allow it.', '')
```
closesodoo/odoo#34463
Signed-off-by: Josse Colpaert <jco@openerp.com>
The production.move_raw_ids usually contains only one move per bom_line_id;
it might not always be the case, as ccbd6712f6 used move[0] to get a singleton.
The following calls to _get_document_iterate_key, _log_activity_get_documents,
also require move to be a singleton, so we use replace move by move[0].
opw 2042099
closesodoo/odoo#35206
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit, the unit price in the so's portal, had the same
decimal precision as the currency and not the one specified for the unit
prices.
Now, the portal shows the unit prices with their specific decimal
precision.
related to : a1e6a0f0c5
opw-2042089
closesodoo/odoo#35171
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
The "lots & serial numbers" feature can be deactivated at any point.
If there are active products that are tracked, either by lot or serial number,
it can be confusing since deactivating it will hide the relevant fields.
Therefore we raise a warning at onchange if there are tracked active products.
opw 2036173
closesodoo/odoo#35108
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
- To enable loop on a video, only setting the 'loop' URL parameter
to 1 will not work anymore. We also need to set the playlist parameter
to the video ID.
- Sound is no longer allowed in autoplay because of new autoplay
policies of most browsers. To make autoplay work, the video must be
explicitely muted.
closesodoo/odoo#34323
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.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>
* Sales > Orders > Sales Team > traceback with error 'user_type_id' isn't defined on account.move.line.
* Also the move.team_id has to appear in some group by because we're using an aggregate function.
Both bugs have been introduced by beaa30a (aka accounting-pocalypse)
closesodoo/odoo#34570
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Commit f60825b439 moved phone validation addition on res.partner model
from a specific module to crm directly. However the inherit from the validation
mixin class was forgotten, leading to a crash when changing phone from the UI.
closesodoo/odoo#34545
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Scenario:
We have the following models:
class A:
submodel_1_ids = fields.One2Many(B)
submodel_2_ids = fields.One2Many(B)
class B:
parent_model = fields.many2one(A)
name = fields.Char()
and the following onchange on class A:
api.onchange(submodel_1_ids)
def onchange_submodel1(self):
// add newline to second o2m
submodel_2_ids = submodel_1_ids
api.onchange(submodel_2_ids)
def onchange_submodel2(self):
do_smth
In a form view containing both o2m fields (editable="bottom" lists):
1) add a line on first o2m -> the onchange adds the same line on
the other o2m
2) add a line on the second o2m
Before this rev., the line (added in (2)) wasn't added at the bottom
of the list, and the row in edition wasn't the newly created one.
The issue occurred because we couldn't retrieve the datapoint
corresponding to the other line (the one created by the onchange on
the first o2m), and we thus created another which was put at the
end of the list. Then, the BasicModel messed up the sort of the
records because it couldn't match the virtual id of that new record
with the ones in orderedResIds.
We fixed the issue by preventing the model from creating a new
datapoint after the onchange, by using 'ref' instead of 'res_id' to
retrieve the one that already exist.
closesodoo/odoo#34493
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
This reverts commit 43d51466c8.
Reasons:
- too complex having 2 UoM "Hours"
- impossible with UoM to modelise month: is that 30 days or 31 ?
Task-1971491
closesodoo/odoo#34497
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
Since groups added on fields 'barcode' and 'pin' on hr employee in
rev: c9ca376146
It is not possible anymore to launch the POS when 'pos_hr' module is
installed. Because we don't want to allow users to access in read on all
pin codes and barcodes of employees. We've made a function that will get
a sha1 signature of the barcode and pin code of all employees to store
it in the frontend of POS.
We don't have other solutions concerning the security if we want to keep
the POS working offline. We also know that it is not brute force proof,
as pin code are composed of only digits and you can easily generate the
signatures of all pincodes.
closesodoo/odoo#34447
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Now that an onchange set its result into the cache, we
cannot create a user because the onchange tries to put
the reified fields (eg: sel_4_7) into the cache.
As those field don't exist and are pseudo-fields used
to manage groups into the res user form view, we should
replace the values by ORM commands on the groups_id field,
as this is already the case in the create and the write
methods.
closesodoo/odoo#34487
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This is mainly a typo / wrong computation introduced at 581a74143e.
This commit also fixes some typos in comments.
closesodoo/odoo#34443
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Let's assume a one2many field in a form view with a default value
with commands 4 (link to). Before this rev., when saving the record,
the BasicModel generated a command 4 and a command 1 (update) for
each record, with the values of the record (directly coming from DB).
This can cause an issue when the related record can't be edited
(e.g. a posted journal entry in accounting).
closesodoo/odoo#33797
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Christophe Simonis