In case a record is no longer referenced in the updated module, its external id
is deleted.
If the linked record still exists, it is deleted as well.
This last clause was incorrect as the record may still be referenced in other
modules.
If a field is declared in module A
class FooA(models.Model):
_name = 'foo'
bar = fields.Char()
and overriden in module B
class FooB(models.Model:
_inherit = 'foo'
bar = fields.Char(translate=True)
In case the field is no longer inherited in module B (code change, moved to
another module,...), the ir.model.field record for bar was deleted.
Two external ids are linked to field bar:
A.field_foo__bar
B.field_foo__bar
The ir.model.field record should be dropped only if both ir.model.data entries
are no longer loaded.
Otherwise, only the ir.model.data entry should be deleted (i.e. B.field_foo__bar
in the above example).
Fixesodoo/odoo#29820closesodoo/odoo#30018
When creating a banner using the web editor, the targeted image
appears centered in the editor but is aligned on the left in the
email.
The issue also happened with other alignment (left in a centered
widget, right, ...) for example on outlook 2007 and should be solved
with this changeset.
note: 12.0 version of #29214
opw-1904827
Co-authored-by: Nicolas Lempereur <nle@odoo.com>
closes#29954
Before this commit, BS4 color for active list-group-item (white) would always
be overriden by our portal custom css to the BS4 color for inactive one.
Part of #29884
Since 12.0, some modal footer button order were changed. The primary button
would not be the one in the modal footer corner.
This is against bootstrap but more annoyingly, users are intuitively clicking
on the secondary button, ending up closing the modal and losing form
information they entered.
This commit simply fix the regression from 12.0 as before 12.0 these buttons
were positionned correctly.
Note that a commit in master (saas-12.2) will fix all the other ones that were
wrongly positionned before 12.0.
Step to reproduce:
- Go to an event having the possibility to register.
- Click on 'Register Now', a modal is shown to write details (name, email..)
- You intuitively click on 'Cancel' as it is the bottom right button
|________________________________ CONFIRM _ CANCEL _|
- The modal is closed, if you try to open it again your infos are lost
Closes#29884
task-1922120
Layouts were not accepted by Pingen due to the fact that the class that we added to the recipient's address was not present in stable versions.
The format was therefore not adapted to Pingen.
We then remove this class to fix layouts in stable versions.
closesodoo/odoo#29976
In community, when entering the Manufacturing app, the first view is the
Manufacturing orders list view as it's not the case in enterpise, the
two steps are only necessary in enterprise.
Note: even if it fix the tour, the main bug could still be there.
closesodoo/odoo#30016
- When installing an accounting l10n module, the method `try_loading_for_current_company`
is called and could cause a deadlock.
The deadlock is caused by the fact that if the installation is started
via a web request the code tries to retrieve the current user's
company by doing `request.env.user.company_id`.
This causes issues since the installation code has its own postgresql
cursor while calling `request.env.user.company_id` will create its own
cursor.
So two cursors exists for the same Odoo worker.
The installation cursor asks for a lock on `res_users` while the
second cursor (the request one) will try to read on `res_users` and
wait the first lock to be dropped.
The lock is never dropped since the python code isn't running anymore
waiting for the `request.env.user.company_id` to be completed.
Causing the deadlock.
To fix the issue, we avoid the creation/usage of a cursor created by
`requesŧ`.
So to retrieve the current user's company, we read the user id on the
request's session, then browse the `res.user` record with the
installation cusror.
Fix issue introduced by commit d40956c790closesodoo/odoo#29927
The tests of the sale module are not constistent. Success depends on version
in use (com vs ent) and the modules installed (sale, stock, event_sale).
**Fix 1**
The "Description" field is updated by a onchange while saving the record.
**Fix 2**
The `sale_stock` module adds a new step to click "ok" on the warning modal
shown when saling a product without enough of that product on hand. The added
step was added to test_01 (that doesn't show the modal) instead of test_02.
**Fix 3**
There is a difference between the price of the SO between community and
enterprise.
**Fix 4**
The event_sale module changes the form view thus need to perform more steps
to create a record.
opw-1912266
closesodoo/odoo#29679
When running in kiosk mode, it is necessary to refresh the interface
once a week since the session is garbage collected.
The garbage collection method `session_gc` relies on the last
modification time of the session file. However, the session file is only
saved when the field key `should_save` of the session request is `True`.
This happens when the session is `modified`, i.e. an item on the cookie
is set.
In practice, the session is saved at each reload of the page. Regular
RPC calls, such as the one used in commit 6e1b660f9c, do not
trigger a modification of the session file. Therefore, we create a new
route which explicitly sets the session as `modified`, which ultimately
triggers a `save` in `get_response`.
opw-1917254
closesodoo/odoo#29919
Following commit c4e0e5461c
Before the current commit the placeholder was used at the end of the logic, so
it ignored the parameters such as width, height, crop, ...
Now the image is correctly replaced by the placeholder before we try to apply
the rest of the logic.
One example of such problem was in website_sale_comparison, on the comparison
page, if we tried to compare a product which had no image, the placeholder image
was bigger than expected.
task-1929646
closesodoo/odoo#30525
The purpose is to set the style of the product label and product barcode
reports that was lost in bootstrap v3 to bootstrap v4 conversion.
opw-1920478
closesodoo/odoo#30407
In 3d2ca8104e some change were introduced to the graph view.
But part of it had no sense when displaying data over 2 group by.
eg. if the first level has 2 groups (2018, 2019) and each second level 2
groups (Done,Cancelled), we could have:
2018/Done: 0
2018/Cancelled: 5
2019/Done: 8
2019/Cancelled: 9
this gives us two main groups [2018: 5] / [2019: 17], the code
remove the 2018 because [2018/Done] is 0 so we have something odd
with columns not in order, and in stacked bar chart some part of
a bar at the wrong offset
opw-1932517
closes#30529
As `formataddr` only accept strings as arguments, an exception was
raised when trying to notify a mailing list channel with followers
without email.
closesodoo/odoo#30492
Based on the stored computed amounts on lines,
it seems better to use read_group on lines instead
of recomputing the whole bunch of taxes and amounts.
closesodoo/odoo#30398
BS3 used to add ::before and ::after elements on all containers so that
margins and floats are cleared inside containers. As lots of current
odoo layouts may rely on this for some alignments, this is restored (at
least for a while) here only for main containers of the frontend.
In master, we should use proper layouts to avoid the need of this.
task-1889238
closesodoo/odoo#30510
In dff64b6f7ca some copied views with no link to a module would be
removed after module uninstall.
But this has some side effects when the website module is being removed.
For example:
- website_theme_install, website are installed
- website is uninstalled (which will uninstall website_theme_install)
- website.theme_customize view can't be removed because it is used by
copied view website_theme_install.customize_modal
- after uninstall _remove_copied_views will remove the view
website.theme_customize but when trying to remove associated
website.page will throw an error because website_page table does not
exist
This issue does not happen if we uninstall first website_theme_install
then website (since like this the reference is not an issue).
The issue also happen with overriding views in theme_bootstrap and
possibly elsewhere.
With this changeset, copied views are removed before uninstalling module
data.
opw-1924714
closes#30191
Sending a message on the chatter is painful as you need to scroll to see
the buttons and click to open the composer. Then again click to set the
focus in the composer (making the keyboard appear) and scroll again to be
able to write your message.
On a view form when clicking on the "New Message" or "Log Note" buttons the focus
should be put in the text field, then opening the mobile device keyboard
and scroll the view to make the text field visible.
NB: in some case on Android (both WebView and Google Chrome) the scrolling is
not operated correctly resulting into the text field being hidden behind
the keyboard. This issue looks related to some timing between the actual
focus() call and the keyboardi appearance triggered by the operating system.
Sadly we don't have any control on that part.
Related to task 1891955
closesodoo/odoo#29239
- Install eCommerce, Inventory,
- Go to website setting and set availability of products as a "Show
inventory on website and prevent sales if not enough stock"
- Create new service type product, and publish it
- Go to shop
The button Add to cart is disabled.
Apply this option to stockable products only.
opw-1931638
closesodoo/odoo#30444
Before this commit, if you duplicate a published record on the website,
the copy was already published, while in most of case you need to update
it to adapt to the new content. There doesn't make senses to duplicate the
same content on a website and let the duplicate content.
Task-1930058
The display of many fields in the setting overlaps other elements,
e.g. OnSIP WebSocket, Domain and VoIP Environment in General Settings.
We override the flex: 0 0 66,6% set by Bootstrap by flex: 0 0 auto
so that everything automatically looks nice.
closesodoo/odoo#30359
Combining a list of elements containing only the monoid's unit should return the
unit.
Since the unit is skipped, it would return an empty domain instead of the unit,
meaning that (0, '=', 1) could not be used in a group rule.
To test this, create a record rule on a model M with domain (0, '=', 1)
that applies to group G.
Log in with a user in group G and access model M; you can read everything
(provided no other record rule applies) whereas you should see nothing.
Because of expression.AND(global_domains + [expression.OR(group_domains)])
we want the empty domain to still be left untouched, even if it violates
the OR's unit rules (i.e. OR(empty, OR(R)) = OR(R) <=> OR(empty) = unit).
Meaning that no group rule would reduce to having a (0, '=' 1) group rule.
So in the end we don't really care about all that algebraic nonsense.
closesodoo/odoo#28765
When creating the list of attachments, no fields information was given, making
the search_read read the content of each field, including the infamous datas
Already fixed at 73d9b9588f but the domain was not backported
Fixesodoo/odoo#30394closesodoo/odoo#30415
Before this commit, a user could unintentionally discard a
notification from a document that he does not have access
rights at the moment.
Steps to reproduce:
1. Setup:
- Odoo with multi-company
- Two companies: "MyCompany" and "SuperCompany"
- Two users "Admin" and "Demo", both have access to being in
both companies
- "Demo" has Notification management in Odoo in the user preferences.
- "Admin" is logged in "MyCompany"
- "Demo" is logged in "SuperCompany"
2. Scenario:
- "Admin" mentions "Demo" in a log of a document from "MyCompany"
- "Demo" receives the notification and click on the notification
from messaging menu.
> Dialog prompts that Demo does not have access to the document (OK)
> Empty chat window is open (not OK)
- "Demo" closes the chat window
> Notification is marked as read (not OK)
This commit fixes the issue by aborting the opening of a
chat window if the user does not have the access rights
at the moment. It should prevent marking the notification
as read by mistake by closing the chat window.
Task-ID 1931313
closesodoo/odoo#30414
If a user has no rights on sale, he should not see the sales menuitem
on the dashboard.
This is because the report_sales_team, which was set on a menu restricted
to managers, has been moved to a menu without groups.
We therefore set the group salesteam.manager directly on report_sales_team
to have the same rights as before.
Similarly, this same report is visible in the CRM app without manager rights,
so we put them explicitly on sales_team_menu_team_pipeline.
Also reverts commit 2cdc1cc9ce that put the groups
on the sales root menu.
It is unnecessary to do so, since when all submenus are hidden to a user,
then the app icon is automatically hidden to the user.
This practice allows customisations to put views accessible without any rights
on that specific app.
Since the sales.team manager has been put back on the correct dashboard,
this previous commit is now useless.
opw 1914373
closesodoo/odoo#30390
The display of long module names, e.g. 'EMail Marketing' or 'General Settings',
overflows on the following line, resulting on the superposition of text.
We fix that.
closesodoo/odoo#30355
The copy() is unnecessary, and it is introducing an issue because
product.template.attribute.value are not created correctly for copied templates.
The test can be done on the original data, the transaction is going to be
reverted either way.
closesodoo/enterprise#3301
The copy() is unnecessary, and it is introducing an issue because
product.template.attribute.value are not created correctly for copied templates.
The test can be done on the original data, the transaction is going to be
reverted either way.
closesodoo/enterprise#3301
Veikko Väätäjä
