Before this commit, the X2ManyField did not have a display name and its supported
types only mentioned one2many.
After this commit, those fields have a display name and the type many2many
is rightfully put has beng handled by the fields.
Part-of: odoo/odoo#107233
documentation link for drop shipping feature is missing as the documentation tag was added along with the field rather than the settings tag.
closesodoo/odoo#107192
Signed-off-by: Tiffany Chang <tic@odoo.com>
with canary islands taxes
Steps to reproduce:
1. Go to Apps, and Install the module `l10n_es`
2. Go to Accounting App > Customer invoices
3. Create a new Invoice with fake comany, fake address with state set as
`Santa Cruz de Tenerife (ES)` and the ZIP set as 38400.
4. Add any line to the invoice and confirm.
5. Try to Send & Print the invoice, you may need to select the template
before.
Issue:
We won't be able to either print or send the Invoice getting a traceback
containing `KeyError: 'tax_details_per_record'`.
Solution:
Keys for `vals` have change so we need to adapt it to match new keys
naming and sorting for accesing the same values.
FW - port: master
opw-3067491
closesodoo/odoo#107176
X-original-commit: accb722d12e76d178ba70b884a020e162e73634f
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
currently the table_id, customer_count fields are editable from the pos order form in the backend and all the other fields are readonly
closesodoo/odoo#107135
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
The routing-map is a mapping that maps HTTP verbs and paths to python
controller methods (endpoints), e.g. it maps `GET /web/health/` to
`/web:Home.health`. The `_generate_routing_map` function is the function
responsible to generating the werkzeug routing-map in regard to the
controller inheritance mechanism. The mechanism makes it possible to
override an endpoint is various odoo modules to enrich it with new
features, e.g. `/web/login` is overriden in website to change the visual
of the page.
Implementation-wise, the informations from each `@route` decorator must
be merged with the other `@route` info for each endpoint override. When
a method is not overriden in a controller, there is not new info and
that controller should be skipped for that method.
The previous implementation attempted to skip such method using the
following idiom:
if not hasattr(controller, method_name):
continue
That idiom doesn't work as `hasattr` will perform a lookup on the full
controller's MRO instead of a lookup only on controller's own methods
and attributes. The controller's own methods and attributes are
actually found in `controller.__dict__`.
closesodoo/odoo#107064
X-original-commit: 42f52d26b6a81a68f1fe28e28971f0e7f4c97d11
Signed-off-by: Julien Castiaux <juc@odoo.com>
This PR add a new page "Accounting Documents" with the journal entry, the list view asset_id and the statement_line_id. This make the first page more concise and allow the related asset to be more visible and simple to work with.
closesodoo/odoo#107205
Task-id: 3075466
Related: odoo/enterprise#34642
Signed-off-by: John Laterre (jol) <jol@odoo.com>
*: website
Commit [1] introduced the possibility to configure "website filters"
used in the website to display some records dynamically via the "dynamic
snippet" and its variants. One of their field is `limit` which is a max
number of records the filter allows to show (so that the client side
cannot ask for thousands of records). Users can configure the limit used
by a snippet via the editor: they are allowed to choose up to 16, still
safe-guarded by the internal limit configured on the website filter on
the python side.
The problem here was that [2] introduced website filters for the blog
posts but set up a max limit of 6. Thus breaking the editor option if
the user choose a limit between 7 and 16. This commit fixes the issue,
for newly configured snippets (as a stable fix) or for users who would
-u their blog application. EDIT: as the master version of this fix, all
blocks will now use their set limit. We consider that is an acceptable
change after migration that the user can change by himself if he wants
to.
Steps to reproduce:
- Install blog application
- Add a "Blog Posts" snippet
- Set "Fetched Elements" to 10 (there are 7 records in demo data)
=> Only 6 are still shown
[1]: https://github.com/odoo/odoo/commit/0e7640b5f22d2bea04bbe22d3189cff7e03af545
[2]: https://github.com/odoo/odoo/commit/3c0d98bcd8adf9325ee3497eb8d25ec7f904d6a5
opw-2885948
closesodoo/odoo#107179
X-original-commit: 3a3dc8729aa2beec49602fe4c141043f60effdf1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Define the following controller:
@route('/get-context', auth='public', type='json', website=True):
return request.env.context
Access that route via JSON-RPC providing a context:
this._rpc({
route: '/get-context',
params: {
context: {"a": 1}
}
})
Since httpocalypse, it replaces the context entirely instead of updating
it. i.e. before you would get along those lines:
{"a": 1, "lang": "en_US", "tz": "Europe/Brussels", "uid": 2}
but since you get instead (and that's wrong):
{"a": 1}
Note that after this commit, this merging-context behavior will be the
same whether or not website=True is defined (while it was only there for
website=True before).
Discovered via opw-2885948
X-original-commit: 7887cfc3f177d9e64f008aabb8bd710f54024dea
Part-of: odoo/odoo#107179
A MissingError traceback that occurs in `_build_bus_channel_list` was
caught by Sentry. This error has been seen 1.3k times in the last 30
days from several customers.
The fix simply consists in checking if the document exists before
checking the rights on it.
Traceback:
```
MissingError: Record does not exist or has been deleted.
(Record: project.task(83,), User: 6)
File "addons/bus/websocket.py", line 879, in _serve_forever
req.serve_websocket_message(message)
File "addons/bus/websocket.py", line 752, in serve_websocket_message
service_model.retrying(
File "odoo/service/model.py", line 134, in retrying
result = func()
File "addons/bus/websocket.py", line 767, in _serve_ir_websocket
ir_websocket._subscribe(data)
File "addons/bus/models/ir_websocket.py", line 38, in _subscribe
channels = set(self._build_bus_channel_list(data['channels']))
File "home/odoo/src/enterprise/16.0/spreadsheet_edition/models/ir_websocket.py", line 13, in _build_bus_channel_list
return super()._build_bus_channel_list(channels)
File "addons/web_editor/models/ir_websocket.py", line 33, in _build_bus_channel_list
document.check_access_rule('read')
```
SAAS-K22 (sentry code)
opw-3086292
closesodoo/odoo#106982
X-original-commit: 9e4c5e427285b76000398476e9d923e7ea036a65
Signed-off-by: Achraf <abz@odoo.com>
After a payment is processed by SIPS, a data object is posted back
to Odoo. The data has a `ScoreInfo` element that has more than one
`=` characters (e.g. `scoreInfo=A3;N;N#SC;N;TRANS=3:2;CUMUL=4500:250000`)
This causes the method `_sips_data_to_object` to break, because there
will be too many values to unpack.
To fix this, we should limit the data split to 2 values. This is the
same method used by SIPS to process data as well.
(See: https://github.com/worldline/Sips-International-non-FR-PHPlibrary/blob/master/lib/Sips/PaymentResponse.php#L73)
opw-3071315
closesodoo/odoo#107143
X-original-commit: 3dce793ad00b1c0b9f06c705f40e31666db74a06
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Ideally, we develop in English any localization (then translate to the domestic language, in this case Serbian) All the module has been translated in english and then a .po file has been create to translate back in Serbian
Added more info on the description of the module and activate storno by default.
closesodoo/odoo#107101
Task-id: 3086250
Related: odoo/enterprise#34608
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
In a view, in the case of a field node combining
- a `groups` attribute on the field node in the view architecture
- a `groups` attribute on the field in the Python model
e.g.
```py
name = fields.Char(groups='base.group_system')
```
```xml
<field name="name" groups="base.group_multi_company"/>
```
The view post-processing adds a temporary `<t groups` block.
e.g.
```xml
<t groups="base.group_system">
<field name="base.group_multi_company"/>
</t>
```
This is to make an `AND` connection with the two groups:
the user is required to have both groups in order to see the field.
Currently, there is no way to make that `AND` combination on the same
node. The below:
```xml
<field name="name" groups="base.group_system,base.group_multi_company"/>
```
would be an `OR` connection, not an `AND.`
Hence this temporary added `<t groups=""`.
Before this revision, in such a case,
the stack post-processing was interrupted by an unexpected side-effect:
The field node changes of parent (the parent becomes that `t` block),
and a condition attempting to check that the node wasn't deleted from
the view actually checked that the parent changed, to decide to
interrupt the rest of the stack post-processing, including the modifiers
post-processing for that node.
This revision changes this behavior,
to check the field node no longer has a parent,
instead of a change of parent,
to decide that the node is indeed no longer in the view,
and to interrupt the stack post-processing or not.
This allow the field modifiers (e.g. `attrs=""`) to be post-processed
as expected.
opw-3072910
closesodoo/odoo#107173
X-original-commit: c163cbb6a9b3679067606868e325d9842ea66aa8
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
If you try to get show_reset_to_draft_button for more than one account.move, it can raise.
closesodoo/odoo#107169
X-original-commit: a5b985e8449a1e858c3fb9a0a90a6d203e16f739
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The problem is that when you archive a company and then install
subcontracting, you get a traceback.
Step to reproduce (in a multi-company environment):
-install 'stock'
-archive a company
-install 'mrp_subcontracting'
-->traceback
Explanation:
When installing the 'mrp_subcontracting', there's a search on all
(active) companies in order to add a subcontracting location for each
of them (this is is triggered by
'/odoo/addons/mrp_subcontracting/data/mrp_subcontracting_data.xml').
But there is still a warehouse linked to the archived company.
So when adding routes to all warehouses and looking for the
subcontracting location of the archived company, it is set to
False. Which is not intended and causes the traceback.
Solution:
Add '.with_context(active_test=False)' to the search for the companies
in '_create_missing_subcontracting_location(self)', so the missing
subcontracting location will be created for the archived companies too.
Discussion:
-The ability to archive companies is new to Odoo16 (implemented due to
the new pricing).
-Here I considered that we want to create a subcontracting location for
an archived company instead of taking action on the warehouse linked to
the archived company (like not considering it when creating routes).
I did this because a company can be unarchived and with this fix, it
will not cause issues.
-I think other problems similar to this one (in any app), should appear
in the future.
opw-3039495
closesodoo/odoo#107168
X-original-commit: 1dcdbe9e3cc21af50ed580c032b1927e21c3c24b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The `align` command applies the alignment to the closest block of the
selected node. Bootstrap sets the default alignment of `.btn` to
`center` but we don't support links with a width that is larger than
their contents so that alignment is not visible. For these two reasons,
we want the toolbar to show the alignment of a link's closest block
rather than that of the link itself.
closesodoo/odoo#107155
X-original-commit: a3bb5b0c4b010b7583af1440cb65e889586636c8
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When the selection was in a link, the alignment buttons didn't work.
That is because they are supposed to align the parent paragraph, which
is temporarily in a contenteditable=false context when the selection is
in a link. This restores the context before applying an editor command,
and restores it afterwards.
task-3083748
X-original-commit: 0a4eb266b198e5e02a3325d063d07c0dd8af0148
Part-of: odoo/odoo#107155
When confirming a bill with a price diff, if the UoM of the bill
line is not the default UoM of the product, the values will be incorrect
To reproduce the issue:
(Need account_accountant)
1. In Settings, enable 'Units of Measure'
2. Create a product category PC:
- Costing Method: FIFO
- Inventory Valuation: Automated
3. Create a product P
- Type: Storable
- Category: PC
4. Create and confirm a PO with
- 1 Dozen x P at $50
5. Process the receipt R01
6. Create and process the return RT01 of R01
7. Create and process the return RT02 of RT01
8. Create the bill related to PO
9. Set the bill line price to $60
10. Confirm
11. Open the valuation of P
Error: a stock valuation layer has been created because of the price
diff, which is correct, however the value is not the good one: $670
instead of $10 ($60 - $50)
When confirming the bill, we check if there is a price difference.
To do so, we compare the price unit of the bill line with the one of
the incoming layer:
https://github.com/odoo/odoo/blob/d3d41c7679f9068a7b986925b15d0d7670233bfc/addons/stock_account/models/account_move.py#L304
But, currently, the price unit of the bill line is based on the UoM
of the line while the price unit of the layer is based on the
default UoM of the product. We need to convert the PU of the bill line
OPW-3081449
OPW-3062433
OPW-3075917
OPW-3048587
OPW-3078429
OPW-3075627
closesodoo/odoo#107145
X-original-commit: a1906f0b5e22f03937389d47e6ce5a650f9269e6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When confirming a bill, if its currency is not the one of the
company, and if there is a price diff, the value of the generated
SVL will be incorrect
To reproduce the issue:
(Need account_accountant)
1. Edit the currency of EUR:
- Rate: 2.0
2. Create a product category PC:
- Costing Method: FIFO
- Inventory Valuation: Automated
3. Create a product P
- Type: Storable
- Category: PC
4. Create and confirm a PO with
- 1 x P at $50
5. Process the receipt R01
6. Create and process the return RT01 of R01
7. Create and process the return RT02 of RT01
8. Create the bill related to PO
9. Edit the bill:
- Currency: EUR
- Price unit: 120
10. Confirm
11. Open the valuation of P
Error: a stock valuation layer has been created because of the price
diff, which is correct, however the value is not the good one: $70
instead of $10 ($60 - $50)
When confirming the bill, we check if there is a price difference.
To do so, we compare the price unit of the bill line with the one of
the incoming layer:
https://github.com/odoo/odoo/blob/d3d41c7679f9068a7b986925b15d0d7670233bfc/addons/stock_account/models/account_move.py#L304
But, currently, the price unit of the bill line is based on currency
of the account move wile the price unit of the layer is based in the
currency of the company.
Related to OPW-3040171
X-original-commit: 86ca91c3684fe5ea5dac1326278b5d4cce0cecda
Part-of: odoo/odoo#107145
When confirming a bill with a price diff, if the user received, returned
and received again the products, some unexpected valuation layers will
be generated
To reproduce the issue:
(Need account_accountant, sale_management)
1. Create a product category PC:
- Costing Method: FIFO
- Inventory Valuation: Automated
2. Create a product P
- Type: Storable
- Category: PC
3. Create and confirm a PO with
- 3 x P at $50
4. Process the receipt R01
5. Create and process the return RT01 of R01
6. Create and process the return RT02 of RT01
7. Create and confirm a SO with
- 1 X P
8. Process the delivery
9. Create the bill related to PO
10. Set the bill line unit price to $60
11. Confirm
12. Open the valuation of P
Error: There are two lines for the price difference, there should be
one line only. Moreover, the value is incorrect: 30 instead of 10 (i.e.
we should generate the price diff layer for the quantities in
stock only)
When confirming the bill, we check if we have to generate some
additional SVL (in case of price diff)
https://github.com/odoo/odoo/blob/d3d41c7679f9068a7b986925b15d0d7670233bfc/addons/stock_account/models/account_move.py#L288-L305
But, we get all ingoing SVL and process them, we don't consider that the
quantity of a SVL might actually be returned and should be ignored.
This is the reason why a SVL is created for the first receipt. This
also explains why the value is incorrect (we use the quantity of the
SVL instead of its remaining quantity)
OPW-3040171
X-original-commit: 18912b05239e6fc5dab26ec4c930f9080882d127
Part-of: odoo/odoo#107145
The current behaviour does not filter the cancelled moves when
evaluating if the product of the purchase order line is a kit.
This causes that, in cases where you have a cancelled wrong receipt
where the product was being received as a kit, if a new receipt is
created without receiving as a kit Odoo will always expect it as a kit.
After the fix, the cancelled moves will not be considered, as this is what
should be expected from cancelled operations.
closesodoo/odoo#107144
X-original-commit: 9659683d1f09c49a3ba3df8770eb7256660d0033
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit fix the issue where the slide content records,
crm team records and crm team members records were
overlapping on other group.
This was introduced by odoo/odoo#105531
Task-3086887
closesodoo/odoo#107159
X-original-commit: f7a2928afc4bc6f3ce4622f28f7cd9672b8a7b6f
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This commit ensures that when searching on a `inherits` field of
a model (like `name` of `website.page`), it works properly when
`pg_trgm` is activated.
Indeed, `name` is a field of `website.page` record but only at the ORM
level, not in SQL, due to how `inherits` works.
So, when the `pg_trgm` extension is enabled, it will switch from ORM
queries to raw SQL query (to use the native SQL similarity feature and
not our custom python/orm one, as obviously the SQL one is better, more
powerfull/accurate and faster).
But this will actually make the code fail when searching on fields from
a model which has `inherits` and that you search on that `inherits`
model fields.
Note that in 15.2, the `pg_trgm` extension is auto installed when
possible thanks to [1] and [2].
[1]: https://github.com/odoo/odoo/commit/eedf37d6e286b995c47b946be1a6b66817094eff
[2]: https://github.com/odoo/odoo/commit/75e6b645acdc95aece506ce0249fd0760838281c
opw-3063592
closesodoo/odoo#107178
X-original-commit: 3d978caad9de2010603581687ee39a5240b74074
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
New features to manage checks and managed them Odoo in latam countries
where they are widely use.
Own Checks Management
---------------------
Extends 'Check Printing Base' module to manage own checks with more features:
* allow using own checks that are not printed but filled manually by the user
* allow to use deferred or electronic checks
* printing is disabled
* check number is set manually by the user
* add an optional "Check Cash-In Date" for post-dated checks (deferred payments)
* add a menu to track own checks
Third Party Checks Management
-----------------------------
Add new "Third party check Management" feature.
There are 2 main Payment Methods additions:
* New Third Party Checks:
* allow the user create a check on the fly from a payment
* create a third party check from a customer payment
* Existing Third party check:
* allow the user to reuse a Third party check already created
* pay a vendor bill using an existing Third party check
* move an existing checks between journals (i.e. move to Rejected)
* Send/Receive again a check already used in a Vendor Bill/Customer INV
* allow the user to do mass check transfers
closesodoo/odoo#107163
X-original-commit: cbec68b414f5b87fe6e146487c532c9a174f40a3
Signed-off-by: William André (wan) <wan@odoo.com>
In order to make this modules to also match new module l10n_latam_check.
* refactory of some methods to make it more heritable
* check number now is showed only when is defined and is related to
check_printing payment method.
X-original-commit: 9394903813947cd4bfbad87f077cdf67233907d8
Part-of: odoo/odoo#107163
Currently in Sale/Orders/Sales Teams menu , The Sales Analysis dashboard
have text overflow bug for large numbers in USD/EUR this bug might be
rare but in currency like Yuan or VND its common
closesodoo/odoo#106822
X-original-commit: 5cebb129860616d80f8f6db6e261818f4ab54e05
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* = {account, sale, purchase, hr_expense}
When a plan is mandatory for SOL, POL or expenses, the flow should still be blocked when pressing the button, and not only when creating analytic lines.
We add the info in the context of the button, so automatic flows are still not blocked.
When the applicability rule requires a mandatory analytic distribution, raise an error upon :
- confirming PO,
- sending or confirming SO
- approving Expense Report by manager.
t-3040929
closesodoo/odoo#107166
X-original-commit: 8623a7850288828759db125b1054b0fed6b6b135
Signed-off-by: William André (wan) <wan@odoo.com>
If an aml has no product, it should not trigger a model that has a product.
So, we now define the fields that have to be checked on the model, instead of just being the ones given as parameters.
The way the field `company_id` impacts the model has also been changed.
The idea is that a model with a company specified should be better than a model without one.
But we also want that a model with 1 valid rule and no company is better than one with only a good selected company.
closesodoo/odoo#107165
X-original-commit: feff1a8a056f1fbbc852f7cf164e73abf83c4cc9
Signed-off-by: William André (wan) <wan@odoo.com>
This fixes the performance of the search panel of `account.move.line`
Menu > Accounting > Accounting > Journal Items
The control panel based on the accounts' roots was the issue (call to
`search_panel_select_range`)
Before this fix, the entire table was read through the use of a
`read_group`.
Since the data returned by the `read_group` is not interresting in our
case, we can simply do a lateral join on an indexed column with a limit
in order to improve the performances.
closesodoo/odoo#107164
X-original-commit: 26dd1d9627cdd04e12c3187f0f53c0e11892a345
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
This reverts 0e958ccd85
Using the id instead of the previous xpath makes it less natural.
It was also conflicting with `l10n_au` which was replacing that part
with something else, removing the id.
closesodoo/odoo#107186
Related: odoo/enterprise#34635
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
In order to pass the validation of the snailmail provider, the margins
are required to have nothing but white pixels. To avoid letters being
stuck until their layout is fixed, we fill the margins with white.
closesodoo/odoo#107180
X-original-commit: 206eb42468997d23b9b998530d246aa0bc69607d
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Signed-off-by: Solan Delvenne (sode) <sode@odoo.com>
Since mail.thread was removed from the account.bank.statement, the message_post code was causing a crash when attempting to import duplicate transactions.
This commit retrieves the messages from the returned action and displays them using the notification service
task-3044636
closesodoo/odoo#107167
X-original-commit: 6b5dd2399ccb2a7f533cdf7e2d00d0161a037c1a
Related: odoo/enterprise#34626
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>
- project.task form view:
- move the tag_ids field below the user_ids one
- move the 'allocated hours' field above the 'deadline' one
- remove the 'progress' field and indicate (x%) next to
'allocated hours' instead
- the final output should look something like
- 10:00 (incl. 05:00 on Subtasks) (50%)
- the timesheets o2m takes the whole width of the notebook
task-3046210
closesodoo/odoo#104677
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
There's a demo vendor bill that is fixed on the 2018, while it
sure should be set at more than an year ago, but not in a fixed
point in time that keeps getting further away from the present moment.
Task link: https://www.odoo.com/web#id=2732449&model=project.taskclosesodoo/odoo#107112
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Before this commit, when the editor was reset through updateWidget, the
options were not updated.
closesodoo/odoo#106450closesodoo/odoo#107108
X-original-commit: 8ac396e6709d1a2eb1134e376572c7a7ec0bd15e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Pregenerate doesn't work for rtl languages. It shouldn't be a problem
but it was discovered that pregenerate run during upgrades leading to
errors
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/16.0/odoo/service/server.py", line 1314, in preload_registries
env['ir.qweb']._pregenerate_assets_bundles()
File "/home/odoo/src/odoo/16.0/addons/website/models/ir_qweb.py", line 180, in _pregenerate_assets_bundles
_, _, _, id_unique, name = bundle_url.split('/')
ValueError: too many values to unpack (expected 5)tore the set of known environments as it was at setUp
```
This is because the rtl is an extra in the url breaking the logic.
Pregenerate is mainly usefull for tests on runbot
(or running tests locally), to speedup httpcases
avoiding generation at each page load.
IntegrityCases are postinstall but don't requires generating assets, or
at least no so often meaning that we can avoid the pregeneration in this
case. It should also avoid losing some time on pregeneration since it
is not useful.
This new logic only pregenerate if we have at least one HTTPCase in the
test suite. This should also speedup local testing when starting
non http post_install tests.
closesodoo/odoo#107107
X-original-commit: 43a5c17088707eec134d54ccf9341e86859f88c7
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
* = crm, mail, survey, test_event_full, website_event
To increase readability and performance, use f-strings where appropriate
(multiple concatenation +- formatting).
Note: Also removing unnecessary string concatenation with `%` for `(i)like`
in domains definitions.
Task-2977548
See odoo/enterprise#31156closesodoo/odoo#99811
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Purpose: In order to reduce the possibility to make errors, make the end
date of the validity period always come after the start date.
task - 3069666
closesodoo/odoo#106966
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
Since fixes done on the bom overview had to be done in a released
version, no method signature changes could be done, hence the use of
excessive context keys to bypass it.
Changes the signatures so that future work is done on better grounds,
and so that each method explicitely asks for what parameters it needs to
do its work.
closesodoo/odoo#107006
Related: odoo/enterprise#34577
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Commit 168cbe66bee7824bdf389de5c6c680342e27bc6d removes fields
with the 'groups' attribute from views when the user is not part
of the groups.
This is the case of product_uom_id in stock_scrap_form_view2,
but the field is mandatory for scrap creation,
therefore we use the unit of measure of the scrapped product
when not provided (as this is the case when uom are not checked).
Task: 2985735
Part-of: odoo/odoo#104062
Lucas Perais