The delivery module overrode the method _create_invoice_from_picking
to add the shipping costs according to the invoice and the shipping.
The issue is that the method _create_invoice_from_picking creates an empty
invoice, without any line. The lines are added afterwards, using the method
_create_invoice_line_from_vals, within the method _invoice_create_line.
So, after having called _create_invoice_from_picking, the invoice is indeed
created, but without lines, and therefore without the amount total value.
Adding the shipping costs there will thus prevent the shipping costs
based on the total price of the invoice (e.g. free for an order of 500€)
This rev. overrides the method _invoice_create_line instead, as, after
the call to this method, the invoice will be completely set, with all
its lines, and with a correct amount total. The side effect
is that we need to recompute the taxes a second time, using button_compute.
This is not the cleanest way to solve this issue. Indeed, a cleaner patch
would be to change the method _create_invoice_from_picking so it creates
the invoice along with its invoice lines, using the ORM command
(0, _, values) to creates the lines directly within the invoice creation:
invoice['invoice_line'] = [(0, _, values) for values in invoice_lines_vals].
Nevertheless, this is a bigger change, that will probably require API changes,
and therefore should be done in master.
opw-626226
opw-628517
Many trivial changes to journal items, such as the
"blocked" flag for litigation (follow-up), do not affect
the balance of the whole entry. These should not cause
the account.move to be (re)validated.
For example it should be possible to change trivial
fields even on journal entries recorded in a closed
fiscal period.
Setting an expense with a tax included with a negative base code sign was
getting the wrong amount (tax line as a credit instead of debit). So leading to
a total for the accounting entry superior of the total of the expense (should
not happend as the tax is included).
Add test to verify this scenario.
Fixes#4260, opw 618531
The quick creation and account record opening in the sheets are not useful.
Besides, restricted users (simple employees) have no read access on account.account.
opw:626989
In the website editor, the translations are loaded using
the route 'get_view_translations', which returns the translations
of the templates loaded by the website (t-call calls)
The thing is, report templates use the 'translate_doc' method
to actually load the report, translated in the partner language,
and the templates loaded by this method are not seen by the website,
therefore, when calling 'get_view_translations', those report
templates were just ignored, thus their translations are not loaded.
This rev. injects the templates loaded with translate_doc
when rendering the report into the method 'customize_template_get'
(which is used by 'get_view_translations' to retrieve the loaded templates).
The translations of the reports are therefore now loaded corretly when
hitting the "translate" button in the website editor for reports.
Besides, this rev. has as (good) side-effect to add the template,
in the template selection input when editing using the HTML editor.
opw-620713
Without this, if the user creates a second line (or more) with another search query and presses tab (or clicks somewhere else) quickly, it will take the previous search result instead of the new one because the new one did not occur yet.
With this fix, if the search did not have time to process, the Create a product modal appears, just like it already did for the same behavior on the first line.
Fixes 620679.
As of January 1rst, 2015, telecommunications, broadcasting
and electronic services sold within the European Union
have to be always taxed in the country where the customer
belongs. In order to simplify the application of this EU
directive, the Mini One Stop Shop (MOSS) registration scheme
allows businesses to make a unique tax declaration.
This module makes it possible by helping with the creation
of the required EU fiscal positions and taxes in order to
automatically apply and record the required taxes.
This module installs a wizard to help setup fiscal positions
and taxes for selling electronic services inside EU.
The wizard lets you select:
- the EU countries to which you are selling these
services
- your national VAT tax for services, to be mapped
to the target country's tax
- optionally: a template fiscal position, in order
to copy the account mapping. Should be your
existing B2C Intra-EU fiscal position. (defaults
to no account mapping)
- optionally: an account to use for collecting the
tax amounts (defaults to the account used by your
national VAT tax for services)
It creates the corresponding fiscal positions and taxes,
automatically applicable for EU sales with a customer
in the selected countries.
The wizard can be run again for adding more countries.
References
++++++++++
- Directive 2008/8/EC
- Council Implementing Regulation (EU) No 1042/2013
Closes#5229
When you try to load calendar_demo.xml, the loading of demo event
`calendar_event_1` fails with fr_BE locale (and probably some others).
This is due to the rendering of the mail template
`calendar_template_meeting_invitation` (which is used when you create
an event).
This template used a method `get_interval()` in calendar.py, which
does not always return Unicode strings. Furthermore, these strings
are dates and should be formatted according to user locale.
PS: Yeah, we love Python2's management of encodings and Unicode...
Since all the lines in a partial reconciliation share the same state and the same amount_residual, we need to keep only one 'result' line.
It was the first line found that was kept ; now it's the line whose amount is greater than amount_residual, whiwh most likely is the significant one.
Fixes#5129
Module 'Warning' overwrites onchange_product_id method of purchase.order.line
The signature in the warning module had 'notes', while there isn't any 'notes'
parameter in the original method, in the purchase module.
The super call was also wrong, ignoring the optional fields, which
were therefore always set to the default value
The name must be changed when changing of product,
but not for other changes, quantity for instance.
The 'or not uom_id' is just for retro-compatibility concerns
uom_id being False actually means we just changed of product,
and the name must therefore be changed
name as been set as False in the onchange call in the view
for the product_id field, in this rev.,
so the name being False now means th change of product
Nevertheless, existing databases for which the view
is not up to date won't have this change
and we therefore have to rely on something else to know
when the product has been changed or not.
fixes#5295
opw-628138
When having several databases in the login form (not monodb mode),
when switching from one database to another,
if the company logo was different,
the company logo could be the logo of the database you came from.
fixes#5291
opw-628131
The payment transactions references must be unique, but for
states within draft, pending, done states, not
if the transaction has been canceled or in error.
Otherwise, this is not possible to create a new payment
transaction for an ecommerce order for which
the payment has been canceled by the acquirer
For instance, when the customer lands on Ogone,
then hit the cancel button
opw-627914
The seller_id field is a related that is read administrator so it would fetch
the first line, whatever the company specified.
Setting related_sudo=False would not be enough as creating purchase orders
through the scheduler makes the computation done as administrator.
Use the company of the procurement (required) to search for a supplier.
If no result, fallback on the first one as before.
Fixes#3833, opw 618809
When clicking on an element in a listview editable, the record_id
is not updated in the dataset, which means that when you switch to form
view, the list view does not display the last selected record.
Also, it should fix the issue solved by PR pull/2725
In ecommerce products list view, if the product name was
shorter than the product price, than,
the product price overlapped the product description
Besides, this display: inline-block; has no useful utility
(at least not known), and it should be set in a CSS property
anyway
In a workflow context (for instance, in the invoice workflow),
context is not passed.
Therefore, relying on the 'recompute' key being the context
in order to not recompute the fields does not work with Workflows.
It leads to huge performance issues,
as fields are recomputed recursively (instead of sequentially)
when several records are implied.
For instance, when reconciling several invoices with one payment
(100 invoices with 1 payment for instance),
records of each invoice are recomputed uselessly in each workflow call
(for each "confirm_paid" method done for each invoice).
With a significant number of invoices (100, for instance),
it even leads to a "Maximum recursion depth reached" errror.
closes#4905
If they are this routes:
/partner/p-1
/partner/p-2
...
/partner/grade-1/p-1
/partner/grade-1/p-2
...
/partner/grade-2/p-1
/partner/grade-2/p-2
...
We want test only one time the routes:
/partner/p-1
/partner/grade-1/p-1
For example avoids a crash with:
TypeError: can't multiply sequence by non-int of type 'float'
when setting the quantity field of a salary rule to `1,0`
instead of `1.0`.
Fixes#5154Closes#5155
During the refactoring of the web client, the self.$el has been changed
from .openerp to body, so the notification was no more into the .openerp container.
Custom css (eg .highlight) was no more applicated.
Fix error where if no email_from was in openerp.tool.config, notif by mail was not sent
Add optionnal param 'missing' to allow to have missing alarm.
Missing field is the date from the last time that cron had run.
Now we stop to process the next 30 minutes, but we process all alarm since the next cron.
So, an email alarm will be always in delay, but a mail will be sent !
In v8 we use ICP to save the date, but it should be changed in master, maybe we should
save the last execution time in the ir_cron model directly ?
This is possible to set a partner as a free member
simply by checking the "free member" box, in the partner form
This leads to the fact there is no membership lines for this partner
Before this rev., only partners having membership lines were displayed
on the website members page.
When creating and deleting (disabling, actually)an event without syncyng with google,
this is possible that Google returns a 404 status page,
meaning the event we are trying to delete google side do not exist.
We can safely ignore these 404 pages, as the event are not anymore existing
in Odoo side either
opw-627767
When having an invoice with multiple lines having the same
product_id and account_id, the residual amount was wrong.
This is due to the fact the residual amount of each line
was computed on the residual amount of the invoice divided
by the number of lines of the invoice, and the fact the main
select of the sql view was grouped by product_id, account_id.
So, for an invoice defined as
Product Account Total
A 1 10
A 1 10
B 1 10
The invoice analysis, grouped by product, account, computed
Product Account Total Residual
A 1 20 10
B 1 10 10
The residual amount '10' of the first line being
30 (the residual amount of the invoice)
divided by 3 (the number of lines in the invoice)
The residual amount of the invoice should actually be divided by
the number of lines in the invoice * the count
of occurences in the group by clause
So, in this case, (30 / 3) * 2 = 20
Replacing the big jointure by
SELECT count(*) FROM account_invoice_line l where invoice_id = ai.id
to get the number of lines in the invoice
is just an optimization for performances
opw-621672
when the user press tab in editable list views, the focus is supposed to
go to the next cell unless it is at the last cell of the line. in that
case, it is supposed to create a new record.
Sadly, when the last cell is readonly, this does not work. This commit
make sure that read only fields are properly ignored when computing the
last_field state.
When using %(date)s in the follow-up text in the follow-up levels configuration
the date was formatted within server date format
instead of the partner language date format.
Closes https://github.com/odoo/odoo/pull/5168
The onchange() on new records processes fields in non-predictable order. This
is problematic when onchange methods are designed to be applied after each
other. The expected order is presumed to be the one of the fields in the view.
In order to implement this behavior, the JS client invokes method onchange()
with the list of fields (in view order) instead of False. The server then uses
that order for evaluating the onchange methods.
This fixes#4897.
The module analytic_user_function allows to define a specific product
to use, when creating timesheet activities for a specific employee
with a specific contract
Nevertheless, the product was not set accordingly to this feature
for the first timesheet activity, because,
when initilialing the timesheet line,
the on_change_account_id, which returns
the product to use according to the user and contract, was called
without passing the user.
Besides, by default, on_change_account_id does not have a user_id parameter,
this parameter is added by the module analytic_user_function, overriding
this onchange, and adding a new user_id parameter (which is not a good pratice).
We therefore use multi_on_change_account_id, which allow to pass the user_id,
within the context
A record rule exists on currencies but not on rates.
If creates multiple currencies with rate = 1, we could fetch the wrong one in
the search and get a security exception while trying to convert rates.
Fixes#3323, opw 626353
This reverts rev. 9f9e7ef0e1
As explained in 9f9e7ef0e1,
if a field "lang" is present in the view, clicking in any action item
in the more menu leaded for the action title to be translated
in the lang value of the form, such as in the partner form.
9f9e7ef0e1 fixed the issue,
but has as side-effect to not update correctly the active* keys.
So, if "active_id" was used in the context of the action button,
and the active_id was set in the dataset context, for example
because you come from another form, trough another action button
(For instance, Customers > Opportunities > Logged Calls),
the active_id was not updated with the current id of the record.
opw-620293
opw-617321
fixes#3462
Most pop servers don't perform deletions until QUIT. If for some reason
the process is killed while fetching a large quantity of messages, the
quit method isn't invoked, while the commit method has been. We may thus
end up with duplicated messages the next time we try to fetch. It therefore
helps to fetch the messages in small subsets and call the quit method between
those subsets.
In 7.0, prevent changes in activities of validated sheets was done thanks to the constraint
_check_sheet_state.
In 7.0, python constraints were checked at each write operations
whatever if the fields on which the constraint is were altered or not
This is no longer the case in Odoo 8.0: The constraint is checked
only if the fields on which the constraint is are altered.
As this specific constraint must be applied anytime, whatever the altered fields,
we now do this constraint check in the "write" method.
Besides, it was already the case for the unlink method.
opw-627415
Once a timesheet confirmed, the activity hours should not be modified,
for any reasons.
The constraint _check_sheet_state prevents to modify activities
for confirmed timesheets, but does not prevent the addition
of new activities within the current, but confirmed, timesheet.
opw-627415
fixes#5128
Christophe Simonis
Denis Ledoux
Olivier Dony
Vicente Jimenez Aguilar
Somesh Khare
Arthur Maniet
Goffin Simon
Anthony Muschang
Goffin Simon
David Monjoie
Jeremy Kersten
Yenthe
Richard Mathot
Christophe Matthieu
Denis Michiels
moylop260
Martin Trigaux
Géry Debongnie
Christophe Combelles
Josse Colpaert
Julien Laloux
Alexandre Fayolle
Antony Lesuisse
Martin
Raphael Collet
Leonardo Pistone
Alexis de Lattre
Adrien Peiffer (ACSONE)
Nicolas Piganeau
Julien Legros
buke