This commit fixes the ribbons used in `kanban` and `form` views.
The SCSS uses the square root of the parent `div.ribbon` to calculate its
diagonal width and applies that width to the child `span`.
After changing the ribbon's transform-origin, we calculate the ribbon's
position based on CSS variables of the view's top padding,the height of
the ribbon and the shadow's size (to avoid it being cropped by
overflow-hidden).
By changing the values of a few of these variables in the kanban view,
we were able to remove all the specific SCSS related to ribbons in the
modules.
Other changes were applied inside some of the modules to make this
work:
- `event`: padding corrections on the kanban's cards;
- `hr_holidays: replaced `margin:0` in the SCSS with negative margin
utility classes on the element to achieve the same visual result;
- `discuss`: moved the ribbon to the parent element;
- this was also done to `discuss`, `survey` and `helpdesk`;
- `crm_team_view` in `sales_team`: the ribbon's height made it overflow
from the kanban's card. We fixed this by changing the value of one of
the CSS variables in the view's SCSS file;
- the same thing was done in `survey` and `appointment`;
- `website_event_exhibitor` had some SCSS that wasn't being used because
it uses `.o_ribbon` instead of `.ribbon`
task-2818586
Part-of: odoo/odoo#116641
*: onboarding, account, account_payment, sale.
Currently used in the appointment module (See c1cf8bfb).
Related Task-3297572
task-2818586
Part-of: odoo/odoo#116641
This just sets a dummy VAT number for all the demo partners
We need to access the demo partners vat number in
l10n_es_edi_facturae, and overriding data in the
other module could lead to different behaviours in
the future
Task: task-2793440
Part-of: odoo/odoo#108350
*: base, web_editor
The Many2oneUserValueWidget does not allow the user to reset it
to blank if it already contains a selection. This commit makes it
possible to select an empty value by specifying a `null_text` option.
task-2406626
Part-of: odoo/odoo#67913
In https://github.com/odoo/odoo/commit/6371565e6933d6ede88fa85992f4acbc2cb5327b we expect required fields to throw ValidationError when not set,
we thus correct res_partner to raise that error when the email is implicitly
required, so after this commit if we can try to create a new partner from the
name directly then It will give a validation error and wizard will open for the
creation of a new partner.
Task-3297388
closesodoo/odoo#121127
X-original-commit: 98aca8f76f7509b143263100384a2f2ed644124b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The assets bundle system allows to generate `<script>` elements whose
resource is meant to be lazy loaded. In that case, a "data-src" is used
instead of "src" directly as attribute. This is valid HTML code: "src"
is not required. However... this lazy loading system also automatically
added `defer="defer"` which makes the "src" attribute required, thus
failing W3C validation.
Now, we only add "data-src" and the `defer="defer"` part is added on the
client-side, once the "data-src" is switched to "src". Note that this
"defer" attribute may not be needed in this case at all, but it cannot
hurt.
Part-of: odoo/odoo#120311
Since 16.0's 0501bbd62e fields with groups are now removed from the view
instead of being set as invisible.
Scenario:
- template user has group "Access to export feature"
- create a new user while being in debug=0 mode
- save
=> the users don't have the group "Access to export feature" set,
because the corresponding field is not in the view. If the same scenario
was done in debug=1 mode, we would get the group set.
Solution: duplicate the field that are inside base.group_no_one section
and have them be invisible if someone is not in debug mode.
note: before the fix, added assert fails because there is missing groups
in the newly created user.
closesodoo/odoo#121097
Note: issue observed when working on another ticket
X-original-commit: 9deb1e6aa902a09c4fd6a91ecbd34a89b9c98f98
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This commit introduces a "_is_portal" method complementary to the existing
"_is_internal" and "_is_public".
The goal is to ease usage through the code base and be able to easily
distinguish our 3 main use cases: public, portal and internal users.
Task-3056280
closesodoo/odoo#120827
Related: odoo/enterprise#38575
Related: odoo/upgrade#4575
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When generating the routing map, `Rule.add` will call
`Rule._compile_builder` twice, representing almost one third of the
routing map generation time. `_compile_builder` is actually stored
in `Rule._build` and `Rule._build_unknown` for latter use, in the
`Rule.build` method.
The `Rule.build` method is used to transform a rule, lets say
`/forum/<model("forum.forum"):forum>` in `/forum/basics-of-gardening-2`
Even if a deeper investigation could be interresting, it looks like it
is only used for `is_frontend_multilang` routes and `_enumerate_pages`,
used in the `sitemap` and `search_pages`.
The proposed solution si to make this part lazy, in order to call
_compile_builder on demand, once per rule. This will speedup the initial
routing map generation and postpone the heavy work when we need it,
only for the part we need most of the time.
On a database with all modules installed, generation of the routing map:
Before: ~600 ms
After: ~200 ms
An alternative implementation was also overriding the Rule.build method
instead of having a callable LazyCompiledBuilder, this implementation
was choosen since it is less dependant off the werkzeug implementation.
closesodoo/odoo#120542
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Before this commit: if you add a custom one2many field to the
'res.partner', like x_related_commercial_partner_ids, that is related to the
`commercial_partner_id` in the`res.partner` model, it won't update the
display name of a contact in case of changing its parent_id name.
Here are the steps to reproduce the problem:
1. Create a new custom field with these values:
a. Field Type = one2many
b. Model = Contact
c. Related Model = res.partner
d. Relation Field = commercial_partner_id
2. Create a new Contact that is the "Company" (e.g. "My Company")
3. Create a new Contact that is the "Individual" (e.g. "My Name"), and
put the "My Company" as its parent_id.
4. Now the display_name is "My Company, My Name" which is correct
5. Change the company name to "My new Company"
-> display_name won't change, and is "My Company, My Name"
The solution is to add the 'commercial_company_name' to the
`display_name` depends.
opw-3202894
closesodoo/odoo#120908
X-original-commit: f242cad9a27fb0e58e1b9c726573b316534f6be8
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
If applied, this commit will handle the KeyError: res_id when the user tries to
import the translation of .csv file in settings -> translations, and if .csv
file doesn't have the res_id column.
I handled the traceback by changing the logger level to warning.
sentry - 4049419481
closesodoo/odoo#120904
X-original-commit: f5b69559a04cad9a693b991497936cf11ca36aeb
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Renilkumar Kajavadra (reka) <reka@odoo.com>
Before this commit an ir_assets generated automaticaly by the web editor
will generate an url ending with ...custom.addon.bundle_name.ext
After this commit the url will start with /_custom/addon.bundle_name/...
This will make it easier to spot at immediately if it is a custom asset
and thus it is useless to apply the glob. Actually, it will fail on the
/_custom when trying to glob, making it faster.
This is mainly useful to clarify and debug but in a case with mainly
customised ir_asset for one bundle, it may have an impact on speed.
An upgrade script was created for this change.
closesodoo/odoo#120699
Related: odoo/upgrade#4636
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
before this commit:
after #109858
The method `update_field_translations` won't directly call the `write`
As a result, when changing the translation of fields from translation dialog,
the orm cache won't be cleared, and translations won't be updated in views
even after refresh the page
after this commit:
when users translate fields and refresh the page, the new translation can be
updated in new views
opw-3267024
closesodoo/odoo#120602
X-original-commit: 8d8dbab203fe7c153522dcb2a420d97dc4adaadb
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
This test will help making stats on routing_map generation performances
This will help to mesure the time for the main `None` routing map as
well as for website1, the idea being that it would be possible to
mutualize a part of this computation between routing maps.
closesodoo/odoo#120591
X-original-commit: 6646fa7e2ef64e5f060bf38b0d85bf1188d79e4f
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit fix the users login disappearance when
hitting 'Change Password' button without setting a
password by adding force_save parameter. It also
removes the required parameter from the new_passwd
field so we don't get a vague missing field error
when one omits to enter a new password. Instead of
an error, we just leave the old password for the
missing lines.
Task-3184727
Part-of: odoo/odoo#112806
This reverts commit 14d97ec2
We revert this to keep the same design when changing password for
one or multiple users.
Task-3184727
Part-of: odoo/odoo#112806
This commit makes the `dependencies` param of
`odoo.define` mandatory. It was optional and when
omitted, a regexp read the function to find the
dependencies. We can simplify it now almost all js
modules have been converted to esm.
The transpiler already adds the param for the es
modules except if the module has an alias.
task id: 3271352
closesodoo/odoo#119145
Related: odoo/enterprise#40040
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Before this commit if a computed field is already in cache, but not its
dependencies, `fetch` would fetch those dependencies.
This commit ensures that fetch checks first if a computed is in cache
before fetching its dependencies.
This commit also follows dependencies of computed fields, if they depend
on other computed fields.
Finally, this commit consolidates `fetch` and `search_fetch`:
they should use the same heuristics to know which fields to fetch.
closesodoo/odoo#120001
X-original-commit: 6b680c463956f929db10d4c3058c36112a67e674
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: rco-odoo <rco@odoo.com>
The purpose of onchange2() is to adress two shortcomings of onchange():
- reduce the payload of the RPC call by minimizing the diff
- use the "unity" format for returning the data
Because of the dependency of onchange2() on web_read(), the new method
has been introduced in module web.
closesodoo/odoo#119510
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Julien Castiaux <juc@odoo.com>
Co-authored-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
This commit allow to add in t-options the decimal_places.
It is useful in case all price are without decimal e.g.
closesodoo/odoo#120036
X-original-commit: 800d18f2e9f94c68ebca281c9956abb23e7e33e6
Signed-off-by: Thibault Francois <tfr@odoo.com>
Signed-off-by: Jérémy Kersten <jke@odoo.com>
THere is now group filter predefined for Actions list
and for Window Actions list.
TaskId : 3255936
closesodoo/odoo#119953
Signed-off-by: Géry Debongnie <ged@odoo.com>
*: web + adaptations in base, fleet, hr, hr_expense, hr_recruitment,
loyalty, lunch, mail, mass_mailing, note, project, stock, survey,
web_tour
**Foreword**
Since d19037e141 the rootnode class attribute for form/list views was
copied two times:
- on the o_view_controller div
- and on the root node of the view renderer.
Examples:
<form class="foo">...</form>
gives
<div class="o_view_controller o_form_view foo">
<div class="o_control_panel">...</div>
<div class="o_content">
<div class="foo o_form_editable ...">...</div>
</div>
</div>
and
<list class="foo">...</list>
gives
<div class="o_view_controller o_list_view foo">
<div class="o_control_panel">...</div>
<div class="o_content">
<div class="o_list_renderer foo ...">...</div>
</div>
</div>
**Issue**
This could lead to confusion and also unexpected styling issues.
See this PR #119815 to read a message JS Framework team has received.
See also another a fix that had to be made for x2m fields: 980244fa8
**Introduced Changes**
- in the form compiler, the root node attributes are no more copied to
the root div node of the compiled template the form renderer receives
- the root div node generated by the form compiler now has the
"o_form_renderer" class, which was removed during the recent form view
refactoring.
- the list renderer no more adds the root node class attribute to its
"o_list_renderer" div
- the X2ManyFieldDialog has been adapted too
- since View, X2ManyField & X2ManyFieldDialog both need to compute view
classnames derivated from the arch root node, an util has been
introduced to avoid duplicating code
- the whole codebase has been checked and adapted.
Related: odoo/enterprise#40418
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
As ir_cron_trigger are only processed for active crons, we should
not create them for inactive crons to avoid bloating the table.
Account_edi tests needed to be adapted to make sure the cron
ir_cron_edi_network is set up as active during the tests.
Backport e79b1a7: ([IMP] base: Garbage collect ir.cron.triggers)
closesodoo/odoo#118844
X-original-commit: a62275430e21f9e7e510913ac9afb25943da525b
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Co-authored-by: Julien Castiaux <juc@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
This commit add a new `odoo.osv.expression.prettify_domain` function
that can be used to format a domain as a string with the correct
indentation.
Example:
['&', '|', ('name', 'like', 'Jack'), ('name', 'like', "O'Neill"),
('function', '=', 'Colonel')]
Becomes:
['&',
'|',
('name', 'like', 'Jack'),
('name', 'like', "O'Neill"),
('function', '=', 'Colonel')]
closesodoo/odoo#118067
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Rationale
---------
Given the following domain:
['|',
('company_id.name', 'like', 'BE'),
('company_id.city', 'like', 'Brussels')]
The ORM would generate the following SQL query:
SELECT "res_partner"."id"
FROM "res_partner"
WHERE "res_partner"."company_id" IN (
SELECT "res_company"."id"
FROM "res_company"
WHERE "res_company"."name" like 'BE'
) OR "res_partner"."company_id" IN (
SELECT "res_company"."id"
FROM "res_company"
WHERE "res_company"."email" like 'help@odoo.com'
);
Which is sub-optiomal as the WHERE clause of the two subqueries could be
regrouped inside of a single query like so:
SELECT "res_partner"."id"
FROM "res_partner"
WHERE "res_partner"."company_id" IN (
SELECT "res_company"."id"
FROM "res_company" WHERE (
"res_company"."name" like 'BE'
OR "res_company"."email" like 'help@odoo.com'
)
);
Postgres-wise, it is faster to execute the latter query than the former
one. This commit is about optimizing the ORM so that it generates
queries where the WHERE clause of compatible subqueries are grouped
together.
Technical solution
------------------
The solution explored by this work is to replace the regular relational
field accesses (over a dotted path) by a new `any` operator that look as
follow:
(relational_field, 'any', domain)
For instance, the above `('company_id.name', 'like', 'BE')` leaf becomes
`('company_id', 'any', [('name', 'like', 'BE')]` using `any`.
Having a domain as right-hand-side allow for the combination of the
domains of same compatible relations:
[('company_id', 'any', ['|',
('name', 'like', 'BE'),
('city', 'like', 'Brussels')])
Having combined domains allows for generating better SQL queries with
minimal changes to the expression parsing algorithm, which can only
translate a single leaf at a time to SQL. With the new `any` operator,
it is still a single leaf but the right-hand-side contains the merged
domain, thus the combined SQL WHERE clause is immediately generated.
task-id-3234671
Part-of: odoo/odoo#118067
Co-authored-by: Raphaël Collet <rco@odoo.com>
This commit hads a few tests that report the existing behavior (before
merging subqueries WHERE clauses).
task-id-3234671
Part-of: odoo/odoo#118067
Co-authored-by: Raphaël Collet <rco@odoo.com>
a new context `prefetch_langs=True` allows ORM to prefetch all translations of
translated fields while fetching.
For example
The activated languages are 'fr_FR' and 'nl_NL'
In the database the value is '{"en_US": "English", "fr_FR": "French"}'::jsonb
after fetch with `prefetch_langs=True` the raw cache value will become
{'en_US': 'English', 'fr_FR': 'French', 'nl_NL': 'English'}
closesodoo/odoo#116947
Signed-off-by: Raphael Collet <rco@odoo.com>
Enforce strict types for returned values for
* create
* write
* unlink
* default_get
to make those methods more consistent and reliable.
Also make sure they can be called with empty self/values,
i.e. that they follow the same behavior as the base methods
defined in the main orm Model.
closesodoo/odoo#116809
Related: odoo/enterprise#38880
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit adds two autoresize hooks for text inputs and textareas to
make it adapt their size (width for text inputs, height for textareas)
depending on their content.
The commit therefore solves the issue of several form view task titles
being restricted to 1 line while it can be annoying if the title is too
long. The autoresizeTextarea feature was moved from TextField to the
autoresizeTextarea hook and the autoresizeInput feature was moved from
the AutoresizeInput mail component to the autoresizeInput hook.
The TextField component has a new option for disabling linebreaks.
task-3138826
closesodoo/odoo#117355
Related: odoo/enterprise#39493
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit:
The AceField component used the ace library to provide the user a code
editing field
After this commit:
The AceField component is now using the CodeEditor component and the usage
of the ace editor lib is now abstracted behind the component.
closesodoo/odoo#117782
Related: odoo/enterprise#39365
Signed-off-by: Géry Debongnie <ged@odoo.com>
__Current behavior before PR:__
The size of an image field is guessed using the field name. For instance, an image field with `field_name = "XXXX_123"` is resized to 123 pixels when fetched.
This is can be an issue if a user creates an image field using studio in a form view.
If the user sets the label of the field as "Image 1", the technical name will become `x_studio_image_1`. Therefore, the image field will be resized to 1 pixel width.
__Description of the fix:__
Refactor the `image_guess_size_from_field_name` method to return `(0, 0)` when the field name starts with `x_studio_`.
__Steps to reproduce the issue:__
1. Open a form view (of any model)
2. Open studio
3. Add an image field with label "Image 1" (notice the technical name becomes in `x_studio_image_1` in debug mode)
4. Close studio
5. Upload an image on the created field
6. Save... The image is resized to 1 pixel width
opw-3242084
opw-3249632
opw-3253133
closesodoo/odoo#118960
X-original-commit: 3318f0e67da40983f52595aba933d8c8fd0f5cc5
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Many templates use the company logo that is set by default on
database creation. As that logo is clearly a placeholder and the user
isn't necesserely prompted to update it. It's possible for a user to
inadvertently start sending emails with "your logo" placeholders
plastered all over.
This removes the default logo of the company and removes it from
templates conditionally.
The logo isn't simply replaced with a transparent PNG as the templates
set a fixed height for the logo, which would look weird.
task-3067315
Part-of: odoo/odoo#106307
* = bus, calendar, crm_livechat, hr, hr_holidays, im_livechat, mail_bot,
mass_mailing, privacy_lookup, test_discuss_full, test_mail,
test_mail_full, website_crm_livechat, website_livechat, base
In preparation of splitting discuss and mail modules.
Part of task-3265211
closesodoo/odoo#118354
Related: odoo/upgrade#4553
Related: odoo/enterprise#39661
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
before this commit:
record = env['model.name'].browse(id)
if record doesn't exist in the database and call
record.translated_field_name = value
Then _get_stored_translation will raise
TypeError: 'NoneType' object is not subscriptable
after this commit:
like write non-translated field, the value can be written to the cache, but not
the database and no error will be raised.
Note: The feature is only for the original ORM 'write', if the 'overriden write'
reads other fields of the non-existing record, a MissingError will be raised.
closesodoo/odoo#119202
X-original-commit: 3ba7ca28a68acccb8eb25f117900c1aa1980264a
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
odoo/odoo#111651 improved and optimised triggers but dropped the
in-place cleanup of field dependencies. As a consequence, during
module uninstallation if a stored computed field is removed (because
it's part of a module being uninstalled), and one of its dependencies
is subsequently altered (e.g. it's itself removed, or written to) the
second update will break as the query trying to find out which
dependent records to update will error, either because of trying to
select / filter on a missing column, or because of trying to fetch
in a missing table.
The simplest examples of this issue are computed fields with a
dependency on `ir.model`:
- In `calendar`, `calendar.event.res_model` is a related on
`res_model_id.model`, this prevents the removal of *any* `ir.model`
record if it gets uninstalled.
As a result the `calendar.attendee` and `calendar.event` tables
don't get removed (just emptied of all their non-automatic fields),
their records remain as well, and when the non-automatic fields get
re-added during installation re-instating the NOT NULL constraints
fails, breaking the uninstall/reinstall test.
- In `payment`, `payment.provider.module_state` is a related on
`module_id.state`, this breaks *during* uninstallation, as after
`module_uninstall` first calls `_module_data_uninstall` which
removes the field, then it *updates the modules being uninstalled*
(sets their state), which tries to find out which
`payment.provider`'s `module_state` is should update, which breaks
because the `module_id` column has been removed.
This second one was worked around in odoo/odoo#118900, by marking
modules as uninstalled before actually gutting them, but as it turns
out the "actual" fix is needed anyway. So revert the workaround, and
actually fix the issue.
closesodoo/odoo#119130
X-original-commit: 48a420efcf7c7b46416bab006003553cc9d23846
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Lot of override of read_group reimplement partially custom security
rule of `_search` method. In order to simplify these security check
and have a consistent behavior between the search and read_group method,
_read_group now use _search to create the from and where clause.
Part-of: odoo/odoo#110737
The `_read_group` was designed to be used by the web client to
efficiently compute aggregations grouped by one or more fields.
However, more and more developers have been using it from the backend
to make computations more efficient (avoid doing the aggregation
in Python). Unfortunately, the API was designed for the web client,
which added a lot of boilerplate when used in the Python (list of
dict with misleading key name choices).
`_read_group` was created to improve the performance of read_group
for backend use (4ef0c00b4b), but didn't
change the API and based the implementation on read_group itself.
Rewrite `_read_group` from scratch with a new API to make it easier
to use from the backend (see the method documentation). Also, split
the method to make it easy to override and add custom behavior.
Part-of: odoo/odoo#110737
before this commit, on duplicating a contact tag
will duplicate the assigned partners also.
suppose if we have a partner A with tag B assigned,
and then we duplicate tag B and create new tag C,
the newly created tag is automatically getting
assigned to partner A.
after this commit, the copy is set to False for
partner_ids field in tag and then the partners
wont be copied on duplicating a tag
closesodoo/odoo#118974
X-original-commit: 5dc9104403606b6421b9cde732cfa3d6bb5962aa
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Before this, uninstalling the `payment` module (or any of its
dependencies) is broken: as payment.provider has a dependency on
ir.module.module.state, marking the modules causes a lookup of the
payment provides to update, but the table was removed by
`_module_data_uninstall`, so the lookup blows up.
This is a consequence of odoo/odoo#111651 which improved and optimised
triggers but dropped the in-place cleanup of the triggers tree.
Thus while the columns & tables get removed from the database the
in-memory structures (registry, models, fields, ..., as well as the
trigger and dependency caches) are not so the python side will happily
try to look up stuff which has been nuked if accessed at the wrong
moment (which is any moment between the start of
`_module_data_uninstall` and the creation of a new registry, really).
As `_module_data_uninstall` is nothing but a giant pile of dodgy state
anyway, making modules as uninstalled before it executes doesn't seem
like a huge deal. It may cause unnecessary extra recomputation for the
few models which depend on modules, but that doesn't seem like a major
issue, at worst it makes uninstallation a touch slower but they're not
a huge performance concern at the moment (they're more of a
correctness one).
closesodoo/odoo#118959
X-original-commit: 460efeb623ec62c980d187710bd4e7614af0e7bd
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Elisabeth Dickinson