Mainly transifex issues but also some errors found through 'grep' checks.
Fix typos and obscure english strings in xml contents, fields strings/helps, some docstrings, ...
ensuring correct translations base (and fallback when translations isn't available).
closesodoo/odoo#57276
X-original-commit: 4214f05d454bca2b60fda3a288d529c098e84f77
Related: odoo/enterprise#13053
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Have a kanban with a filter
Quick create a record in one column that won't match the domain
Before this commit, the noContent helper was displayed. This was because
the count of the group was reset to zero after the web_read_group call.
After this commit, the noContent helper is not displayed.
Note that in the quick_create situation, the records are not re-fetched
i.e. there is no search_read after the read_group.
Task-id 2251734
closesodoo/odoo#57247
X-original-commit: 0e12fa135882cd5095dbf15fe2f64231c6a84336
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce the bug:
- Create vehicle A
- Create a contract for vehicle A
- Change the license plate of vehicle A
Bug:
The name of the contract of vehicle A hasn't changed
opw:2327820
closesodoo/odoo#57251
X-original-commit: 5a031de6c456180b0f447470382e1ae1c7dbd5dc
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
This commit fixes 2 minor issues with the survey frontend layout:
- When hovering an answer option, the word "key"'s offset only worked properly
for a 3 letters word.
This does not comply with possible translations and the scss was adapted to
display correctly with any string.
- The "Continue or press Enter" block needlessly took 2 rows of space if the
text was slightly longer.
We provided more space to account for possible longer translations.
Side note: we also added parenthesis between the "add" property on the
"wrapwrap" element XML inherit to ease subsequent overrides.
(Otherwise, the next override would add its own value within our "if else"
statement and that could cause issues).
Task 2334823
closesodoo/odoo#57216
X-original-commit: f3237a2945ae522218af5a7089097c8d561af2c6
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Before when we tried to duplicate a lead without the mrr option
active, a traceback was raised.
If the MMR option was not activated, then the user was not be able to write
on some field because he was lacking the corresponding group. In this case,
the recurring_revenue and recurring_plan fields.
Now, when copying a lead, we purposefully set those fields to 0/False to
avoid a crash if the option is not enabled.
task-2325629
closesodoo/odoo#56927
X-original-commit: 1a5cc55dfeb03ad7d4a63a0286d5d33eaca3cbe2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Now, compute's methods are executed on default, which leads to a crash
when these methods try to use the actual records but there isn't one
yet (e.g. at the creation of a record).
- Fix the traceback raised when creating a lead because of the
visitor_page_count method when self.ids is empty on default compute.
- Since the default_get() and the first_onchange() are also now combined,
we need to adapt the syntax of the default get for the field opportunity_ids,
replacing the array of ids by the command syntax '[(6, 0, ids)]'.
task-2325629
X-original-commit: acbc97bfe290ef3c7b8f7a1160266e49485099ae
This commit adds a test to save the effort of re-setting the tz
cookie when it is already set. We also merge the tz cookie script
with the one defining session_info.
Commit motivated by discussion on PR #55726closesodoo/odoo#57218
X-original-commit: 0a43d8040f0c5ec8e9728b2e9da8c7d46d7292bb
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
- Go to Sales > Configuration > Settings and activate "Product Configurator"
- Go to Sales > Configuration > Attributes and create an Attribute:
* Attribute Name: Attribute X
* Variants Creation Mode: Never (create_variant='no_variant')
* Attribute Values:
- Value 1
- Value 2
- Go to Sales > Products > Products and create a Product:
* Product Name: Product X
* Variants: Attribute X (Value 1, Value 2)
- Go to Sales > Configuration > Quotation Templates and create a Template:
* Quotation Template: Template X
* Lines:
- Product: Product X - Description: XXX
- Go to Sales > Orders > Quotations and create a Quotation
- Select Template X as Quotation Template
- Add Product X in Order Lines and validate Product Configurator
The Product is added to the SO line but the selected Attribute value is not displayed
in the SO line description, as it usually does.
It comes from the fact that when using a Quotation Template, if an added Product is
defined in the Template, the description from the Template (i.e. XXX) is used instead of
the default generated description.
This is not practical as it is not possible to differentiate several Product X with
different values for Attribute X, because of its Variants Creation Mode set to Never.
opw-2322827
closesodoo/odoo#57195
X-original-commit: b4cc0f0bd4ff9b6b537041a174d5283bbd18dfbd
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
With:
- Anglo-saxon activated,
- Costing Method: FIFO,
- Inventory Valuation: Automated.
Create a PO for product AAA, receive the product and archive it,
create and try to POST the vendor bill.
> This lead to a ZeroDivisionError: float division by zero
The anglo-saxon entries cannot be generated as the product
is not valued anymore.
This commit is displaying a clearer error message for end users.
more info from SLE on 2250451
opw-2307562, 2317338, 2320080, 2311843
Fine tuning of https://github.com/odoo/odoo/commit/8ce4db8ca04cd8e5266fc186b35deef76506da46closesodoo/odoo#57016
X-original-commit: 83239af1d396cf7f5aca37e33445405238fcfc48
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Co-authored-by: simongoffin <sig@odoo.com>
before this commit, widgets which has specialData attribute
e.g.many2manyattendee were not supported in calendar popover, as widgets with
specialData attribute are meant to be supported in form view.
after this commit, widgets with specialData attribute can be added in calendar
popover, specialData method is called explicitly from calendar_popover to fetch
special data required to render such widgets.
with this commit we also did miscellaneous improvement in many2manyattendee
- many2many_attendee status widget bullet not aligned with attendee name, with
this commit bullet is aligned with attendee name.
- if many2many_attendee does not have status value then do not display status
else blank space is displayed before attendee name.
- in community tentative status color in many2many attendee tags widget has
o-brand-secondary color which is almost light grey, so due to badge light grey
color and tentative status light grey color status is not displayed. To fix
this issue, set tentative status color to simple grey which is bit dark then
badge background color.
task-2058767
closesodoo/odoo#46396
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when a user posted a message from a chatwindow, the scroll
did not move to the last message.
task-2314409
closesodoo/odoo#57183
X-original-commit: 8e4f133890b08e7e9a909abbc97b89bb5409119a
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When multiple date (or datetime) pickers are added to a website form,
the uniqueId value is used to differenciate them thanks to 694af9a19a.
It works well in a lot of case (eg. when adding several field at the
same time, or by change because other code consume uniqueId) but in this
scenario:
- add a date field on a form
- save
- add a date field on a form
it is possible have the second field targetting the first one because
they have the same `'datepicket'+uniqueId()` ID. This happens because
uniqueId is reset at each page opening.
found when working on opw-2326882
closes#57092closesodoo/odoo#57110
X-original-commit: 75ad994a628ef0d994b44cf6e25fd5340c3ecafd
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Currently on branch saas-13.5
Without demo data
closesodoo/odoo#57168
X-original-commit: 32f752b486053b19a8c6167efb5ca0813f2bf3f8
Related: odoo/enterprise#12997
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Forgotten TODO
Instead of checking in _for_xml_id (where 99% of calls are static),
verify on the few calls that accept an arbitrary argument
closesodoo/odoo#57117
X-original-commit: efc0263b2574fa355ea794514eb3285d8c449260
Related: odoo/enterprise#12975
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Values for "context" and "data" key were injected into the action
dictionnary by report_action to be used by the /report controller
later
Courtesy of William Henrotin (whe) for the test
X-original-commit: 4d43a301fd10cfeb498d9bf6b614779e26e12d16
This action is called from a product.template view and should be
possible to be executed by any stock user
X-original-commit: 177d5e833989a40726eff040ec1cc25bdef48c06
For large lists of blocked emails, the time taken to load the records in
cache becomes prohibitive. For instance on a sample blocklist of 600k
entries, the `search([])` to load them could take 80-90s to run!
And this toll is taken every time the mail composer processes an email
batch in mass-mailing mode. Technically, most of the time is spent
iterating on the list of ids many time, in order to prefetch fields
into cache by determining what's missing.
Loading the contents of the list in raw SQL takes a fraction of that
time (400ms vs 90s).
Subsequently using a set for lookups in that blocklist is also much
faster (average time complexity O(1) vs O(n)).
Example: looking up an item in a 600k-entry blocklist is easily 5
orders of magnitude faster!
```
In [1]: blocklist = set(x[0] for x in self._cr.fetchall())
In [2]: len(blocklist)
Out[2]: 634610
In [3]: self._cr.execute("SELECT email from mail_blacklist")
In [4]: blocklist = set(x[0] for x in self._cr.fetchall())
In [5]: %timeit "hello@hello.com" in blocklist
The slowest run took 35.29 times longer than the fastest. This could mean that an intermediate result is being cached.
10000000 loops, best of 3: 31.6 ns per loop
In [6]: self._cr.execute("SELECT email from mail_blacklist")
In [7]: blocklist = [x[0] for x in self._cr.fetchall()]
In [8]: %timeit "hello@hello.com" in blocklist
100 loops, best of 3: 2.24 ms per loop
```
closesodoo/odoo#57129
X-original-commit: 3b9a85754f30f0bef508d0b576ff679c87ead5da
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Using a `set` to lookup recipients that already received an email is
much faster on average than with a list. `x in list` is O(n) on
average, whereas `x in set` closer to O(1) on average.
Example: for a sample mailing with 50k recipients that is half-through,
filtering the remaining half (25k) took 10s with a list, and 1s with
the set.
X-original-commit: 7948698cc6e6b0af5fc84847ea7ec166882eda0b
tracked
On production order view, dot not show the Serial Numbers column
when in draft or when no component tracked by serial number
closesodoo/odoo#56889
X-original-commit: 4fc8374ee4470a05b27216999e341418e72f28ea
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When pos_hr is installed but not checked in the current pos.config,
the close button was not showing for non admin users.
closesodoo/odoo#57141
X-original-commit: ead7e3b801d4f7dcb2d48cf308e405d643dc5368
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
Incorrect override of message_post.
Without this decorator, message_post returns a string `mail.message(ID,)` via
RPC. Discuss needs the message ID to scroll chat window
closesodoo/odoo#57123
X-original-commit: 3939d3aa3b60e0f606a9f7defd695417f7b3f383
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Automatically load messages from a thread cache only if the thread cache is used
in at least one thread view.
Ensure thread viewer don't keep thread view records alive when they are not
displayed.
This change is particularly important for performance, to avoid spamming RPC at
init if many threads are opened in chat windows.
task-2310623
closesodoo/odoo#57121
X-original-commit: 8d3413ff647de8d98c6858062dd07dde4160af95
Related: odoo/enterprise#12979
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When a user is accessing a work order in state ready, we are updating it and
rewriting date_planned_start field. We also update accordingly the associated
slot of the workcenter calendar (leave_id), but if the ressource of this slot
is linked to another user, a record rule on resource.calendar.leaves is preventing
the update, which should occur without error, even if the user does not have
Time Off / All Approver rights.
closesodoo/odoo#57120
X-original-commit: 790fb1820fbd49d07206963077216cc304ed2b0a
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
Initial rendering of order management screen shows the list of orders
based on the previous render. This is done so that during fetching of
new orders from the server, a list of orders are already shown.
This optimization causes a random runbot error when transferring an
order from one table to the other. The moment the order management
screen is open, it will render orders with the old table, but right
after fetching of orders, the listed orders are immediately updated.
To rectify the random error, we modify the test so that instead of
immediately clicking the transferred order, we wait for its new table
to show before selecting it.
closesodoo/odoo#57104
X-original-commit: 713dd3777ca0ce9d121d5162a3d63de3237509f4
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Joseph Caburnay (jcb) <caburj@users.noreply.github.com>
Before this commit, the ListRenderer's on_attach_callback hook was
called each time the view was reloaded, even though the renderer
was already in the DOM. As a consequence, sub components were
mounted several times, which could lead to issues.
For instance, go to Inventory > Operations > Transfers, create a
new one. Change the Operation Type to a Receipt, and change again
to a Delivery: it crashed.
Task 2315149
Closes#56701closesodoo/odoo#57101
X-original-commit: 78f361fb5382e4c7aed9a4e705e20f8d8757300d
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In multi-company configuration setup, Company A and Company B.
Have a project in Company A that I want to share with a user in
Company B. The user only has access to Company B.
Share using the project link and open using the user
Traceback error will raise.
Adding a default value to retrieve in case the filter option is used
but the user has no permissions on the records.
opw-2322236
closesodoo/odoo#57090
X-original-commit: bcb62e8f6e20bccc2f2350bdc1268c495b7103da
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
The register payment wizard for invoices is fetching a default account
for the partner in a compute, without verifying the company.
This can cause the wizard to load an bank account from another company
and block the user to finish the payment.
This commit will make sure the account loaded is from the current company.
Task id #2308032closesodoo/odoo#57072
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
These tests assert that some user interactions didn't do something.
The user interactions were mistakenly expecting to trigger some
re-render.
Task-2333810
closesodoo/odoo#57091
X-original-commit: b4c4086104d815442ff6f2e92f80513f2ffad5ab
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Have a default db in US (date format mm/dd/yyy)
Change the user lang in UK (date format dd/mm/yyyy)
Go to POS, make a sale.
On the receipt screen, the receipt footer will display the date with the
US date format.
opw-2325382
closesodoo/odoo#57060
X-original-commit: 65e15d6baed602ee026825c7331d565688c4aecd
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
The method action_validate_invoice_payment() has been removed from the base
model but is still overriden in the payment module.
This commit will remove the override.
Task id #2285897closesodoo/odoo#56278
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The only reason the customer facing display was a field was that the
customers were able to modify it. As this feature is has been removed,
we can turn it into a Qweb template.
We also remove customer_facing_display.scss as it wasn't used anymore
Before this commit, when being in a form view without active field
(the field is defined on the model, but not present in the view),
the action "Unarchive" was available in the Actions menu, even
though the record was actually active.
The issue has been introduced by [1]. This commit restores the
previous behavior: when the active field isn't in the view, the
Archive/Unarchive action isn't available in the Actions menu.
[1] 220eb4db39closesodoo/odoo#57041
X-original-commit: 97b70aab69b491443d862847fbff69c4e29274af
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The return value of `send_printing_job` was not correcty formated for
the ePOS printers so the POS showed an error even though the receipt
was correctly printed.
closesodoo/odoo#57051
X-original-commit: 827c8d0b257d027504df1acf469d6c4761603550
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
It was only possible to print the tip receipts through an IoT Box.
If no IoT Box is configured, we now show the browser's dialog.
X-original-commit: 4b48109bb414b4768712d0e5d8706fd0088bef4b
Python 3.8 changed the equality rules for bound methods to be based on
the *identity* of the receiver (`__self__`) rather than its *equality*.
This means that in 3.7, methods from different instances will compare
(and hash) equal, thereby landing in the same map "slot", but that isn't
the case in 3.8.
While it's usually not relevant, it's an issue for `GroupCalls` which is
indexed by a function: in 3.7, that being a method from recordsets
comparing equal will deduplicate them, but not anymore in 3.8, leading
to duplicated callbacks (exactly the thing GroupCalls aims to avoid).
Also, the API of `GroupCalls` turned out to be unusual and weird. The
bug above is fixed by using a plain list for callbacks, thereby avoiding
comparisons between registered functions. The API is now:
callbacks.add(func) # add func to callbacks
callbacks.run() # run all callbacks in addition order
callbacks.clear() # remove all callbacks
In order to handle aggregated data, the `callbacks` object provides a
dictionary `callbacks.data` that any callback function can freely use.
For the sake of consistency, the `callbacks.data` dict is automatically
cleared upon execution of callbacks.
Discovered by @william-andre
Related to odoo#56583
References:
* https://bugs.python.org/issue1617161
* python/cpython#7848
* https://docs.python.org/3/whatsnew/changelog.html#python-3-8-0-alpha-1
(no direct link because individual entries are not linkable, look for
bpo-1617161)
X-original-commit: d4b2e9224839aed8fc160ebe5a89e0f7d4c6a5bb
Victor Feyens