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
Before this commit, the notification "Odoobot has a request" would
stay on screen even though the user blocked them in Firefox.
This case occurred when the user clicks on "Not Now", which tells the
browser that the push notifications should be blocked until the next
page reload.
This commit fixes this issue, so that the notification is removed
when clicking on "Not Now", in addition to cleaning tests related
to push notifications.
Task-ID 1918476
closesodoo/odoo#29584
Imagine the following use case: you have a partner (company) with
children (person). Selling a service to that company will create
a task on SO confirmation. Then the project lives its life, and
sometime a person of that company requests a task. The task
customer is the person, but should be linked to the SO as the
time spent on its should be invoiced to the client (the company,
customer of the SO).
This is not possible, as the selectable Sale lines for a task was
the one of the exact partner of the the task.
This commit changes that by checking the commercial partner instead
of the partner. So, for reporting purpose, we can keep the real
customer of the task, and correctly invoice the related timesheet
on the SO of customer company.
opw-1915703
closesodoo/odoo#29921
Create a Sale Order linked to a timesheet, for k hours.
Add the a line for the k hours, invoice the SO.
Then, next time you add a line or modify the value of an existing line,
the SO invoice_status becomes "upselling".
Then, everytime you do it again, it triggers a recompute which writes the
invoice_status "upselling" on the SO.
Now since commit 17c9b7afee every time you write
an invoice_status as "upselling" this creates a new activity to upsell the SO.
However it was intended to run only once, the first time the status changes.
Before creating an activity, we check what was the invoice_status to ignore
records that were already in that state.
opw 1911642
opw 1919283
opw 1919284
closesodoo/odoo#29891
Sending a letter resulted systematically in an error due to the insertion of the binary of the PDF in the JSON sent to IAP-services.
closesodoo/odoo#29880
The original issue is described in #29528, and the commit was reverted
in eb19016ba3.
The root cause of the issue was that the module `base.automation`
performs a `commit()` in `_update_registry`, which is called during a
`create`. This conflicts with the `savepoint` created in `load_demo`.
We postpone the registry reload after installing the demo data. Note
that we only do this in `base_automation`, to limit the potential side
effects.
opw-1920636
Co-authored-by: Raphael Collet <rco@odoo.com>
closesodoo/odoo#29863
This revision moves the `cache_key` to the first level
dict of the cache, instead of the last one.
Doing so, we reduce the number of times the reference
to the cache key is stored in the dict.
For instance,
for 100.000 records, 20 fields and 2 env (e.g. with and without sudo)
formerly, there were 100.000 * 20 * 2 occurences of cache key references
now, there is only 2 references.
Storing references to an object consumes memory.
Therefore, by reducing the number of object references
in the cache, we reduce the memory consumed by the cache.
Also, we reduce the time to access a value in the cache
as the cache size is smaller.
The time and memory consumption are therefore improved,
while keeping the advantages of revision
d7190a3fd0
which was about sharing the cache of fields
which do not depends on the context, but
only on the cursor and user id.
This revision relies on the fact there are less different references
to the cache key then references to fields/records.
Indeed, this is more likely to have 100.000 different records stored
in the cache rather than 100.000 different environments.
Here is the Python proof of concept that was used
to make the conclusion that setting the cache_key
in the first level dict of the cache is more efficient.
```Python
import os
import psutil
import time
from collections import defaultdict
cr = object()
uid = 1
fields = [object() for i in range(20)]
number_items = 500000
p = psutil.Process(os.getpid())
m = p.memory_info().rss
s = time.time()
cache_key = (cr, uid)
cache = defaultdict(lambda: defaultdict(dict))
for field in fields:
for i in range(number_items):
cache[field][i][cache_key] = 5.0
# cache[cache_key][field][i] = 5.0
print('Memory: %s' % (p.memory_info().rss - m,))
print('Time: %s' % (time.time() - s,))
```
- Using `cache[field][i][cache_key]`:
- Time: 3.17s
- Memory: 3138MB
- Using `cache[cache_key][field][i]`:
- Time: 1.43s
- Memory: 756MB
Even worse, when the cache key tuple is instantiated inside the loop,
for the former cache structure (e.g. `cache[field][i][(cr, uid)]`),
the time goes from 3.17s to 25.63s and the memory from 3138MB to 3773MB
Here is the same proof of concept, but using the Odoo API and Cache:
```Python
import os
import psutil
import time
from odoo.api import Cache
model = env['res.users']
records = [model.new() for i in range(100000)]
p = psutil.Process(os.getpid())
m = p.memory_info().rss
s = time.time()
cache = Cache()
char_fields = [field for field in model._fields.values() if field.type == 'char']
for field in char_fields:
for record in records:
cache.set(record, field, 'test')
print('Memory: %s' % (p.memory_info().rss - m,))
print('Time: %s' % (time.time() - s,))
```
- Before (`cache[field][record_id][cache_key]` and cache_key tuple instantiated in the loop):
- Time: 4.12s
- Memory: 810MB
- After (`cache[cache_key][field][record_id]` and cache_key tuple stored in the env and re-used):
- Time: 1.63s
- Memory: 125MB
This can be played in an Odoo shell, for instance
by storing it in `/tmp/test.py`, and then
piping it to the Odoo shell:
`cat /tmp/test.py | ./odoo-bin shell -d 12.0`
closesodoo/odoo#29676
* = account, sale_management, website
Settings that are using groups internally should not appear on the user form
without using debug mode.
The admin should not get the idea that he should configure those per user,
because they are going to be reset if/when changing the general setting.
closes#29842
PR: #29860
The generated query in _generate_goals_from_challenge lacked spaces
between the date clause, which caused a traceback.
The traceback only appears since v12 and above, because the dates are
now casted as dates (::date) in SQL, which has to be followed by a
space. Before that it was "fine" as SQL does allow you to write
g.start_date = '10-10-2017'and g.end_date = '11-11-2017'
Closes#28773closesodoo/odoo#29836
Some aria attributes were missing on menus, and are required to ensure a
good compatibility with keyboard users and screen readers.
To solve the above, the following attributes are included:
- `aria-expanded`: this should be present in all dropdown menus. This is
set on elements with class `dropdown-toggle` and `o_closed_menu`.
- `role`: used to improve given information about what elements are for.
It is added in the following cases:
1. Non-button elements that have the class `dropdown-menu` are set to
`role="button"`.
2. Menu items that have the class `dropdown-item` are set to
`role="menuitem"`.
3. Menu separators that have the class `dropdown-divider` are set to
`role="separator"`.
This is a continuation of baa1c515c5closesodoo/odoo#29719
Suppose calling get_fiscal_year(date, day=29, month=2) with date(year=2017, month=2, day=28)
The computation steps are:
date_from = date(year=2017, month=2, day=28) - 1 year = date(year=2016, month=2, day=28)
date_from = date_from + 1 day = date(year=2016, month=2, day=29)
It's incorrect because the value of date_from must be date(year=2016, month=3, day=1)
closesodoo/odoo#29416
The week_start has been added as an option since commit 27b30daea5.
This stores as a database parameter the day starting the week, [1.. 7] starting
on Monday, while the calendar options expect to get Sunday as 7 % 7 = 0.
As a result the week number would be shifted.
Commit c72403d2ba solved the issue,
this commit adds tests for it.
opw 1916666
closesodoo/odoo#29838
The field ignored is set in javascript on company object to filter the
ones we want to show. As it is not an odoo field, it triggers a
traceback when the trigger_up 'field_changed' is called.
OPW-1921568
closesodoo/odoo#29864
The fields `validity_start` and `validity_stop` are `Date` fields, they
should therefore be compared to `datetime.date`.
opw-1918843
closesodoo/odoo#29834
Julien (juc) Castiaux
