purpose of this commit is to show modal with proper height
before this commit:
currently, the modal structure was not correct, so it is displaying
modal-content twice in the modal that's why it shows modal with full height.
after this commit:
correct modal structure to show it properly, so payment modal in the portal view
looks like as expected.
task-2025869
closes: https://github.com/odoo/odoo/pull/34334closesodoo/odoo#34334
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
As a portal user, complete some steps within a course
Completing all of them makes the course completion to 100 %
Now, in the backend, unpublish one of these steps
Before this commit, the completion was not taking into account
that a step did not "exist" anymore i.e. has been unpublished,
leading to a completion > 100%
After this commit, we search only for steps that are published
The completion cannot exceed 100%
OPW 2033553
closesodoo/odoo#34800
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Fix a bug that can be reproduced like so:
- Insert list
- Type char
- ENTER
- TAB
- Type char
The character gets inserted _after_ the `br` instead of replacing it.
closesodoo/odoo#34805
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Create a lead, assign it to a partner who has portal access. Go to that
opportunity on the portal, edit any date to set 3-digit year (0-999) and
submit the form. Go to the opportunity using the web app, traceback.
Dates are only supported starting to 1900 thus many parsing function
assume the year to be a 4-digits year. The html form has been changed to
use an input type date with a minimum value instead of a plain text
input. This ensure a better support by browser (they use their built-in
calendar) and allow basic html5 form validation.
opw-2033276
closesodoo/odoo#34796
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.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.
cherry pick of b295723c99closesodoo/odoo#34822
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
This commit replaces the usage of `formData.delete()` as it is not supported
by Internet Explorer and Safari Mobile.
closesodoo/odoo#34787
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, if we had a livechat channel with a user and:
- in backend use command "/leave" to leave and unpin conversation
- [do not reload the page (or there is no issue)]
- then the user sends a new message
The chat window opens just with the new message. Fetched previous
messages are ignored due to being already in the mail manager, and
links between these messages and the threads were never updated.
With this commit, when fetching messages that are already in the mail
manager, these messages are linked again to threads.
This commit also fixes an issue in which messages moderated with
status "accepted" were not correctly removed from the moderation
mailbox. This problem occurred after the fix on re-linking messages
to threads.
opw-2031270
closes#34761
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
- When creating a vendor on lunch without setting explicitly the
`responsible_id`, `default_get` should return the current user id.
Instead it returns the current user's partner id.
closesodoo/odoo#34759
Signed-off-by: Nicolas Seinlet (nse) <nse@odoo.com>
Go to the database manager, configure a password either via the
interface either via the `admin_passwd` `.odoorc` config file. Click on
the backup menu, let the `password` field empty and submit the form. The
modal is closed without any warning and no query is sent.
The problem is that even if the field is marked as `required`, there is
a event listener that catch the `onsubmit` event and close the modal
even if it is not valid.
opw-2031461
closesodoo/odoo#34669
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Setup a multi-company account and multiple website (one for each
company), create a mail campaign from a different company than the
superuser, send the emails and unsubscribe, the company logo is the logo
of the company the superuser is in instead of the logo of the company
sending the email.
opw-2026528
closesodoo/odoo#34701
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Before this commit, when a direct message chat was renamed, it
crashed with the following error:
`TypeError: Cannot read property 'toLowerCase' of undefined`
This occurs because the name of the dm chat changed from the RPC
response. However, no new name was provided, thus it sets its
name to `undefined`.
Test has been adapted in order to reflect that the server does not
response with new name after RPC `channel_set_custom_name`.
closesodoo/odoo#34641
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
The patch fa492d87f4 has been backported
from Odoo 12.0, that runs on Python 3.
The string '\n\n({} {}, {} {})' to be formatted is a byte-string in
Python 2, while the return value of _() is always a unicode-string.
As format() is (too?) nice, it attempts to convert the unicode-strings
into ascii in order to inject them in the format pattern.
With some languages that are written in ascii, this works -- by chance.
When you use non-ascii languages like Japanese, it fails.
We then fix that issue by using unicode-strings in the formatting
pattern.
#OneCharacterPatch B-)
opw-2032016
-----------------------------
For full technical understanding:
Python 2.7.16 (default, Mar 11 2019, 18:59:25)
[GCC 8.2.1 20181127] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> '{}'.format('test')
'test'
>>> '{}'.format(u'test')
'test'
>>> '{}'.format(u'エ')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\u30a8' in position 0: ordinal not in range(128)
>>> u'{}'.format(u'エ')
u'\u30a8'
closesodoo/odoo#34698
Signed-off-by: Richard Mathot (rim) <rim@openerp.com>
Steps to reproduce the bug:
- Create two companies C1 and C2 where C2 is the child of C1
- Create two purchase taxes T1 and T2 where T1 is in C1 and C2 is in T2
- Create a prodcuct P with T1 and T2 as supplier taxes
- Be in C1 as current company
- Create a RFQ and add P
Bug:
T1 and T2 were set on the order line of P instead of T1
PS: This fix is insired from product_id_change in model sale.order.line
opw:2032113
closesodoo/odoo#34658
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Have a user U that is Project User, Timesheets User, Employeed Officer.
Give him access to a private task T (by adding U as a follower of T)
on private project P.
Because of Employeed Officer rights, view_task_form2_inherited is rendered.
This shows field is_project_map_empty, which computation depends on project_id.
If U does not have access to P, then this triggers an access error, so the Task
cannot be displayed.
It is in general a legitimate configuration to allow U to interact with T
without being given full access to P, since it works in all cases but the rights
described above.
Since the computation of is_project_map_empty is the only blocking point,
we put it in sudo.
opw 2031124
closesodoo/odoo#34676
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
In multicompany mode,
/!\ Adress book sharing should be deactivated
User A in company A creates a vendor bill without a partner
User B in company observes the list. The new bill is present
User A changes companies and goes to company B
User B doesn't have access to company B
User B reloads the list
Before this commit, there was an access right error on User B side because the partner associated
with User A changed company, and is now unreadable from User B perspective
After this commit, there is no crash and we have the string: Created By User A in the list
in place of the vendor display name
OPW 2028451
closesodoo/odoo#34668
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this patch, this method was altering the signature of its parent method, moving the position of `failure_type` to 1 and making the other 2 arguments kw-only.
It seems this accidentally didn't break anything because all calls happened to be done in kwarg mode. However, it's very possible that a downstream module that is not based on `mass_mailing` and makes positional calls gets broken when `mass_mailing` is installed.
The fix is to respect original method signature.
closesodoo/odoo#34648
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The callback will usually check the transaction's state during
its execution, hence it should be executed after the state change
closesodoo/odoo#34666
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Move inside a node so the term can be exported (t-esc value are not
translatable)
opw-2031550
closesodoo/odoo#34663
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit, when a transaction has as status 'authorized', the
transactions' confirm page gives an error : 'Oops! There was a problem
with your payment.'
Now, the page gives the same message as when the transaction has the
status 'done' : 'Your payment was successful! It may take some time to
be validated on our end.'
opw-1984325
closesodoo/odoo#34652
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
[FIX] mrp: Manufacturing cost analysis report
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
Fine tuning of this commit: cb4afb263b
opw:2010912
closesodoo/odoo#34642
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before this commit, on a device with a "pen" (e.g. Surface Pro, ...),
it was not possible to sign a document on some browsers recently
updated (e.g. Chrome, Firefox, ...) only Internet Explorer was working.
Instead of drawing continuous lines only few dots appeared.
For Chrome and Firefox we have to catch events with "addEventListener".
For Edge we add touch-action property to convert touch events into click.
Steps to reproduce:
1) Go to sales app
2) Then go to quotations (menu Sales)
3) Create a new quotation
4) Click on preview
5) Click on the "Accept" button at the end of the preview
6) Use the "pen" to draw the signature (BUG)
We use a custom version of the jSignature lib (c.f. odoo/odoo@eddcb46),
so we have to patch the file in the Odoo repo with a mix of some
pull request found in the official repo and forks.
Link:
https://github.com/brinley/jSignature/pull/109https://github.com/brinley/jSignature/pull/159https://github.com/willowsystems/jSignature/pull/96
opw-2029684
Set an automatic reconciliation model with a tax
Create a bank statement on which one line will be caught by that model
Click on reconcile to get to the reconciliation widget
Observe the account move lines creates
Before this commit, the move line representing the tax amount
(and in the account for taxes) did not have a tax_line_id, which is
a reference to the tax that made the line exist
This messed up tax reports
After this commit, the move line of the tax has a reference
to the tax it originated from
The tax reports are correct
OPW 2006826
closesodoo/odoo#34627
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
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>
Backport somewhat improved version of this fix (we don't need to check
for the existing extension since we're not doing anything if there is
an extension at all) merged into later branches, to avoid forward-port
conflicts.
closesodoo/odoo#34509
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.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>
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>