On a small display, go to accounting > journal entries > create
In the (now kanban) list of account move lines, click ADD
Then, try to choose an account
Before this commit:
The list of accounts was empty.
This was because the form view spawned was the automatic generic one
The generated view did not have thr necessary structure to get fields' value
from the parent form view.
In this case, the domain of the name_search for account.account was wrong
After this commit:
The flow works on mobile as on desktop. The form view's arch is a 1 to 1
copy of the list view in terms of fields and their definition
OPW 2030837
closesodoo/odoo#34601
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
In sale_expense, there is a rules allowing employee to see all confirmed sales
order. This rule breaks the one from sale "see own document" for salesman user.
The initial goal of this rule is explained in Task-29303: we wanted to ease the
reinvocie flow. For an employee, is it diffuclt to know on which analytic account
the expense should be reinvoice (no knowledge of that, no "analytic rights", ...).
Anyway, this rule brings more problem than expected and prevent people to work.
So, we decided to functionnaly revert the feature by desactivate the rule and hide
the sales order field on expense for user that are not salesperson. Salesperson can
set the SO, and the onchange will set the analytic account. Futher work will be
done in master (for 13.0) in order to solve that matter.
To apply the fix, the rule should be desactivated, and the module sale_expense can
be updated.
opw-2027005
Coming from Task-29303
closesodoo/odoo#34514
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
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>
Before 8557bcf the URLs were never rewritten for multilang, which was an
error and could duplicated the number of requests on frontend.
Since 8557bcf the URLs are rewritten. In Odoo the werkzeug library is
used to parse the URLs (this is similar to python parsing URL but works
in python2 and python3 the same), and in this particular instance it
chooses that tel:800800 is website http://tel:800800 and not a telephone
number.
The problem is when the url uses the uri 'tel:' and only numbers as a
phone number, if the user uses the global format for telephone number
(with the +) or using a separator for the numbers (e.g. '-' , '/'), in
these cases there are no problems parsing the url (phone number RFC:
https://tools.ietf.org/html/rfc3966).
This commit changes the uri 'tel:' to 'tel://' this one is correctly
parsed by the werkzeug library.
opw-2029844
closes#34306closesodoo/odoo#34586
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.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>
Have a product with a fixed amount tax.
Make a "return" of that product in the pos (i.e. negative quantity)
Before this commit:
- The amount of the return was `tax_amount + product_amount` instead of `-1 * positive_total_amount`
- The amount differed from what can be observed in sales
This was because the sign of the quantity was applied twice
After this commit,:
- the amounts of positive and negative amounts are symmetrical
- they match the behavior in sale
The logic is very similar to bb72dea98d
OPW 2026278
closesodoo/odoo#34548
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Incorporate Deivis Laya (deivislaya) as Vauxoo's contributor
I confirm I have signed the CLA and read the PR guidelines at
www.odoo.com/submit-pr
closesodoo/odoo#34569
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
smtplib.SMTP API calls such as .sendmail() or .login() make sure on
their first line that this command is sent, by calling
.ehlo_or_helo_if_needed().
However, test_smtp_connection() does not use SMTP.sendmail() to simulate
sending email, or the email would really be sent.
Instead it uses the low-level API SMTP.mail() which does not make sure
that HELO was sent.
The connection test could be fixed by ensuring that this command was
sent to the server in the test method. However, this could lead to
inconsistent cases where the connection test passes whereas another
usage in the code fails because the command was not sent.
For example, someone could use the low-level API for some reason.
EHLO could have already been sent because if authentication is enabled
smtplib.SMTP.login() calls ehlo_or_helo_if_needed(). Therefore it is
correct to call it ourselves at the end of our connect() method.
STARTTLS sends a first EHLO, negociates the encryption, and leaves the
state without the second EHLO, which should still be sent to the server,
as stated by RFC 3207, in section "4.2 Result of the STARTTLS Command".
https://www.ietf.org/rfc/rfc3207.txtclosesodoo/odoo#34550
Signed-off-by: Julien Legros (jle) <jle@odoo.com>
Fix/improve commit d870749d79
that was removing line feed (\n).
In this one, we also remove carriage return (\r)
to address all cases.
closesodoo/odoo#34536
Signed-off-by: Nicolas Lempereur (nle) <nle@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>
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
- 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>
When an `IntegrityError` is raised, the user receives a cryptic error
message which doesn't provide much valuable information in order to
solve the problem.
However, such an error is raised in 3 cases:
1. A mandatory field is not provided at creation/update.
2. The deletion of a record makes a mandatory Many2one field NULL on a
referenced table (`ON DELETE SET NULL` on a not nullable field).
3. The deletion of a record raises a `ON DELETE RESTRICT` foreign-key
constaints.
In the first and second cases, we provide the table and field on which
the `NOT NULL` constaint is raised. We also suggest to archive the
record in case of a deletion.
In the third case, we provide the table and the constraint raised. We
also suggest to archive the record.
Notes:
- The IDs of the records causing the issue is not provided since the
information is not provided by PostgreSQL.
- Although cases 2 and 3 have a different root cause, the error
message raised is very similar. Indeed, from an end-user perspective
the solution is identical: archive the record. Another solution would
also be to manually edit the records raising the error, but most of
the time this is not an option: these records are locked and cannot be
edited anymore.
task-1970853
Closes#32949closesodoo/odoo#33922
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Sapan Zaveri <sza@odoo.com>
Co-authored-by: Pragya Ladda <pla@odoo.com>
It's currently possible for binary downloads to be missing an
extension entirely. Generate an extension from the mimetype and use
that. Also ensure the existing extension (if any) matches the
mimetype.
Warning: this may require adding new mimetype/extensions pairs to the
local mimetype database similar to
f413d155df.
Also fix missing or incorrect filenames on records without a filename
field: in some Odoo versions the client would send a filename of
"null", resulting in a download of e.g. "null.pdf" instead of the
attachment or inferred name.
Task 2025716
closesodoo/odoo#34299
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Lucas Perais (lpe)