The argument `auto_commit` was omitted in `send_mail` overrides.
`auto_commit` was therefore allmost always `False` when
reaching the `send` method of model `mail.mail`,
in `mail/mail_mail.py`. At least it was when either
`sale`, `purchase` or `account` were installed.
Not committing the sql transaction leaded to the fact
the mail statistics were never created when the queue
process was interrupted (e.g. process time limit reached),
and knowing if an email in a mass mailing has already been sent or not
is based on the fact the mail statistics exists or not.
Therefore, if a mass mailing sending process was interrupted,
the emails were re-sent over and over.
opw-649106
Once the website_quote module installed,
the "default template" is set by default
on all new quotations.
There is an onchange on the field `template_id`,
setting some values according to the template,
including the description in the website quote.
When creating the quotation / sale order from
the web interface, the on change is triggered,
and the values related to the template are correctly
loaded.
However, when the quotation is created through
the code or the API, the default `template_id` was
correctly set, but as the onchange wasn't triggered,
as onchanges are automatically triggered only
through the webclient creations, the related values,
issued from the template, were not, such as
the quote website description, or the date expiration,
and so on.
In particular, this happen when creating a quotation from
an opportunity, through the "Convert to quotation"
button.
opw-648920
In e-commerce, on a product page. If the product has some attributes
("product.attribute.line" model) with several values for at least one attribute
(which means several variants for one product), the display of these attributes must
respect the sequence defined in:
Sales > configuration > products > attributes("product.attribute" model)
opw:648634
In e-commerce, on a product page. If the product has some attributes
("product.attribute.line" model), the display of these attributes must
respect the sequence defined in:
Sales > configuration > products > attributes("product.attribute" model)
opw:648634
In 8.0, the products labels report is a non-customizable
xml report. Among others, the product name is displayed.
In saas-6, this report has been converted into
a customizable, qweb report. Unfortunately, the product
name has been forgotten during the convertion.
opw-648643
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
Consider the following setting:
- on model A, field F is computed, stored, and depends on field G
- on model A, field one2many G to model B, with inverse field H
- on model B, field many2one H is inherited (_inherits) from model C
- on model C, field many2one H is stored
When adding records of model B, the field F must be recomputed. In order to
determine which records to recompute, one searches model A with a domain like
[(G, 'in', ids)]. In expression.py, this is resolved with an SQL query like
select H from B where id in {ids}
This query fails, since the field H is not stored in model B. This happens in
general if H is not stored (it may be any computed field). In that case, one
should instead browse records from B, and read field H through the ORM.
A test case has been added: it introduces a many2one field in a parent model,
and a one2many field using the inherited many2one on a child model. The test
checks whether one can search on the one2many field.
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
Can use 'add' or 'remove' on attribute tag.
'add' values are stripped and add to the current value preceded with a space.
'remove' may contain more than one value separate by spaces.
'separator' by default space the string are splited by spaces.
E.g.:
<attribute name="thing">bob tata lolo</attribute>
<attribute name="thing" add="bibi" remove="tata"/>
thing contains: bob lolo bibi
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
- GMail caches the images contained in emails
- It seems to take the opportunity to replace `%20` by `+` in the images URLs
- Werkzeug doesn't seem to handle '+' in URL as spaces (at least not as a %20)
(See https://github.com/mitsuhiko/werkzeug/pull/756)
When inserting a fontawesome character/image,
there are spaces in the CSS color,
e.g. `rgb(255, 255, 255)`.
And window.encodeURI, doing its job, encode this as
`rgb(255,%20255,%20255)`
This, in the URL, is supported by Werkzeug.
However, Google changes this to
`rgb(255,+255,+255)`
which is not supported by Werkzeug.
The fontawesome images were therefore not available in
mass mailing sent to GMail addresses.
This revision removes the spaces from the CSS color.
This is not the best fix, but
- We cannot really ask Google to not change %20 by +
- We cannot afford to wait the support of the '+' as spaces in Werkzeug
opw-648456
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
Goffin Simon