- In SaaS-16 we have added a related on the employee's department.
This causes access rights issues when changing the employee's department.
We do not want to rewrite all the old records, only the new ones should use the new employee's department.
Use case to reproduce:
- Install sale_stock
- Create a SO
- Cancel it
Traceback
It happens because _log_activity_get_documents need at least
one entry in the dict orig_obj_changes.
- options inside the template will not be correct if we set options in start method(template already loaded when start is call), for the correct value of options inside the template we must set it inside willstart
(PR #22751)
Before this in the event of a network failure that lasts longer than the respective return cycle of the deferred call,
this deferred will keep in purgatory forever (until reload of the client).
This is not problematic in the normal use case, but working with offline modules, such as POS or similar making use of the
long polling concept for synchronization purposes, this generates toxic behavior.
Simply: The client state never recovers on it's own from the network failure
(PR #21653)
Before this in the event of a network failure that lasts longer than the respective return cycle of the deferred call,
this deferred will keep in purgatory forever (until reload of the client).
This is not problematic in the normal use case, but working with offline modules, such as POS or similar making use of the
long polling concept for synchronization purposes, this generates toxic behavior.
Simply: The client state never recovers on it's own from the network failure
(PR #21653)
The settings of a channel were available in debug mode only. Adding a settings button on each channel allows to read/edit a channel settings easily.
Remove the unsubribe button and the settings button from the top of the page since they can be acceses another way now.
Apparently, SEO audit thingies (possibly google's own? unclear) don't
ignore *empty* keyword or description meta tags, then complain that
they're duplicated (there's a use case for SQL-like nulls).
So remove the keyword & description metas entirely if the
corresponding fields are empty.
OPW-815492
Issue 1) and 3) in 73f7567627 still
occured in 11.0. It seems this was not fully forward-ported, most
likely due to conflicts caused by
ac89783d2f.
opw-782855
When onchange RPCs return a command 4 (LINK TO), the res_id of the
record to link is given, and the BasicModel has to read the fields
in the view for that record. When one of those fields is an x2many
(for instance, displayed with widget many2many_tags), the
subrecords in the relation must be read as well (at least their
display_name).
Before this rev., this last part wasn't done by the BasicModel, and
as a consequence, the many2many_tags widget was always empty, even
though there were records in the relation.
Same thing applied to reference fields, but this is way more
uncommon.
This rev. ensures that x2manys and reference fields are correctly
fetched in this scenario.
Before this commit, there is an issue with one2many lists with records that
have been created on 'default_get': if the record has a required field that
is empty, when the user clicks on this empty required field and then somewhere
else, the record is removed from the list.
The cause of this bug is that these records have invalid field changes, here
the required field that is empty. As a consequence, it checks whether the
record is "new", and if so, removes it visually from the editable list.
(Note: a record is "new" when it is not stored in DB).
This behaviour is expected when discarding records created from "Add an item".
However, that is not intended for records that have been created as default
items of the list. These records are still considered as "new" items, because
they are not stored in DB, but they should stay in the list on discard.
This commit solves the issue by making an additional check before assuming
that the record for which we discard changes comes from "Add an item":
if the record in the list has been created before user interacts on the list
(in other words, the record has been added in the list when the user accesses
it), then we should not remove the record from the list, even though the record
has some invalid fields from the savepoint (e.g. empty required).
opw-806650
* account, board, hr_holidays, mail, sale, website_sale
Small fixes on nocontent onboarding screens.
Initial commit: https://github.com/odoo/odoo/commit/a87d761fdbf345ada5dc93e0a686b08a0f5a0417
Details:
- list: centered;
- pivot/graph: centered + empty folder face;
- Dashboard app with nocontent helper;
- Discuss inbox/starred: centered without neutral/smiling faces;
=> no faces because it's too much with animated
rainbow man when emptying the any of the boxes.
- hr_holidays: fixed onboarding screens;
- (technical) dropped obsolete 'o_view_nocontent_container' style;
- manual reconciliation 'nothing to reconcile': centered + inside form sheet;
=> renamed account's o_view_nocontent to o_view_noreconciliation,
so that it doesn't use the style of views.less.
- kanban: nocontent helper above the columns (if any);
- texts "no order to upsell"/"abandonned cart" paragraph split in two.
5ca0ef97 was forward-ported from 9.0. In 10.0 the function signature
of product.uom's _compute_price has changed. In 10.0 it uses the new
API and it no longer takes a to_uom_id keyword argument.
opw-816738
Before this commit, the domain use to retrieve pages in enumerate_pages was
wrong (mainly used for sitemap.xml). It would only show website.page that:
1. are published
2. are indexed
3. have a publishing date (whatever date, future or past).
Last point was incorrect
Now, we correctly retrieve pages that:
1. are published
2. are indexed
3. have no publishing date or a publishing date in the past
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