Activate analytic tags
Create an reconciliation model on which you set at least one tag
Create a bank statement and a line
Click on reconcile (or access the reconciliation widget by another means)
Quick Create a writeoff line
Click on the button corresponding to the reconciliation model
Before this commit:
The many2many tags was buggy, there was one empty tag, corresponding to nothing
clicking on the field triggered errors
validating the reconciliation by clicking on reconcile triggered a server traceback
in the real backend, opening the tag form view triggered an access error
This was because the data were not formatted the right way to be passed to the m2m_tag_field through
notifyChanges
After this commit, the reconciliation model's tag renders and behaves well
Validating the reconciliation works
OPW 2033350
As a side note, in the future, the reconciliation widget Model should fully implement basicModel
or not at all. Some of the heavy plumbing that the ReconciliationModel does (fetch records, data...)
is imitating what fetchRecord does
closesodoo/odoo#34838
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Put toogle_button or a favorite widget to handle a boolean field in an editable list
click straight up on the widget's button or link
Before this commit, the widget changed its appearence, but the changes were not
propagated to the model. This is because the controller will not force_save if its mode is edit
(to let changes piling up and save everything when clicking save), which is the case
of the editable list
After this commit, following what has been done at 2f5e44d40b
clicking on a widget in an editable list just activates the row for editing
but doesn't change the widget's value
OPW 2033700
closesodoo/odoo#34878
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The ready code warning timeout of 2 seconds can be confusing since
it is triggered just after the 2 seconds. We can log this message
at the end in order to give the real timeout.
In JS tests, when the ready code takes too much time, a warning is
logged. As a consequence, the runbot updates the github status as a
failure, causing real pain to people who simply wants to merge their
features.
With this commit the warning is changed into an info and the runbot will
be happy.
closesodoo/odoo#34865
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Steps to reproduce the bug:
- Select template type boxed in general settings
- Select show serial/lot number in Delivery slip (in inventory - settings)
- Print the delivery slip with a non tacked product
Bug:
The delivery slip report displayed wrong columns.
opw:2031985
closesodoo/odoo#34852
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Usecase to reproduce:
- Create a MO for 5 final units
- Reserve all the components
- Produce 3 units
- Post Inventory (debug mode)
- Edit/Unlock
- Edit a line to consume to an arbitrary amount of quantity
- Change the product qty and set it to 3.
At this point, the reserved quantity and the quantity to consume
still the same than intialy even if the final quantity was updated.
- Mark as done
Then a move is marked as done withtout quantity done and still have
reserved quantity.
It happens because the _update_raw_move function do nothing if the
new quantity to consume is equals to 0.
The arguments returns in _update_raw_move still exists for override
but are not used by the chang_prod_qty method. It's not possible to
cancel the move and then find its parents in order to log the activity.
opw-2023653
closesodoo/odoo#34471
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Previous versions of this action had a domain. It was removed at 2d3e6d7383
Set explicitly an empty domain to force the removal when upgrading the module
Similar to 2d03ed43a5closesodoo/odoo#34581
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In PostgreSQL, we can't CREATE OR REPLACE VIEW if there is the type of the column change.
To fix it, just drop the view before creating it
closesodoo/odoo#34851
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This is an api.multi method, which should therefore not call self.field.
Fortunately there's a loop just below.
opw 2035374
closesodoo/odoo#34832
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
before this commit the date of the IoT Box did not update.
With this commit we restart the service timesyncd on the IoT box
Task: 2034930
closesodoo/odoo#34789
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Steps to reproduce the bug:
- Install point_of_sale and account_accountant
- Create a company C in USD
- Create a cash journal CJ with no currency set
- Activate Multicurrency
- Create a pricelist P in EUR
- Create a sales journal SJ with currency = EUR
- Create pos.config in company C
- Assign SJ in the Sales Journal field
- Set P as default pricelist
- Set the cash journal CJ as payment method and save
Bug:
As CJ is implicitly in USD, it was wrong to set CJ as payment method in a pos.config
in EUR.
With courtesy of <jcb@odoo.com>
opw:2031883
closesodoo/odoo#34790
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When reading the non stored computed field property_product_pricelist,
the force_company set in the context is taken into account. But when
writing on property_product_pricelist, the force_company was not taken
into account. So it was inconsistent as you could read a record with a
force_company in the context and wrote on an other record as the inverse
function didn't take the force_company into account.
closes#31561
opw:2032024
closesodoo/odoo#34757
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Let's assume a one2many field (editable list) in a form view with
a many2many (e.g. many2many_tags), and an onchange on the one2many
such that, when a row is added to the relation, the server returns
update commands for (a subset of) the records being already in the
relation. For thoses updated records, the many2many field needs to
be read (the onchange only returns the ids in the relation).
Before this rev., the many2many field was read independently for
each record in the one2many. This could cause a performance issue
on large relations. For instance, this was the case on
account.invoice records with a lot of lines.
This commit must be forwardported up to 12.2, not further.
Issue 2027356
closesodoo/odoo#34771
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Add the support to be able to specify exlicitely module, class and method name in test_tags
Before this commit, there is no distinction between module tag and test tag. Meaning
that --test-tag module_name will replace the default +standard tag and execute all test
of the module.
This commit tries to keep the initial behaviour, while addind new features, like explicit
modules tag with /module_name, as well as class (:class) and method (.method)
Some usage examples:
--test_tags /module will execute all standard test of module
--test_tags :class will execute all standard test with class name 'class'
--test_tags .method will execute all standard test with method name 'method'
--test_tags external/module will execute all external test of module
--test_tags */module will execute all tests of module,
--test_tags */module,-standard will execute all non standard tests of module,
--test_tags -/website:TestUiTranslate.test_admin_tour_rte_translator will disable only rte translator test
closesodoo/odoo#34756
Signed-off-by: Raphael Collet (rco) <rco@openerp.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#34748
Signed-off-by: Simon Goffin (sig) <sig@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.
Fixes#28853
Backport from odoo/odoo#34596closesodoo/odoo#34689
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When a pl promo code is applied, the code is shown in the promo code input.
Before this commit, if the user clicked on "Apply" (so with the same code) it
would remove the pl as it would go in the `if` condition that is supposed to
handle empty code modo to reset pl.
Coming from #34633closesodoo/odoo#34734
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Forward port of a8dfc7fb73
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
Prevent singleton error when validating stock.picking with option cancel_backorder
in case there are multiple backorders involved by displaying all the backorder's names separated by commas.
opw: 20337021
closesodoo/odoo#34709
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Have a Tax 24%, included
Have account.voucher with a line reading:
`Price: 64.93; Tax: 24% Incl`
Validate the voucher
Before this commit, the account.move.lines created were wrong and unbalanced
as the amounts that should have been affected by the tax included haven't been
After this commit, the move and its lines are correct and balanced
OPW 2031751
closesodoo/odoo#34784
Signed-off-by: Lucas Perais (lpe) <lpe@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>
Before this commit, values were rounded to the unit, which was part of the former specs
of the Intrastat report
After this commit, we make the intrastat 2019 comply with the new spec, which is to round
value, price and weight to two decimals
See the spec here: https://www.nbb.be/doc/dq/f_pdf_ex/nieuwsbriefintrastat_n28_2018_fr.pdf
OPW 2031682
closesodoo/odoo#34700
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.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>
Insall website and mass_mailing, go to the `/sitemap.xml` url, the
`/unsubscribe_from_list` url is listed, it should not.
opw-2033251
closesodoo/odoo#34677
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.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>
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
Create a quotation and send an email to the customer, let the customer
reply by email, as a portal user go on the portal view of that
quotation, he does not see the emails.
opw-2008653
closesodoo/odoo#34611
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
On the webiste, add the Latest Posts widget. Create a new blog post,
publish it on website but set its "Publishing Date" `post_date` to a
future date. The blog post is not publicly available but is listed on
the latest blog posts.
opw-2027368
closesodoo/odoo#34760
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
[FIX] hr_timesheet_attendance: disable link from timesheet attendance report
---------
Before this commit, linking was enable for pivot view of hr.timesheet.attendance.report
Opening the record is useless since all information is in
the pivot view.
Also, no list view is defined, therefore an empty list view is opened.
This commit disable linking.
[FIX] hr_timesheet_attendance: Fix report date type
---------
The field `date` of `hr.timesheet.attendance.report` if of type Date.
However, in the SQL view, the value is wrongly set
to a datetime in the database.
Therefore, the value is a datetime in database, but it's considered
as a date by the ORM. This can lead to a traceback.
The postgreql function `date_trunc` is misused because it returns
a datetime.
Fix:
1. The date value from hr_attendance.checkin is a datetime
=> cast to date
2. The date value from account_analytic_line.date is already a date
=> don't do anything
closes#34046#34612
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#34741
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The field `date` of `hr.timesheet.attendance.report` if of type Date.
However, in the SQL view, the value is wrongly set
to a datetime in the database.
Therefore, the value is a datetime in database, but it's considered
as a date by the ORM. This can lead to a traceback.
The postgreql function `date_trunc` is misused because it returns
a datetime.
Fix:
1. The date value from hr_attendance.checkin is a datetime
=> cast to date
2. The date value from account_analytic_line.date is already a date
=> don't do anything
Before this commit, linking was enable for pivot view of hr.timesheet.attendance.report
Opening the record is useless since all information is in
the pivot view.
Also, no list view is defined, therefore an empty list view is opened.
This commit disable linking.
Before this commit, `language_ids` field would be required through python code.
It is the only website res settings field that is required=True.
That's an issue since the website settings can be empty if there is no readable
website. In that case, the settings won't save.
Website res settings should be set as required XML side, in the view,
conditionned on the fact there is a website selected or not.
For the reason why there is not always a website selected, see bb473003d7.
closesodoo/odoo#34706
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Lucas Perais (lpe)