When we group by date with DST change within a range, we could get a
reocrd inside two date range grouping, or inside no grouping.
This is because we computed range just with [+ 1 month], so we possibly
had these ranges (in UTC):
- October 2019 : [('datetime', '>=', '2019-10-01 02:00:00')
('datetime', '<', '2019-11-01 02:00:00')]
- November 2019 : [('datetime', '>=', '2019-11-01 01:00:00')
('datetime', '<', '2019-12-01 01:00:00')]
So a record on 2019-11-01 01:30:00 would be both inside October and
November.
This happen because the DST is removed on happen on 27 October 2019 and
this was not taken into account when computing the end of the range.
With this changeset, for the given example aboth, we will have:
- October 2019 : [('datetime', '>=', '2019-10-01 02:00:00')
('datetime', '<', '2019-11-01 01:00:00')]
Added test without the change fails with "AssertionError: Lists differ"
because:
- "Q1 2019" finished on 17:00:00 instead of 16:00:00
- "Q3 2019" finished on 16:00:00 instead of 17:00:00
opw-2278829
closes#54056closesodoo/odoo#54345
Note: maxDiff added for test to work in 13.0
X-original-commit: af5d03de28fa300ebbaa37a3d226b41051ebdf0f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Search the xsd files from in the database.
To enable this option, the Environment should be passed to the optional
`env` parameter. Both the XSD root and the XSD imported by the root and
the recusrively imported files will be searched in the database.
X-original-commit: 06a35f2e11230db81b8c21696d228097b31cf649
The linter would miss / fail to warn on injection of *local variables*
in some cases.
Try to improve it to be stricter and more reliable, after discussion
with odo, sql which is "correctly" dynamic should use psycopg2's sql
package in order to bypass the linter (bonus: it should also properly
escape & quote identifiers).
closesodoo/odoo#53938
Related: odoo/enterprise#11718
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
These field combinations [1] are actually secondary keys. They are
unique and represent the record identity.
Marking them as modified had a nasty side-effect: on some models, there
is a m2o to an ir.model and a stored related to ir.model/model that will
be recomputed at each model reflection. This can take some time on big
tables.
Moreover, some other stored fields may depend on those ir.model/model
related store, which adds useless time lost at recomputing unchanged
values.
[1] ir.model/model, ir.model.fields/{model,name} and
ir.model.selection/{field_id,name}
closesodoo/odoo#54126
X-original-commit: db013a01ca4e10640ac33a59466c9cb5746e3698
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Christophe Simonis <chs@odoo.com>
This intend to enforce specifications and improve readability
Layout changes:
* [FIX] Amount section must be placed under the QR code
* [FIX] Don't display empty additional information
* [FIX] Rename slip sections and labels
* [IMP] Rework of the layout
Group content like adresse by removing line spacing
Reduce character size to follow Swiss Implementation Guidelines QR-bill v2.1
Reduce left margin to avoid overlap of spaced ISR reference on the Receipt
* [FIX] Missing street on Receipt
* [FIX] Add thousand separators
Official specs asks for:
- thousand separators as blank. (using a non breaking to avoid spliting the amount)
- decimal separators as a full stop
> If the amount isincluded in the Swiss QR Code, then it must be printed after the currency code. A blank (space) should be used as the thousands separator and a full stop «.»as the decimal separator. The amount must always include two decimal places (e.g. CHF 1 590.00).
QR-Code:
* [IMP] Align QR code upper and improve accuracy of size
Add an option on reportlab to print QR Code without surounding blank space
this is required to compute with accuracy the width of 46mm x 46mm defined
in the specs.
* [FIX] Street and street2 issues
Removes an extra space between street values when only one is given.
Test the right partner street, only the company street was checked.
QRR generation
* [FIX] make it possible to generate QRR
It must be possible to generate QRR without ISR subscription number.
Content removed as not present in the specs version 2.1:
* [RM] procedure section
* [RM] due date
Translations:
* [IMP] Add translations of the QR-bill in DE, FR and IT
* [FIX] QR-bill lang is now based on customer lang
Tests:
* [IMP] Add unit tests for Swiss reality check for the QR-bill
closesodoo/odoo#54053
X-original-commit: 4f4edd0594b29252a5d44281cc773230c09521e9
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before this commit, when the same field occurred multiple times in
a form view, all occurrences were associated with the same id, and
all occurrences of the corresponding label (if any) had the same
'for' attribute. As a consequence, besides the fact that there were
warnings in the chrome console, clicking on any occurrence of the
duplicated label focuses the first occurrence of the field.
This commit generates a unique id for each pair label/field, when
possible. However, there is a case that can't be handled
automatically: when the label isn't automatically generated (field
located outside a group, or with nolabel attribute set to "1").
Typically, in this case, there is a <label> node with "for"
attribute referencing the associated field. In this situation, the
id must be defined in the arch, and used in the "for" attribute:
<form>
<label for="phone"/><field name="phone"/>
<label for="phone_2"/><field name="phone" id="phone_2"/>
</form>
Task 2261697
The logs should all be in the same language, s.t. one does not need to
understand multiple languages when browsing/reading the server logs.
closesodoo/odoo#53984
Related: odoo/enterprise#11615
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* Use of new _ signature (and placeholders)
* Ensure all error messages are translated
* No translation for warning logs
* Improved/fixed validation messages
closesodoo/odoo#53804
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit fixes all issues detected by the new pylint
gettext-variable test.
It converts some calls to the new syntax
_("Foo %s", bar)
to progressively migrate the code to the new syntax.
A few calls were not technically incorrect but still detected by the
linter.
_("Foo" +
"Bar")
has been converted to
_("Foo"
"Bar")
as it has the same effect and make sure the argument is of type
asteroid.Const instead of BinOp).
closesodoo/odoo#53683
Related: odoo/enterprise#11467
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
More often than it should, translations calls are made using
_("Foo %s" % bar)
instead of
_("Foo %s") % bar
or the even better (but more recent)
_("Foo %s", bar)
The issue of using the first writing is that the translation lookup
won't work at the execution (looking for ir.translation for src "Foo
Alice", "Foo Bob",... instead of "Foo %s").
Add a pylint test to ensure this won't happen anymore
* Improve layout of access error messages from group restriction
* Improve layout of access error messages from security records rules
* Use the error title in the js crash manager when possible
* adapt unit tests
closesodoo/odoo#50369
Taskid: 2206787
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Code's been dead since 3407fb70e4
essentially inlined its behaviour into the base class.
closesodoo/odoo#53774
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Well odoo/odoo#40872 is definitely the gift that keeps on giving,
after causing grief with the logging configuration change turns out
inlining the method was *also* a terrible idea because it's overridden
in `mail` in order to note merges on the destination partner, which I
apparently completely missed back then.
Task 2285876
closesodoo/odoo#53756
X-original-commit: 41209dababfaebca7bfd3be6ee5a2f41e9bb4ff5
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Was missing demo data and some modules
closesodoo/odoo#53666
X-original-commit: 957bad16b6df1ee712e0db218fe03285fbf5c420
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Performance fix: when parsing domains using special operators
(`child_of`, ...), or with dotted field on the left value
(`['partner_id.name', ...]`), the ORM starts by a first call on
`search()` and builds a new domain so the final query has "IN (<ids
found by sub-search>)".
The sub-search issued on the comodel uses the default "order by".
The order of the ids is irrelevant here, we only need to know the ids.
A good example is when the sub-search happens on `product.product`,
which is ordered by `default_code, name, id`. The field `name` is
inherited and translated, so the ordering requires a JOIN on
`product_template` and a LEFT JOIN on `ir_translation`. Ordering by `id`
avoids these 2 JOINs.
Some discussion took place about modifying `_generate_order_by()` to
remove the `ORDER BY` clause when the `order` argument is False or ''.
Apart the fact that it would be a breaking change, @odony has shown that
sorting by `id` is so cheap that removing the `ORDER BY` might not
bring significant performance boost [0].
[0] https://github.com/odoo/odoo/pull/52368#issuecomment-646643773
opw-2270690
closesodoo/odoo#53629
X-original-commit: fc91f7b4e8f9f8a95862df1ce95a9639cf7d1363
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Issue
The misc feature remove_accents(input_str) return a
string 'False' if the param is a boolean.
Solution
Return input_str if equal '' or False.
opw-2278959
closesodoo/odoo#53572
X-original-commit: 3fc7ce3b5599355933734e5e3f59d14a7a9b199c
Related: odoo/enterprise#11391
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Revision 07631a5185
inverts the parent/children relationship of the module categories
`module_category_administration`
and
`module_category_administration_administration`,
by swaping the `parent_id`.
During an upgrade, e.g. from 12.0 to 13.0,
as the `parent_id` node has been removed from the category
`module_category_administration` in the data xml file,
the field `parent_id` of the category was left untouched,
therefore leaving the former parent,
creating a recursion between the two categories.
```sql
select id,name,parent_id from ir_module_category where name ilike 'administration';
id | name | parent_id
----+----------------+-----------
79 | Administration | 78
78 | Administration | 79
```
closesodoo/odoo#53568
X-original-commit: e4bc0a6c6b1181b7c723df415c75f6983ff91927
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
It's not super useful as we've re-enabled DeprecationWarnings though
logging, and it turns out to be a *very* expensive lint, as it more
than doubles the runtime of pylint locally:
Before:
odoo.addons.test_lint.tests.test_pylint ran 1 tests in 376.27s, 2 queries
after:
odoo.addons.test_lint.tests.test_pylint ran 1 tests in 114.05s, 2 queries
It also seems to significantly increase peak memory consumption (by
~60% though that's not a precise measurement), which can lead to
non-deterministic memory errors.
Also disable mixed-indentation since it doesn't do anything (mixed
indentation is illegal in Python 3).
closesodoo/odoo#53562
X-original-commit: 8062098d0586048a9e91543290c6ab1c8d8d7009
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This ensures that flushing a one2many field automatically flushes its
inverse many2one/integer field. Without that, a search like:
model.search([('o2m_ids', 'in', ids)])
can return incorrect results.
closesodoo/odoo#53514
X-original-commit: b91b485a5d9a62acfe44b12c64a46dcca23981ce
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Steps to reproduce the bug:
- Let's consider a new instance with default installed language 'en_US'
- Install CRM
- Activate a second language (e.g. en_GB)
- Set that language in all users
- Inactivate default language 'en_US'
- Reset the language of your current user (no value)
- Go to contact and try to create a new one
Bug:
A traceback was raised because the lang en_US did not exist.
PS: Forcing the user to set a language ensures that this fallback
will never occur anymore.
opw:2267711
closesodoo/odoo#53375
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
We want to create a XMLID for every first exhibition of a field in a
model. That is, we just want one XMLID by field by model and not one
XMLID by field by class. Previous implementation was determining the
"first field exhibition" by making sure the field was created and used
as part of the same module.
This assumption is invalid when we consider mixins. A mixin is an
abstract model that define fields and methods to be included in other
models. As it is abstract, it does not exhibits the field by itself. The
field will only be exhibited when included in a concrete model via
inheritance. When it is included in another module, the XMLID creation
is discarded.
Take a module M1 that defines a model A, take another module M2 that
defines a mixin X with a field X1. In a third module M3, extend A to
inherit from X. While M3.A is the first model module to exhibit the
field X1, the XMLID creation was discarded because `"M2" != "M3"`.
See https://github.com/odoo/odoo/issues/49354#issuecomment-614093767
Task: 2235368
Closes#49354closesodoo/odoo#53435
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This commit sets attribute sample="1" in a bunch of list and
kanban views, to enable the new sample data feature when views are
empty.
Task 2232801
X-original-commit: 5471309b35619f307242c2704c7681ba63d2be42
* code *must* have an eval_context, `None` would blow up as soon as it
looks for the `'action'` key
* [accidentally quadratic] eval_value returns a value per line, seems
silly to evaluate all lines for each line when we can evaluate all of
them once, then map results to field names
* eval_value doesn't break inside the loop, so every id gets a value
by construction, `dict.fromkeys` is completely unnecessary (and
provides no performance benefits)
closesodoo/odoo#53110
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Taking a self and a separate action seems unnecessary given self *is
an action*.
Only do this change for the "new" naming scheme, so the old one keeps
working as-is.
There is no reason to call these directly, in fact it's not really
possible to do so as they expect an `action` object as first
parameter.
* warn against the presence of rpc-public runners
* move runner selection outside of ``run``
* improve doc a bit maybe
`state` was special cased in `copy_data` such that it would always be
reset to its default value if it had one.
While this special case can be useful (maybe) and is certainly
ingrained in odoo, having it not be overridable can be
problematic. Move the special case to the fields, so it's possible to
explicitly mark state fields as copy.
closesodoo/odoo#53113
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The attribute has been lost during a previous commit e6695c72d8.
This commit avoid that you can create an ir.ui.view without arch.
Before this commit, if you try to create an ir.ui.view with type but no
arch, the code will raise an exception in _check_xml:
/odoo/addons/base/models/ir_ui_view.py, line 377, in _check_xml
view_arch = etree.fromstring(view.arch.encode('utf-8'))
AttributeError: 'bool' object has no attribute 'encode'
Now, the user will have a warning on create, to say that View Arch field is required.
Could be backported if reported
X-original-commit: 4877bb4b650f5d1c52fefb06dec2fa568afcb121
On ir.property model, do get the field_id using the cached result from
ir.model.fields _get() method instead of issuing a direct SQL query
OPW-2067461
closesodoo/odoo#53351
X-original-commit: 24fff41d02fc7469d563f732a607db5c9a150e1e
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Wrong usage of self in for loops makes some apparently multi-friendly
methods not work correctly when called with a recordset of len > 1.
This commit replaces those references by the correct unique record
reference which should be used at this iteration of the loop, avoiding
potential exceptions or wrong behavior in the concerned methods.
closesodoo/odoo#53320
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Purpose of this commit is move 'Helpdesk' under the 'Services'
section on res.users form view instead of 'others'.
closesodoo/odoo#52043
Taskid: 2253481
Related: https://github.com/odoo/enterprise/pull/10821
Related: odoo/upgrade#1351
Related: odoo/enterprise#10821
Closes: #52043
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In the PDF, `DictionaryObject` can be wrapped in `IndirectObject`. For nested
dictionaries, using `get` on a `DictionaryObject` will unwrap the result if it's
an `IndirectObject`, but not `__getitem__` so when trying to futher call `get`
on the result will cause an error: we need to unwrap the object first.
Instead, we patch `DictionaryObject.get()` for it to unwrap the object in case
it's an `IndirectObject`.
This is a follow-up commit of fece5ab1bf2fef043b131f1bd0886f0841116103
closesodoo/odoo#53269
X-original-commit: 189a0b28ec7fdb7472f936450cfd7b4bfd6912ed
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
Until version 13.0, ir.ui.view:postprocess_and_fields returned a tuple
of a string and a dict of field information.
With aae1d57829, it now returns a
defaultdict instead of the dict.
This dict comes from NameManager.available_fields, which is initialized
as a defaultdict. There is no apparent reason to have a defaultdict in
this place, apart from the usage in has_field.
Furthermore, using a defaultdict has a side-effect in the search_view
computed field of all the ir.actions.act_window. On a database, if you
access env.ref('base.paper_format_action').search_view it will contain
a stringified dict, and the string default_dict(<class 'dict'>, {...})
is used in place of just {...} under the fields key.
closesodoo/odoo#53235
X-original-commit: 4586d0fbf0bdd5959b274611c58df911e50f4ef2
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Paul Morelle <madprog@users.noreply.github.com>
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
Mimic the syntax of logging to use placeholders in translatable
message.
The main advantage is to be able to fallback on the source term if the
translation can not be formatted properly.
It is very common to have errors in translations with missing
placeholders or badly translated (ie. the source
"%(subject)s" -> "%(sujet)s").
Instead of blocking the execution of the code, fallback on source
string.
Task-id: 1853119
Since a recent commit[1], we have a utility method in tools named
'is_html_empty' that checks whether the given html content is
void(containing only formatting tags) or not. However, the re from
this method does not consider the case of self closing tags, fox ex
`<br/>`. In such cases, the method returns Falsy value even if the
content is void.
This commit fixes the issue by considering self-closing void tags
in the regular expression.
commit[1] - https://github.com/odoo/odoo/commit/974f512f5f5d3b9f80a8c3fcde290e4f55cf1230
Task - 2267689
closesodoo/odoo#53167
X-original-commit: 0fd6c9388dc959a9b6b7828850683175edb05b9d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
ACLs on the wizard lines should match that of the wizard, otherwise
ERP managers can see the action but get an error as soon as they open
the wizard.
Since ERP managers have write access on arbitrary users, that's
probably the right group to use.
Task 2275134
closesodoo/odoo#53007
X-original-commit: 657d44f08c402bc0547b7cbb01c2d447e641d062
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
In the search panel, the domain used to compute the field image values
(when the attribute expand is false) was the same as the domain used
to compute counters (if enabled). The idea was that a value bringing an
empty domain is totally useless and should not displayed.
That being true, it turns out that if one does not allow them and
several fields are used, selecting a value in the search panel will very
often totally transform the search panel. From a UI perspective,
this turns out to be bad: the search panel 'moves'.
Let us give an example:
Let us start from a search panel that looks like to:
first_field
A 1
B 3
second_field
C 1
D 2 <--- mouse above D
E 1
with first_field and second_field both with expand="0" and
enable_counters="1". Let us also assume that no record in the global
domain has both first_field=A and second_field=D.
Click on D would make the search panel look like to something like
first_field
B 1
second_field
C 1
D 2
E 1 <--- mouse here
(the selection of D does not impact the values for the second_field but
does for the other first_field values).
This has led us to use basically only the domain comming from
outside of the search panel to compute field image values.
This means that we might now have value with zero count even if expand
is false. In the above situation, a click on D would give us
first_field
A
B 1
second_field
C 1
D 2 <--- mouse still above D
E 1
Task ID: 2154749
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
This commit introduces a new attribute 'limit' for search panel fields
that allows to avoid performance issues. That integer attribute (with
default 200) allows to fix a maximal number of values to display for the
fields. When the number of field values to display reaches the limit,
no values will be displayed. Instead, a warning message will be shown
in the corresponding search panel section.
Note it is possible to have no limit using limit="0" on a field.
This commit reintroduces in a better way the principle brought by the
fix 8d57153b34c04952a85f6642951cb2697016da84.
Task ID: 2154749
The commit introduces two new attributes for search panel fields:
- hierarchize: boolean attribute (default True) available for
many2one fields with select="one". It allows to choose whether
to hierarchize the field values using the _parent_name (if set)
on the field comodel.
Note that a sanitization of the parent hierarchy takes place.
Basically, it ensures that parent chains are
completely in the domain (on comodel) accessible by the user.
See _search_panel_sanitized_parent_hierarchy documentation for
more information.
- expand: boolean attribute (default False) available for many2one
and many2many fields. If set to true, all field values are fetched
and displayed in the search panel. If set to false, only the
values that have at least one corresponding value in the field
model (and in some domain) are fetched.
An exception in the case of an hierarchized field
(hierarchize=True and _parent_name set): more/less values can be
displayed in order to have a good representation of the parent
hierarchy. That means we complete and sanitize the set of initial
field image values.
Note that the fix 8d57153b34c04952a85f6642951cb2697016da84 bringing the
notion of limit in search panel has been reverted in the present commit.
An upcomming commit will reintroduce the limit principle in a better way.
Task ID: 2154749
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Task 2274998
1/ In the accounting dashboard, maximum one primary button per box
2/ In all boxes : "Sample data" must be removed. (Too obvious)
3/ In the configuration of Accounting Periods
* Opening date and fiscal year end must be on a same line.
* Remove the button "Configure your tax accounts".
4/ "Configure your tax accounts" is still available in the settings.
* But also make it available while doing the Tax Report Entry, if an
error message pops up.
5/ Chart of Account (list view)
* Captital D for opening Debit/Credit
* Rename "Name" into "Account Name"
6/ While génerating an Invoice
* Rename "Post" button into "Confirm"
* Check that the incremental number is added as a suffix of the name
of the bill ; not as a prefix
7/ Vendor Bill (list view)
* Status must appear as a Tag ; like it is already done in "Payment
State"
* Rename "Payment State" into "Payment Status"
8/ Bank journals
* On the bank journal level, if bank feed is set to synchronization,
then while selecting that journal from the accounting dashboard, then
directly go to the statement lines rather than the bank statement
itself.
* In the bank statement's account moves, remove the button duplicate.
It is enough to have it in the actions.
closesodoo/odoo#52818
Related: odoo/enterprise#11081
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The following situation can occur: a computed field depends on one2many
lines, and during an onchange, a line is modified. Both the main record
and the line are new records. If the many2one field is not in cache on
the line, its value is fetched from the line's origin, and the field
will be triggered for recomputation on the main record's origin instead
of the record itself.
The fix enforces the following property: if new records are modified,
only new records can be triggered for recomputation.
X-original-commit: f038b6c40b7045b6fe569c009d29ea092b614ed6
Add an autocomplete for opportunity name. If no name is set when a customer is
selected set the name partner_id.name's Opportunity
Change help title and subtitle to be more explicit. Change title from "Create
an opportunity in your pipeline" to "Create opportunities to keep an eye on
all your ongoing sales talks." Concerning subtitle, if a valid
and active email alias is found : Emails sent to ALIAS@address automatically
create opportunities.
Improve crm onboarding tour text messages and display.
Change menuitem from Teams to Team Pipelines to be more explicit. Update
the corresponding act_window name in the sales_team module.
Make the "schedule an activity" button bigger (100% of the div) and highlight
the entire Schedule button box.
Update test tours accordingly. Since quick create opportunity form is updated
the tests were failing. Reason is a trigger on input:first trying to detect
the field "name". This is not the case after this commit's changes.
Task ID 2226563
Community PR #51587
Nicolas Lempereur