Create a new column in Project, add a record and then hit 'Archive Records' : a
traceback occurs.
When creating the new column, the `groupedBy` attribute on the datapoint is set
according to the parent list datapoint, which makes no sense as the records are
not grouped inside the column.
The mentioned attribute is now removed as the records cannot be grouped inside
the column.
Server actions return an action to execute, or false. When they
return false, an 'ir.actions.act_window_close' must be executed,
such that the current dialog closes (if any) and mostly, the
'on_close' handler is executed, which ensures for example that the
current view is reloaded.
The case where server actions return false has been broken by rev.
32b8cec53. It produced tracebacks in several models, when clicking
on some actions in the 'Action' dropdown. For instance, in lunch,
go to Configuration > Products, open one in a form view, and click
on 'Lunch: Archive/Restore products' in the Action dropdown.
Previously to this merge portal customers receiving a notification email
on a shared document could not directly reach the document on the portal
as the access token was not given to them. The only way to give access
to portal was done using the specific email implemented for sale orders
or invoices. This behavior is now extended to notification emails.
This merge adds the token support for customers through inheritance in
portal mixin. It also fixes inherit order so that the call chain
effectively goes through portal before calling the mail.thread base
implementation.
This merge is related to task 40064. #Closes #21426.
Purpose is to enable override of mail.thread methods in portal mixin.
An example is the _notification_recipients method defined in mail.thread
and customized in portal.mixin.
Purpose is to enable override of mail.thread methods in portal mixin.
An example is the _notification_recipients method defined in mail.thread
and customized in portal.mixin.
Purpose is to enable override of mail.thread methods in portal mixin.
An example is the _notification_recipients method defined in mail.thread
and customized in portal.mixin.
Purpose of this commit is to allow customer portal to have an access link
containing an access token. Portal mixin now override the default mail.thread
behavior when classifying recipients of a notification email in groups.
If the model has an access_token and a customer field correctly defined
the recipient that matches the customer will have an access link in its
notification email holding the access token. It will also contain an
auth signup token if it is enabled.
Purpose is to allow to add parameters to the view link. Currently it is
formatted like '/mail/view?model=model&res_id=res_id'. We would like to
be able to add parameters like access token for example. It will allow
to create view links specifically tailored for some people like customer
portal.
This reverts commit ab65a02f5a.
Before that commit "Sales / User: Own Documents Only" had access to
self-assigned or without salesperson assigned leads.
With the change, user of this group were meant to also have access to
leads with an activity to which they were assigned to.
But:
- this is a different behavior from activities on other models.
- there is a technical disability that in some case prevent to have
fully functionning access rules if based on one2many with
auto_join=True (we will try to fix this in master).
opw-816246
closes#23085
Revision of https://github.com/odoo/odoo/commit/02ec09cb1c3e2d7bc7968f40c18f2208d7f3f498
One of the purposes of the previous commit was to test discuss.
There was an attempt to test im_livechat, but it has been aborted due to the possibility
to use livechat on an external website.
However, some bits remain from this attempt, such as LivechatButton becoming a JS service
provider in order to use those services with the external lib. LivechatButton was not working
for the following reasons:
- ServiceProviderMixin.init was not called (so it couldn't load any service);
- On website, there are two service providers (LivechatButton & websiteRootInstance).
This fix ensures that LivechatButton does not rely on JS services, such as the bus_service.
The pos must be in http to talk to the posbox
The problem here is that imgs can sometime be fetch in https depending on the server's configuration
Before this commit, when converting imgs to base64, a "Tainted canvas" traceback was thrown by the browser
due to difference in domain that http VS https make
After this commit, we explicitly allow cross origin when fetching the image
while requiring the server to send the right headers
OPW 805860
Revision 89c63096cb fixed the creation
of the taxes applied to account move lines when validating a pos session
The fix though overlooked two things:
- protection against recursivity
(nothing prevents a group of taxes to have a grand-parent as one of its children)
- the fact that when converting a group of taxes into a regular computed one,
the field children_ids is never reset
Those two caveats provoked a "max recursivity error" in python within the right conditions
This commit protects the recursive process from the two issues, and there is no traceback
OPW 816163
Rev 666b594842 introduced an autodetection
mechanism for transforming base64 embedded images inside emails into
attachment with a Content-ID URL.
The patch suffered from several issues:
- the base64 detection regex failed to detect base64 data that is folded
over multiple lines - which happens to be the default in many Python
versions when a binary field is read, or when using the base64 codec
to encode a string.
(Those cases where left untouched and the image was therefore missing)
- there was a logic error in the code when the same image was present
multiple times, leading to an exception (`name` variable was
referenced before being assigned)
This patch addresses both issues.
Fixes OPW-815073
Having base_vat installed (but is potentially more general than this)
In the pos frontend, try to save a partner with an incorrect VAT
Before this commit, the generic and cryptic message "your internet is probably down" was displayed to the user
when a python exception occured
After this commit, we display the exception's message
OPW 807656
We should normally stick as close as possible to the version we depend
on in the official DEB packages. This in turn depends on the version of
Debian stable at the time of release - for 9.0 that would be Debian 8
(jessie) and thus Pillow 2.6.1.
However Pillow versions before 3.1.1 suffer from a few issues that could
lead to crashes of Odoo workers. The bugfixes have been backported in
the DEB packages for Pillow, so users of Debian/Ubuntu LTS versions
won't be affected if they are keeing their systems updated.
However it's worth an exception to our rule for pip users.
FWD-PORTS: skip
In order to help limit leaves recording errors. We need to add some
configuration on leave type object. For example we need to avoid people
taking legal leaves 2016 on 2017.
* Add validity dates : start and end dates on the leave type. An empty
end date means forever
* Double validation : change the checkbox into a radio button with now
three choices :
- Human Resource Responsible
- Manager
- Double Validation
* Add a sequence field, using handle widget
* Add a field, to specify if the employee can select the leave type in
his allocations, requests or in both of them
We need to check if resource module takes into account the timezone of
the employee taking a leave and the timezone of the user asking to see
when this employee has taken some leave.
Basically everything should be done in UTC internally and then converted
back to the user's timezone.
The emails sending is skipped during the tests.
The mecanism to determine if the server was running tests
was to check if the attribute `testing` was set for the thread.
Unfortunately, this `testing` attribute is removed/set to false after the loading/installation
of the modules is done, and phantomJS tests are ran post-installation,
and therefore the emails that were potentialy sent following an action
performed in a PhantomJS tour were not skipped.
This occurred for instance in the tour `project.tour`,
when the responsible of a task was changed,
the sending of the assignation notification email was not skipped.
In the case the machine on which the tests are ran does
not have an smtp server (or mailcatcher) running on the port 25,
this resulted in a test fail.
As the old name 'date' of the filter was the same as the field date, the context key 'search_default_date':1 was ambigous and not well processed by the web client.
It was indeed considering on field by default and was trying to set value 1 on date field, which is not possible and it gave traceback.
Christophe Simonis