`False` is not syntax valid for a domain.
It leads to errors when trying to evaluate `False`
as a domain in the evaluation of `pyeval.js`.
Therefore, using `False` as default value for `mailing_domain`
isn't correct
opw-648857
Correctly use the email_from tag from template.
This partially reverts commit 0f82346167.
"[FIX] email_template: keep email_from and outgoing server"
Remove the email_from part that was incorrect, keeping the one on mail_server_id
Instead of assigning an non-evaulated email_from in the context, specify the
email_from in the onchange method. This way the created email has an evaulated
from value. This was an issue for templates using email_from like
"${(object.user_id.email or '')|safe}"
In the _notify method method, the email_from is partially respected as it will
be used a fallback only. However changing that would introduce a modification of
behaviour not suitable for 7.0 branch.
Fixes#8409
In Accounting > Bank and Cash > Cash Registers, when clicking in "More" button
on 'Put Money In' or 'Take Money out', the date used for the bank statement line
created must be the date of the bank stattement(same behaviour then when clicking
on "Add item" in edit mode). It's forbidden to put/take money in/out for a bank
statement which is not open.
opw:647631
To compute the intervals of working time, the function interval_get_multi
used 'hour_to' and 'hour_from' from "resource.calendar.attendance" model. 'hour_to'
and 'hour_from' are not in UTC timezone. All the dates in odoo are compared in UTC.
Then 'hour_to' and 'hour_from' must be converted.
To take into account the minutes in this computation, the minutes from the start date
are added in the variable todo (number of working hours).
opw:648349
Complement of the fix 6f355623f0
Adds the button for cash registers as well since the base view is
different than the one for bank statements.
Closes#8410Closes#8342
The product_id_change was always triggered at the creation of a sale order line.
This is due to the 'type' field that is no longer present in 8.0 and makes the
condition to be always verified.
When a account.bank.statement.line is created by clicking on "Put Money In"
(Accounting(Menu)>Bank and Cash(Menu)>Cash Registers(Menu)>More(Button)>"Put Money In"),
the account.bank.statement linked to this line must be updated(by passing in the write of
this model) to compute the real closing balance. This fix allow to have the same
behaviour than when a line is manually added (with "Add Item) in an account.bank.statement.
opw:647631
The `check` decorator expects the context to be in the `kwargs`
or to be the last arguments of the method.
The `call_kw` route, which is decorated by the `check` decorator,
like every route,
expands its kwargs arguments.
Therefore, once in the `check` decorator,
the context is located in the `kwargs` key
of the kwargs.
(More simply, instead of
`kwargs.get('context', {})`
it's
`kwargs.get('kwargs', {}).get('context', {})`
As the context is not retrieved correctly,
the lang is not set correctly either,
and the sql constraints were not translated.
In 7.0, it worked, because there was a double
check, as the call_kw was called trough an rpc
(`dispatch_rpc`) call,
which was decorated by the `check` as well.
As a fix for 8.0, we apply the same logic,
we perform a double check, with an indirection.
The check decorator should probably be
refactored, but this cannot be done
in a stable release such as 8.0.
Closes#3634
To compute start and end date of a working interval this function replaced
hour in datetime object without taking into account the time zone. The start and end date
taking respectively from calendar_working_day.hour_from and calendar_working_day.hour_to are
in the time zone of the user and the datetime object are compared in UTC to avoid schedule's gap.
This is why the start and end must be converted in UTC after being replaced by these hours.
The tz_info must be removed from dates because it's forbidden to compare naive and aware dates.
opw:648349
With 3e82c94d we use the timezone in the context to format date
sequences when formatting an ir.sequence.
This commit adds the other missing context when getting a sequence, so
these sequences are also dependant on the timezone.
closes#8351
opw-646487
The total used to check which delivery.grid.line to apply must be in
the currency of the company because the delivery.grid.line records with
variable == Price are expressed in the currency of the company.
opw:647799
When creating timesheet,
default from-date and to-date are adjusted for user timezone.
Fixes#3627
User timezone considered when assigning attendance records to timesheet
Fixes#3628Closes#3632
Written in the new API even though the rest is in the old API, because otherwise we'd have to add an onchange in the views which may be a problem for existing custom modules.
We want this behavior because previously, in some cases the default values were only added at create() time, ie. possibily when the users close the pop-up, so they may never have an opportunity to see and adjust the default.
This rev. is related to 1c533b193f
The reason why we force the event Google internal id is
explained in the above commit.
Forcing the internal id must be done only when creating the
event in Google, not when updating, for retro-compatibility:
if the event is already in the attendee calendar, with a different
internal id then the other attendee, we must leave it like this,
otherwise Google will be lost.
This rev. is related to a9e3d74713
This new revision is about the same use case than above, except
that both Google users login doesn't match the Odoo login email.
e.g.
User A: A@agrolait.com in Odoo, A@gmail.com in Google
User B: B@agrolait.com in Odoo, B@gmail.com in Google.
When A creates an event, with B in the attendees, and
syncs his calendar to Google, B is not automatically invited
Google side, as his attendee email is B@agrolait.com, which
doesn't match any existing Google User (doesn't match B@gmail.com)
While the revision mentioned above, a9e3d74713,
expected the attendee to be automatically invited Google side, and therefore
expected the event to already exists in B's calendar.
Therefore, when B syncs his calendar in Odoo, as the event
was there in his Odoo calendar, but not in his Google Calendar,
the code actually think it's no - longer - there, and take the assumption
the event has been deleted Google side. So, it deletes the event
in Odoo side as well, for both users A & B.
To overcome this new issue, when the Google & Odoo users emails
do not match, while keeping the compatibility when the Google & Odoo
emails do match (and therefore the invitation is automatically sent
Google side, as the email matches an existing Google account, and
the event is automatically created in B's calendar without needing the
sync in Odoo), we now force the Google internal id to be the same
for all attendees of an event, event by Google side.
opw-645745
Confirm lines of account cash statement on closing
The `account_bank_statement_extensions` adds
a state field to account.bank.statement.line
and sets the status to 'confirm'
when a bank statement is closed.
When a cash statement is closed,
the lines remained in draft.
Closes#3584
`hr_timesheet_invoice.py` overrides `on_change_account_id`
of model `hr.analytic.timesheet`.
The super call wasn't done, probably because this on_change
method in the base model was trivial:
`return {'value':{}}`
Nevertheless, if another module overrides this on_change,
according to the module dependences,
this method could have been called first in the calling chain,
discarding the changes from the other overriden
`on_change_account_id` methods, preventing
any customization in this on_change according to the
current database state.
Closes#8248
When we export a recurring event, there was an error since there is
virtual ids (like '{real_id}-{date_of_the_event}').
Events steming from a recurring events are in fact shown virtually. In
the database there is really only one event and a suffix is appended to
the id to target a given instance of a recurring event.
If we want to separate a recurring event from the instances, we can edit
the instance and use the link "Update only this instance", once done
this instance is separated for the recurring event.
This commit if one or more recurring events instances are selected when
an export is done, will only export one source event of each of the
events occurences.
fixes#7932closes#8262
opw-647676
Regarding _schedule_days, similar thing was done in
saas-6, @ fd5e7f2.
When the argument `days` was negative, the
returned intervals were wrong.
Regarding `get_working_intervals_of_day`,
calling this method without
`default_interval` and calendar
set crashed.
Closes#8208
Escape text nodes changed via the web editor before sending the content
it to the server controller.
It is done since the content is unescaped one time when being displayed,
and it is not done for inline style and script tags (which may be
injected by dropping a snippet) since that would break them.
replacing the solution in cdb900044.
When clicking on the button "Refresh Challenge" in the "gamification.challenge"
view form, all the "gamification.goal" records linked to this challenge must
be updated.
opw:647983
In bank statement reconciliation, when selecting an other partner(with the pencil),
the possible invoices to reconcile must be suggested.
opw:647210, 647885
On a first edition of a view list editable, scrolling before the first
edition might cause an issue: the editing fields are higher than they
should.
This commit solves this.
This issue stems from jQuery .offset({value}) function which is broken
if the element we want to position:
- is in absolute postionning,
- is inside a scrolled element in non static positionning,
- has not both top and left css property setted,
- has no ancestor element between itself and the scrolled not in static
positionning.
This issue happens less (and probably not at all) in saas-6 since the
last condition is most often not met thanks to this change:
https://github.com/odoo/odoo/commit/1ccd87a#diff-27c072074221456684bfc5f150ca0bc9R876
This issue of jquery is solved since jquery 3.0.0-alpha1:
https://github.com/jquery/jquery/commit/2d71594
( the issue is shown in https://jsfiddle.net/wpjrnggf/ and we can see it
is solved with jQuery 3.0.0-alpha1 https://jsfiddle.net/L6ykpjgy/ )
closes#8251
opw-647622
In the case of a signup with token, the user login
already exists, and changing of login (email) is
therefore not allowed.
It's the same behavior than in the reset password
view (`auth_signup.reset_password`)
opw-648125
/var/log/syslog gets filled up quicker than usual because of all the
crontab logs:
Aug 26 09:29:01 raspberrypi /USR/SBIN/CRON[21223]: (root) CMD (rm /var/run/odoo/sessions/*)
It makes more sense to just look for usb devices that identify as a
printer and use whatever we get. This saves us time having to explain to
users how to add their particular printer to the whitelist to test.
The function "name_search" defined on "product.template" made a search on
"product.product" name to give the "product.template" which matched with the
search. The number of results given by the name_search on "product.product" is
generally limited to 8. The problem was when for example there were 8 variants ("product.product")
with a name begining by "AA" for the same "product.template" T1 and another "product.product"
with a name begining by "AB" linked to T2. In this situation, if a name_search was made on "product.template" with a name="A",
the result got was just the the name of T1 linked to the 8 variants instead of the name of the
two templates (T1 and T2) due to the limitation.
opw:647066
This commit removes the request of having gzip or deflate data for two
requests to google drive API.
Previously the code worked since google api would send ungzipped data
(maybe base on urllib2 user agent or other input parameters) but after
a recent change on google part, it is not anymore the case.
closes#8243
opw-648007
note: if we did not do this, we would either need to use requests or add
custom uncompressing code for urllib2 response content.
Product pages ulrs can be indexed by searches engines.
The product category can be included in the url.
If the category has been deleted, accessing
this page should still work anyway
opw-648008
It has no sens to map a tax by a tax included in the price because
when a tax is included in the price, the price must be computed
according to this tax.
-account:_fix_tax_included_price
If a fiscal position mapped an included tax on a SO or on a PO line
then the price unit of the product must be recomputed.
-purchase: onchange_product_id test
Test that when an included tax is mapped by a fiscal position, the included tax must be
subtracted to the price of the product.
-sale:product_id_change test
Test that when an included tax is mapped by a fiscal position, the included tax must be
subtracted to the price of the product.
opw:647321
f26b94f had as goal to filter the taxes of the product
according to the company when the sale.order
was created/edited as SUPERUSER_ID
(Who ignores the record rules).
Unfortunetaly, to filter the taxes,
it used the company of the customer,
while it's actually the company of the order which
should be used.
Indeed, for instance,
partners can be shared among all companies.
It was way less simple to access the company
of the sale.order, this parameter being
not available in the on_change method signature.
This is the easiest way to solve this issue
without breaking the API / retro-compatibility.
opw-647819
Previously when replacing time related sequence in a prefix or suffix of
a sequence, the timezone used for the time values would always be the
server's timezone.
With this fix, the context timezone is used if available (UTC is used
otherwise).
closes#8159
opw-646487
When subscribing a document, a partner is created based on the email address.
Instead of using the email address as the name (which is a bit too spammer
friendly), only keep the first part of the email address as a name.
Following discussion https://www.odoo.com/groups/59/13640169
This revision is related to cfbd086b09.
This is the same use case than above, but with a different
currency than the one of the company, for the field
`amount_currency` this time.
Closes#8135
opw-647639
This is a regression from rev.
1cedcf6abb
Not updating the product uos qty on updating the uom qty
is wrong, and it has multiple side-effect.
The SO line margin not being correctly recomputed
when changing the quantity is one of them.
opw-647902
Introduced by f7f18ba5b1
The lang of the customer must be used.
In the drop shipping use case (order.location_id.usage == 'customer'), the customer
is in the destination address of the order (order.dest_address_id).
opw:647628
Introduced by 9abf7a2010
When clicking on the many2one edition button of the field "email_registration_id" in the
"event.event" view form, the return action id was not available in the action.
closes#8147
opw:647698
The propositions of reconciliation for a bank statement line must
be taken from account move lines with the same partner_id of this
bank statement line or without partner_id.
opw:647199
When a move is creating from a purchase order line and the destination
of the order("location_id") is "customer", the description of the created
move must be the name of the product. To avoid that the supplier description
of the product appears on the customer invoice because in "drop shipping",
the customer invoice line is created with this created move by the function
"_get_invoice_line_vals".
opw:647628
When converting an invoice in journal entries,
the invoice lines amounts must be currency rounded
not only when the invoice currency is different
than the company invoice,
but also when they are the same.
Otherwise, a rounding issue can happen
if the `Account` decimal accuracy is greater
than the currency rounding, the journal entries
total and the invoice total could be different.
e.g.
- Set decimal accuracy of Account and product to 4
- Create a supplier invoice, any supplier
- Add a line as follow:
- Product: None
- Quantity: 2057
- Price unit: 11.9150
- Tax: 16% (create a new tax with 0.16 as percentage)
- Validate the invoice
- In the other information tab of the invoice,
click on the journal entry
- Notice that the first line has as credit amount 28430.6150
While the invoice total is 28430.6200
- Now if you try to create a bank statement with one line
of -28430.6200 and as partner the supplier you chose
in the second step of this explanation, and try
to reconciliate it to the invoice created above,
the above won't be marked as paid, while it should.
opw-647639
Fixes#8135
If there is no partner on the contract to which are invoiced
the timesheets, the error telling you to set a partner (and a pricelist)
must be raised before trying to create the invoice, not before
creating the lines of the invoice.
In this case, this is because if you set no customer
on the contract, there is no pricelist automatically filled
as well, and the currency is took from the pricelist,
which will be False in the case there is no pricelist
on the contract, and you cannot create an invoice
with no currency set.
opw-647672
The string belongs to the account module, but was wrongly added to
stock.pot. This commit adds it to account.pot, but also keeps it for the
moment in stock.pot to prevent losing existing translations in
Transifex.
In the standard account_analytic_account module,
the employees have the read access to the analytic accounts.
Therefore, it makes sense to give the read access to the
account distribution plan, so an employee can choose one
in a purchase order when the Analytic Accounts for Purchases
is activated.
opw-647606
When the Purchase analytic plans module is not installed,
the analytic account field in the lines of the purchase order
is available only for the group
`Analytic Accounting for Purchases`
It should be the same for the field of the analytic distribution plan.
Otherwise, it will lead to an access error if you don't, as
you do not have access to the required model.
opw-647606
When a product is in "dropshipping" with one supplier and with a few SO
created for the same customer, the origin of the resulting PO must
include all the SO names.
opw:647409
- set keyboard layout to us
- install GNU screen
- add udev rules to make USB devices accessible to the usbusers group
- setup crontab to delete odoo sessions/*
- define inputrc and vimrc
When changing the min_date / max_date in a move,
the date change wasn't propagated to its picking.
The use of store triggers is needed in such a case,
`store=True` isn't enough
Fixes#1862Closes#3278