amount_tax compute method uses `price * (1 - (discount or 0.0) / 100.0)`
_create_account_move_line method used `price * (100.0 - discount) / 100.0`
with price = 9.95 and discount = 0.1 it makes a difference
>>> 9.95 * 0.9
8.955
>>> 9.95 * 90.0 / 100.0
8.954999999999998
Cumulative errors makes a 1 cent difference between totals of the orders and
computed amounts.
The session could not be closed as debit != credit
opw-743188
When removing a move previously linked to a bank statement, the move_name value
must be removed too.
This field is set when reconciling the entries.
When move_name is set, it is not possible to delete the bank statement line,
even if the refered move no longer exists.
opw-741205
The filter on activity_date_deadline has been added during a fix, see
28c158cd13
It's incorrect for the computation of the 'Won in opportunities'
because it excludes opportunities not having activity_ids.
Furthermore, the way to compute the 'won' amount is not equals to the
filters when clicking on the button. Then, we need to keep only
opportunities standing in a kanban column having a probability of 100%.
opw-742489
The context key `from_date` can be retrived from `self.env.context,
while the context key `to_date` can be defined for each procurement
group.
We extend the code so that `from_date` can also be defined for each
procurement group.
Closes#16803
opw-743013
In the xml definition of views, a 'currency_field' can be specified
in the node options:
<field name="amount" widget='monetary'
options="{'currency_field': 'currency_id'}"/>
It indicates which field the monetary widget has to use to
determine the currency to display.
Before this rev., the widget didn't look for the 'currency_field'
in the options, but directly in the node attrs, so this simply
didn't work. This was for example the case on the crm.lead kanban
and form views.
This rev. removes some html injections issues:
- in char and text field widgets
- in phone field widget in mobile
- in list views (when no widget is instantiated)
Following bee3253b44, this commit is made
to increase the mail clients compatibility for the mails that are
created with the odoo mail editor.
Three new problems are handled:
- Font family of titles had to be forced too as outlook was not
inheriting parent font family on those either.
- Default text font-size had to be forced as was not detected in
transcoding correctly.
- text-decoration rule was decomposed in text-decoration(-line,
-style and -color) in transcoding. Outlook is ignoring those
three rules for some reason. As the decomposition is useless,
the transcoder now forces the recomposition of these three rules.
After 5d4dd98a a registration was confirmed once an invoice was fully
paid.
This is not very handy if the registration was free to begin with, you
need to create a 0.00 amount invoice.
This commit get back the previous behavior of auto-confirming
regitration directly when the registration is free.
opw-742901
closes#17035
... from a new record.
Steps to reproduce the issue:
- go to a multi-record view (e.g. list) of basically any model
- click on 'Create' -> it opens a form view in edit mode
- click on 'Discard' -> it goes back to the list
- click on an existing record -> it should open the selected
record in readonly.
However, it didn't display the data of the selected record, but
the default data of a new record (the result of a default_get).
This was because the changes weren't properly discarded when
reloading from a new record (it rather restored the record to its
initial state, i.e. to the result of the default_get).
The '/point_of_sale/display' controller is added in the hw_screen module.
This module is not loaded if the init scripts are not modified.
This means that updating a posbox with the internal update feature will not work.
This adds the link only in hw_screen and display an information message for old
versions.
Fields translated with function such as `xml_translate` or
`html_translate` have translations such as:
lang=fr_FR, src="Tree", value="Arbre"
when the value directly stored in the table could be:
<strong>Tree</strong>
The code to copy translations when duplicating a record did not take
this into account and when not in english, would add previously not
existing translations such as:
lang=fr_FR, src="<strong>Tree</strong>", value="<strong>Arbre</strong>"
This is wrong since for example after a copy in french, what is in the
database is:
<strong>Arbre</strong>
This commit change this so that the translation in the database stay the
same:
lang=fr_FR, src="Tree", value="Arbre"
This translation will still not apply (if the base language is different
and a translation different than the source exists) but it is more
logical to have this.
This change also magnify an issue that was that if a translation was:
Tree -> Arbre
and the content `<strong>Arbre</strong>`. The translation doesn't happen
in one way, but does when doing the reverse translation.
So:
translation (Tree -> Arbre):
`<strong>Arbre</strong>` -> `<strong>Arbre</strong>` <= FAIL
reverse translation (Arbre -> Tree):
`<strong>Arbre</strong>` -> `<strong>Tree</strong>` <= WORKS
this broke the test that something reverse translation of a translation
got the original. But testing this if the translation did not work seems
to make little sense.
opw-740213
closes#16984
Before this commit, we compare in some case False != u''
Commit #56c798a fix u'' != False but in case of the partner has been
edited from front end, partner.vat will be u'' and not False
There was two main problems with the feature
- The author name was not properly fetched so the feature which was
supposed to add the author of the blog post in the tweet never
worked -> this commit simply deletes it
- The code was considering the url length in the size of the tweet,
so if the url was 135 characters long, it considered that only 5
characters have to be taken in the selected text... which is wrong
as twitter URL are all shortened to 23 characters by twitter
opw-741530
Nothing prevents the deletion on invoice line at the Python level. Other
modules might give access directly to the invoice lines, and make their
deletion possible when the invoice is not draft.
opw-743154
The license entry in the manifest files for these modules were
leftovers from previous versions.
Once integrated in Odoo Community they share the same license as all
other modules, as mentioned in the LICENSE notice at the top of the
files.
opw-743686
- Sell a product in the POS
- Go back in the backend
- Return the product
- Click on "Payment"
The user is allowed to select any journal. It should be restricted to
the payment method available in the POS.
opw-743585
Before this commit, when a test in the qunit test suite failed, the
error displayed by the runbot was not really interesting. It just said
that test_01_js failed. With this commit, each assertion error is now
logged as an error, which means that they are displayed in the short
error log by the runbot.
With this commit, we introduce a benchmarking infrastructure: a new
controller, accessible at the route /web/benchmarks which will render a
new template (web.benchmark_suite).
This template uses benchmark.js and qunit.js to display a list of
benchmarking informations. For example, the number of op/s for
instantiating and destroying a list view.
I hope that this is the start of the beginning of taking the habit to
check our JS code performance sometimes, and making sure we do not have
large regression without a good reason.
The form renderer defines inline style on the groups it renders to
set the width of their children according to the col and colspan
attributes specified in the view.
However, before this rev., this impacted inner list views (for
x2many fields), as their columns get an harcoded width as well,
whereas they shouldn't.
This was for example the case in the stock.location.route form
view, for the push rules and procurement rules o2m fields.
The license info for these modules was a leftover from previous versions.
Once integrated in Odoo Community they share the same license as all
other modules, as mentioned in the LICENSE notice at the top of the
files.
opw-743686
- Create an expense, approve.
- Register the payment by check
- Print the check
The amount in words is not written.
The core of the issue is that the wizard
`hr.expense.register.payment.wizard` has been defined as a brand new
model instead of inheriting from `account.register.payments`. Hence the
Enterprise module "hr_expense_sepa" and now "hr_expense_check".
opw-742305
When PO and SO used the same sequence, a vendor bill with a source
document equal to the sequence of a SO could be displayed by this
SO(in the smart button "invcoies").
opw:693991
- Create a PO with a line scheduled 2017-07-01
- Validate the PO => the expected date of the related stock move is
2017-07-01.
- Modify the PO line date to 2017-07-15 => the expected date of the
related stock move is not updated.
Since we allow the modification of the scheduled date, we should make
sure that the related information is changed accordingly.
opw-741815
Before this commit, the tour tips were overlapping the chat windows.
This was due to the fact they always had a z-index of 1051 wherever
they were. If a tip was placed in a location where none of its
ancestors created a new stacking context, the closed tip was then
positioned above everything else, including the chat windows.
A simple solution would have been the one proposed by this commit:
https://github.com/odoo/odoo/commit/856e78b35a47a8732e5bd4da1cce247df70e5414
However, as it explained, this would not be entirely correct. In the
website, elements are using z-indexes and would thus hide closed
tooltips when it is not wanted if those have no z-index at all.
The solution this commit is making is to force the creation of a
stacking context for tooltips' parent. The z-index will still exist
on all tips (closed and not closed) to force them above every other
elements, but now only elements of the same parent. This is indeed
more correct (but maybe still not entirely): website tooltip are
often placed in the body (as it is the element which scrolls) and
are thus still placed above elements like the navbar as their
z-index is left high. However, when placed in the appswitcher, they
will now be placed above appswitcher elements only (and thus not
above outside elements which are themself above the appswitcher
(e.g. the chat windows)).
opw-743330
Caused by a stupid programming error.
Also refactor a bit the code that performs mention RPCs (that are
throttled) to allow to override the throttling value for the tests.
Editable grouped list views isn't a supported feature. Before this
rev., grouped lists weren't automatically set as non editable, so
it could cause crashes when the user clicked on rows of grouped
lists with editable="top" or "bottom".
This was for example the case in Timesheets > All timesheets ->
go to list view.
The 'data' attribute of exported datapoints (using 'get') must
contain a value for each field in the view, and the default value
is false when those fields are unset. The code manipulating those
datapoints supposes that this is the case and it makes it easier
and clean.
However, it wasn't the case for x2manys in new records for which
the default value contains CREATE commands with missing fields:
in that case, those missing fields weren't added in data.
This caused a crash in the Employee form view, in edit, if the user
clicked on 'Create and Edit' of the 'Working hours' field, because
some code in field_utils assumes that if the value of a date field
isn't false, it means that it is a moment instance (but in that
particular case it was undefined).
in res.company write(), create a sub method _validate_fiscalyear_lock()
so that it is easier to inherit to modify or extend its
functionality.
Was PR #16615
Introduced by 8f39ad2be6 which was
intended for 9.0. It does not work well in 10.0 because here users
have the possibility to specify their own tracking numbers directly in
the POS interface. This causes issues when eg. the user specifies the
same lot number as is already reserved by the system.
opw-742657
Creating a mail template which is complex and compatible with all mail
clients is a very difficult task as each mail client supports a
different subset of basic CSS rules.
This commit fixes 3 problems which were occuring in outlook and/or
thunderbird but not in gmail:
- Main layout horizontal overflow
-> change 24px horizontal padding of main layout to 3% and set the
width to 94% (so that the sum is 100%)
- Fixed 600px content was full width instead
-> Change the .o_mail_wrapper to be a <table> element instead of a
<div> element. The table is full-width and contains one row of 3
cells: an empty left one, a fixed 600px-width center one and an
empty right one. This allows to have the same layout as before but
without using the unsupported max-width css rule.
- Texts were not using the right color and font-size
-> <p> elements were not properly inheriting the color and font-size
properties, so force the style on <p> elements.
opw-743156
Josse Colpaert