This commit improves the helper message in team member action
task- 2583755
closesodoo/odoo#92616
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
TLDR:
* invoices are implemented using computed methods instead of onchange
* the synchronization only happens when switching tabs in the Form view
to improve perfs.
_______________________________________________________________________
The whole engine of the synchronization of Invoices to the Journal
Entries has been refactored
* by using computed fields instead of onchange functions
* by synchronizing only from invoice to journal entry in `create` and
`write`
* by saving when switching tabs on the Invoice form, to synchronize
before showing the values
This comes with numerous advantages:
* no need to call the onchange methods manually
* no need to use the Form emulator to build invoices (i.e. EDI, OCR,
intercompany, ...)
* the performance for invoices with many lines improves drastically, going
from 2 minutes to 4 seconds to create an invoice with 500 lines
* the model is more declarative, we can now see how the values are computed
instead of having the values being copied from various places.
* remove the hack in `onchange` that disabled the recursivity of it,
which was unexpected and needed to be managed manually in all the
onchange methods
This means that:
* Some fields need to be exclusively computed on journal entries values
or invoice values, more specifically the Tax Summary widget.
It is now
- computed from entry lines, when opening the view
- computed from invoice lines when changing those, because the tax lines
will need to be recomputed anyways, erasing previously set values
- set with an inverse function when saving; after the sync has been done
* Some possible operations previously possible have been dropped.
(i.e. look at the removed test test_in_invoice_line_onchange_accounting_fields_1)
This is because such a behavior was undefined (how is changing the balance going
to affect the unit price? How is the amount currency going to affect it?)
_______________________________________________________________________
Implementation Details
----------------------
The "dynamic lines", meaning the payment terms and the tax lines are now
only created in the `create` and `write` functions.
In order to reduce code duplication, it has been implemented using
context managers used in both `account.move` and `account.move.line`
These context managers help comparing the values before/after, acting
like a local `onchange`, but getting benefit from the dirty flags from
the `compute` dependences.
This is relying on computed fields on the move (`needed_terms`) and on
the lines (`compute_all_tax`) which contain the values needed for the
related move.
Depending on the needed values and the existing values (`term_key` and
`tax_key`, respectively) the context manager will determine what needs
to be created/updated/deleted.
Some related changes are to produce a `dict` instead of a `str` for the
`tax_totals` (previously `tax_totals_json`) fields, by simplicity to
reduce the complexity of IO, and simplicity of debugging, because the
logic of the field needed to change (cannot be computed at the same time
anymore since it needed the lines to be synced)
By simplicity, and also because it makes more sense, some boolean fields
have been merged into `display_type`:
* `is_rounding_line`
* `exclude_from_invoice_tab`
* `is_anglo_saxon_line`
The `price_unit`, `quantity` and other "invoice fields" are now not set
anymore on lines that are not product lines since it didn't make any
sense to have it.
Performances
------------
You have to keep in mind that a simple `create` didn't compute a lot of
fields, for instance not taxes were set, no payment terms,...
Now it does.
```python
import random
from timeit import timeit
from odoo import Command
domain = [('company_id', 'in', (False, self.env.company.id))]
products = self.env['product.product'].search(domain).ids
partners = self.env['res.partner'].search(domain).ids
taxes = self.env['account.tax'].search(domain).ids
def create(nmove, nline):
self.env['account.move'].create([
{
'move_type': 'out_invoice',
'partner_id': random.choice(partners),
'invoice_line_ids': [
Command.create({
'name': f'line{i}',
'product_id': random.choice(products),
'tax_ids': [Command.set([random.choice(taxes)])],
})
for i in range(nline)
]
}
for j in range(nmove)
])
# After | Before
print(timeit("create(1, 1)", globals=globals(), number=1)) # 0.11 | 0.09
print(timeit("create(100, 1)", globals=globals(), number=1)) # 2.76 | 2.50
print(timeit("create(500, 1)", globals=globals(), number=1)) # 14.56 | 12.34
print(timeit("create(1, 100)", globals=globals(), number=1)) # 1.03 | 5.52
print(timeit("create(1, 500)", globals=globals(), number=1)) # 3.99 | 125.02
print(timeit("create(50, 50)", globals=globals(), number=1)) # 19.44 | 79.55
```
Another metric that can be used is running the test suite with
`--test-tags=/account` (only `account` installed)
* before: 404s, 267127 queries (366 tests)
* after: 318s, 232125 queries (362 tests)
Why this commit title?
----------------------
Someone told me that this was the perfect way of naming your commits.
c04065abd8
task-2711317
closesodoo/odoo#96134
Related: odoo/upgrade#3715
Related: odoo/enterprise#29758
Signed-off-by: Laurent Smet <las@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Currently, two lost buttons will appear, if you go to the form view of a lead that has 100% probability. The difference between the two duplicated "Lost" buttons is that one ask for a "lost reason" before marking a lead/opportunity as lost, the other does not.
After discussing with the PO for CRM, it appears that the button that asks for a "lost reason" should not appear on a lead. This commit makes the necessary changes to reflect that behavior.
opw-2886623
closesodoo/odoo#96486
X-original-commit: 707bddefdc5604db3304afa3633a0b90027f78b4
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
The `fetchmail` module is build on top of the `mail` module and enables
the incoming email capabilities. However, using the `mail` without
incoming email server is not a good use case.
This commit merges the `fetchmail` moudule into `mail` and lessens the module
complexity, along with adapting the xml/external ids in the dependent modules.
task-2797458
closesodoo/odoo#94143
Related: odoo/upgrade#3615
Related: odoo/enterprise#28659
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, if you try to create an opportunity through the smart button on a contact form, a lead is created.
A lead created from a customer should be an opportunity.
opw-2886623
closesodoo/odoo#96268
X-original-commit: 415c8393f25ab47da45d15ebc455660bfa440389
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
With Calendar and CRM installed:
- Create a lead and a meeting related to that lead.
- Delete the lead.
- Go to the meeting form view from the calendar App.
- Click the Document action button and nothing will take place.
After this commit if you delete the lead, you will no longer be able to the
see the button as document information is correctly reset.
Task-2917174
Closesodoo/odoo#42450Closesodoo/odoo#47497closesodoo/odoo#96190
X-original-commit: 71ccb7dae43a13521f2a290ce76cafd8fb5b963f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The fake demo email used in our crm_lead demo data is an actual customer's email.
Steps:
* Install Demo Data
* Navigate to CRM and activate Leads.
* See Lead for "DeltaPC: 10 Computer Desks"
* Issue: Email being used is an active real company's email.
Updating to a more distinctive fake email so actual customers are not
accidentally used in our demo data.
opw-2746911
Task-2917174
Closesodoo/odoo#84225
X-original-commit: 3e11482db41d7633a1606d6a98537e23f369d1e4
Part-of: odoo/odoo#96190
Probability is not always given to write, hence date_closed is currently not
always reset. Indeed as it is a computed field it can be updated after stage
update, without being explicitly in values.
In this fix we consider that going out of won stage without any other hints
on probability is like being not won anymore, therefore resetting date closed.
Task-2917116
Closesodoo/odoo#93704Closesodoo/odoo#93704
X-original-commit: 1cf1b572b10bfbd02581c12f89824a028c4f23e6
Part-of: odoo/odoo#96190
Followup of odoo/odoo@6e46d4cd07 and odoo/odoo@1f81d60de6
Also fix a test failing with python 3.8. Message-ID is formatted using chevrons.
Task-2917174
X-original-commit: 26c88387f24b8515dc74c24594f203e3953b8a39
Part-of: odoo/odoo#96190
Onchange could also populate the lang field of the lead when updating the
customer.
Partial backport of odoo/odoo@65bb3a5710
Task-2917174
Closesodoo/odoo#78715
X-original-commit: e0e1e402a6c40ed89bc5a11671e364a67e93a176
Part-of: odoo/odoo#96190
With commit[1], we added `o_text_overflow` classes at several places to avoid
long names going out of the boxes. However, for the name/title fields in the
form views, we should always show the full name.
So this commit replaces `o_text_overflow` class with `text-break` from
name/title fields in the form views to display full string in the read
only mode, but also keep them from going outside of the form view.
Below are the modules affected:
- base
- coupon
- crm
- event
- mass_mailing
- mass_mailing_sms
- project
- sales_team
commit[1] - a0ebb46
task-2889845
closesodoo/odoo#96132
X-original-commit: 4a74c7af6b54bd771f50d3885813f4aae442c9e7
Related: odoo/enterprise#29552
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The field `company_currency` is indirectly used by portal users, and
does not seem to be a security concern in that context. But as portal
users cannot read companies, the field should be computed in superuser
mode. This apparently used to work by accident in the past...
closesodoo/odoo#95325
Signed-off-by: Raphael Collet <rco@odoo.com>
There was an issue with the computed `read_group` `__range` when grouping on
the same date/datetime field on multiple granularities (i.e. month, week).
Since the range was stored with the field_name as a key, the last evaluated
range would override the previous ones.
Impacted Versions:
- master
(- exists since 15.0 but it does not impact the user directly so it has been
decided to fix this only in master, since the API is modified)
Steps to reproduce:
1. Open a list view and group by a date field with at least 2 granularities
2. Open the chrome debugger (network) and check a web_read_group rpc preview
3. Find the web_read_group for groups related to one of the largest
granularities and check the `__range`
Current behavior:
- `__range = {field_name: false}`
Expected behavior:
- `__range = {field_name: {from: range_start, to: range_end}`
Explanation
Since the smaller granularities are evaluated last, and the condition to update
`__range` is related to the field_name and not the granularity, the range is
always overriden by the smaller granularities (even if their value is False)
when grouping on the same field with multiple granularities.
Furthermore, there is a conceptual problem with the current solution: it does
not allow to store multiple ranges when the read_group is not lazy and when
grouping on the same field with multiple granularities.
Therefore, the proposed solution is to use the full groupby keys in the
`__range` to allow storing multiple ranges depending on granularity. The keys
in `__range` would thus match the group value keys and allow more flexibility
if a domain must be forged from the group(s) range(s).
Task-2894519
closesodoo/odoo#95193
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit allows multiple salespersons to collaborate on a lead without
erasing each other's data.
closesodoo/odoo#95042
Taskid: 2900372
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
In the web client, in a real use case, it's not possible
to write on fields which are invisible,
as it's not possible to write on fields which are readonly.
This is a first step in the goal to change the behavior
of the `groups=` attribute in the back-end views,
to remove them for the view instead of making them invisible.
This is mainly to reduce the diff of the revision that will introduce
the mentioned above behavior change.
As nodes with `groups=` will be removed from the view
when the user doesn't have the group, it's no longer possible
to set a value on a field having a `groups=` the user doesn't have
in the `Form` test class, as the field will no longer be at all in the
view.
However, these unit tests shouldn't have been able to set values
on invisible fields in the first place.
This revision therefore aims to correct the unit tests setting value
on fields which were invisible because the user executing the
test was not part of the required group(s) for these fields
to be visible in the view.
closesodoo/odoo#94337
Related: odoo/enterprise#28936
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
The logic not identical in BS4 -> BS5
The color contrast system in BS5 relies on WCAG 2.0 contrast algo.
So color-yiq is converted to color-contrast.
Note that there are some "texts/buttons/other visuals" elements
which will not have the same contrast as before.
$yiq-text-dark and $yiq-text-light are respectively replaced with
$color-contrast-dark and $color-contrast-light.
Note that we had to use '$min-contrast-ratio: 2.2' for .o_tag_color_X badge.
Task ID: 2766483
Part-of: odoo/odoo#95450
Co-authored-by: Stefano Rigano <sri@odoo.com>
To reproduce
============
Have two companies with different currencies,
Create a lead in the first compnay => the expected revenue has the company's currency
Create a lead in the second company => the expected revenue doesn't have the currency
Purpose
=======
in v15 the `company_id` has became computed, but the compute method in some scenarios
doesn't set the `company_id`.
`company_currency` is related to `company_id`, so when `company_id` is not set `company_currency`
is also not set which occures this issue.
Specification
=============
To solve the issue, the field `company_currency` is computed now, and we give it the value of the active
company if `company_id` is not set.
opw-2862410
closesodoo/odoo#95484
X-original-commit: de59391caede72624fddcb01ba3565884c4e5574
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit removes the unnecessary measures(like partner latitude/longitude)
from the lead related graph views. Also, we try to order the measures and keep
time related measures(Days to Assign, Days to Close, Exceeded Closing Days, etc)
first and revenue related measures(Expected Revenues, Prorated Revenues, etc)
last.
Note that with this commit, recurring revenue related measures will be displayed
only when the feature is activated.
ent PR: https://github.com/odoo/enterprise/pull/21981
Task-2674367
closesodoo/odoo#79167
Related: odoo/enterprise#21981
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In module mail, invalidating 'message_ids' on a mail thread also
invalidates its inverse field 'res_id' on messages. If you haven't
flushed it before, your cache will be inconsistent, as shown by the test
/mail:TestMailgateway.test_message_process_bounce_records_channel.
In module purchase_stock, add depends on report.stock.quantity. This
ensures that when the model is queried after changes in other models,
the data on which the SQL view depends is flushed to the database before
querying that model's table.
closesodoo/odoo#66938
Related: odoo/enterprise#16722
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
This commit makes various adapations in addons with respect to
the introduction of the owl kanban view. Mainly, some selectors
in scss and in tests needed to be adapted. Moreover, in some tests
that we haven't adapted yet, we must ensure that legacy form and
list views are still used (useLegacyViews).
It also contains some adaptations in kanban templates, e.g. the
replacement of moment by luxon, the removal of underscore...
Part-of: odoo/odoo#92475
In base, when the group "group_partner_manager" is created, user_root &
user_admin are already specified as group users.
Therefore, it's useless to add them again in the data of the crm & sales
modules.
Part-of: odoo/odoo#94704
Use case
--------
A sale user convert a lead to an opportunity, this lead has duplicates.
The wizard will convert and merge the lead. At the end of the process
the duplicated lead are delete.
Issue
-----
Before this commit the user get an access error because he cannot delete
leads
Since they can merge lead using the action "Merge" it's not consistent
and sales user should be able to merge lead during the conversion
as well
closesodoo/odoo#94699
X-original-commit: 3b79867460d9a407fba094fe1cd719d8d52011ef
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Thibault Francois <tfr@odoo.com>
Purpose of this commit is to add a first populate implementation in CRM to
create leads. Indeed as CRM application may have to handle lots of leads we
should ease data creation to test performance in several use cases.
Task-2679887
closesodoo/odoo#79150
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit does below improvements:
1/ If salesperson and sales team are set on an individual partner, we propagate
those to parent company being created from m2o of the form view.
2/ If the existing parent company is manually linked to an individual partner
being created, and salesperson and sales team are not set on the individual,
we set those values from the linked parent (if set on the parent).
Task-2636290
closesodoo/odoo#78696
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In a multi-company environment, when we transform a lead (which has no
salesperson) into an opportunity, we get an error if the customer has
a company set.
To reproduce the issue
1) Create a new company
2) Create a Lead for a customer with the Company set
3) Remove the Sales Team
4) Set the company on the Lead
5) Convert to an opportunity and you will see an error showing up
Solution
A previous commit (1fad826743de9c8f916ef083e8de453212df6959) adapted the `_compute_company_id`
computation in which a case was forgotten (the case described here-above).
The fix was to force the `company_id` to the one of the `partner_id` if it
has one.
OPW-2805181
Task-2888330
closesodoo/odoo#88108closesodoo/odoo#94493
X-original-commit: fc3bb66a863cd3ff8c92d70dd43146a5610a4a43
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently using a customer with a company set on a lead without company
crashes, as it keep a void company on the lead. This is not compatible
with the company set on the partner itself.
OPW-2805181
Task-2888330
X-original-commit: 51be6cab5c4437ef56de5d1b25c0ba8486d25291
Part-of: odoo/odoo#94493
For bugfix purposes, app administration groups have been given to
(implied by) the "Settings" group because without those rights,
opening/saving the settings crashed.
1) Do not load hidden view content
This commit uses the conditional inheritance of views
(depending on user groups) to avoid loading unnecessary view
& record content client-side.
This improves performance for admins without the specific application
admin rights, but also fixes the main bugfix problem,
caused by the webclient querying name_get for the records in relational
fields content.
Example:
sale_management adds a res.config.settings field to specify
the default sale.order.template for the current company.
If a 'Settings' user without 'sale.group_sale_manager' opens the
settings, he won't see this setting, but if a default template is
specified for the current company, the webclient will still request
the name_get of this template to the server, because the field
was present in the view, only hidden with a groups attribute.
With this commit change in sale, the field won't be in the view unless
you have the Sale manager group, avoiding the error/traceback/bug.
2) Remove implied application administration groups
Do not force the specific application groups on all 'Settings' user,
they globally do not need those rights, and if they need it, they
can add it to their account themselves.
3) Add a test to make sure settings user are able to manage settings.
4) Enforce 'settings' -> 'access rights' -> 'internal user' groups
As the previous test highlighted some 'false positives' because
it considered a settings user unable to read `crm.team`
and `stock.warehouse` records, we also took the opportunity to enforce
the fact that 'Settings' & 'Access rights' users must be internal users.
It makes no sense for a portal/public user to have access to the
settings, and didn't work anyway.
Part-of: odoo/odoo#91909
This commit revamps the grouped-kanban implementation for smaller
screens (aka. mobile) by making it more "responsive" and avoiding
mobile-specific variation. It makes the implementation simpler and
closer to what the user expects from the desktop version.
In a nutshell:
- columns are displayed individually ; an horizontal scroll allows to
switch to the other ones, "snapping" to the column (aka. carroussel-like).
- each column takes 90% of the viewport's width to give a hint of its
siblings.
- each column scrolls (vertically) individually to avoid being lost when
switching from one column to another.
- folded columns are "virtually unfolded": they takes the same space as
the other ones, but content is loaded on-demand.
- some configuration modals are fullscreen for ease of use.
Part of the SCSS revamp task-2704984
task-2883057
Part-of: odoo/odoo#94134
Purpose
=======
In message_notify, when called on a recordset, call model methods instead of
base one defined on MailThread. This allows to use internal methods overrides.
Also perform some linting on calls to ``message_notify`` in order to better
spot calls, parameters, ...
Task-2852908
closesodoo/odoo#92868
Related: odoo/enterprise#28038
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, when creating a new stage, even if there are sales team(s)
available, the `team_count` always displays zero, because it is a
computed field but is not dependent on any other field.
This commit improves the behavior by small hack, which makes the
compute method dependent on `team_id` field so that it can be
triggered while creating a record.
taskID-2819559
closesodoo/odoo#88738
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit improves the helper string for 'My Pipleline' a bit in case
the logged in user has not joined any sales team yet. Also, if user is
having enough rights to access 'Configuration >Sales Team' menu, the
helper string will now contain a link to this menu as well.
task-2846401
closesodoo/odoo#91304
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
SPECIFICATION
Various change for the partner view:
- Moved the activity widget to the bottom right of the kanban
- Moved the informations badge to the bottom right next to the
activity widget and made them clickable
- Change the address options order and add a small help below
- Change the 'Remove' button function from delete to remove from
the company and add a delete button to the right end.
- Correct some typo
- Add an 'Archived' ribbon to the kanban card
- Change various small things
LINKS
Task-2821356
closesodoo/odoo#89249
Related: odoo/enterprise#26442
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Update to latest runbot state, at least for tests known to be
deterministic.
Notably mail tests are lower than before, probably due to odoo/odoo#73271closesodoo/odoo#93470
X-original-commit: 6118ecba8d807ac5ebc69ae4877e1f202b0daeb1
Related: odoo/enterprise#28308
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
install crm and change a lead between two won
stages
Expected behavior:
The date_closed does not change
Current behavior:
The date_closed changes
opw-2839298
closesodoo/odoo#92534
X-original-commit: 0c55c0d31021abe966c453c4827d5873a7af485c
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
Revert the possibility to install languages from the form views
of opportunity/lead and partner.
We consider that the quick installation of languages is too
advanced and admin people can go through the dedicated menu if
need be.
task-2839020
closesodoo/odoo#91750
X-original-commit: 5a616997659b2359ec946883b620e2fae6d6c39d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit shows the sum of field 'recurring_revenue_monthly' on
leads' kanban progressbar next to the sum of 'expected_revenue',
if the recurring revenu is enabled for logged in user.
taskID-2414576
closesodoo/odoo#66237
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Change all masculine nouns in Odoo's code to neutral nouns (when
possible), making sure that demo data is correctly handled. This is
particularly important since our code is open source, and nowadays lots
of machine learning models are trained on open source repositories.
With this small change we contribute to training more "fair" models, and
teaching models that "employee" or "user" != "he".
This also affects some text visible by the user, hence making it more
inclusive for Odoo users.
Task-2853046
closesodoo/odoo#91292
Related: odoo/enterprise#27302
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
How to reproduce the bug ?
- install the CRM and sales modules
- remove the user from the all the sales security group
- go back to the dashboard and click on settings
What is the bug ?
The res.config.settings model of the CRM module has a field referencing
the crm.lead.scoring.frequency model. This model can only be accessed by
the members of the sale security groups. If an admin is not part of the
sales group, he will get an error when he wants to access the settings
while he will not see the sales or the crm settings tab.
opw-2755177
closesodoo/odoo#91405
X-original-commit: 5f2d6dfac018339283971eadc2a3bbadc857ae35
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Minet Adrien (admi) <admi@odoo.com>
Prior to this commit branded UI components were styled exclusively in
raw SCSS using the '$o-brand-odoo' variable.
This leaded to unnecessary code repetitions since, to achieve the same
visual result, each module defined its own classes.
Visual inconsistencies were frequent too since each module defined its
own variations for interactive states (eg :hover).
This commit injects '$o-brand-odoo' into bootstrap's default
'$theme-color' map, allowing the framework to automatically generate
odoo utility/contextual classes.
These classes can be used to handle text, backgrounds, borders and
buttons wherever needed.
Part of the overall v16 SCSS optimization/restyle, task-2704984.
task-2800721
closesodoo/odoo#87448
Related: odoo/enterprise#25700
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Earlier in Odoo, JS views were defined by defining 4 elements: View,
Controller, Model, Renderer. This was complex in some way, because we
wanted to inherit behaviour as well, so it was necessary to think along
multiple dimensions to understand how the code was running.
Then, with Owl, we rewrote some views, and simplified them: views were
now just a Component. Most of the common behaviour now came from the
generic View component that instantiated the concrete view with the
proper informations. In practice, views were still split in views
(which was the equivalent of the Controller of earlier views), Model and
Renderer
Now, this commit reintroduce the Controller, and change the way views
are defined: by an object with multiple metadata, and an (optional)
props function to compute the actual props used by the view.
As a result, views are now much easier to extend/modify.
closesodoo/odoo#89889
Related: odoo/enterprise#26728
Signed-off-by: Géry Debongnie <ged@odoo.com>
Nikunj Ladava