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
Following some user brain tests analysis, the following small modifications have been implemented to improve the usability of the app.
* Delete the quick create option of the payment terms
* Change the name of the payment column in the invoice menu
* Removing the tags of the payment column when the state is different of posted
* When only one currency is activated the currency symbol wasn't displayed anymore cause of recent change on the js side with "group", by adding the field currency_id invisible in the arch the problem is solved
closesodoo/odoo#106903
Task-id: 3085423
Related: odoo/enterprise#34558
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Before this commit, the rendering context of kanban and form views
was the instance of the KanbanRecord and FormRenderer, respectively.
As a consequence, a lot of implementation details (e.g. "props",
"__owl__", any Class method...) were available. This wasn't what
we want.
The door being left open, people went through, and in 16.0, several
kanban and form archs contain(ed) such use of undesired "features".
With this commit, we restrict the rendering context of those two
views. In kanban views, it contains what has been historically
available (e.g. "record", "widget", "kanban_color"...). In form
views, nothing is available since the only dynamic part in those
archs is the attrs, which aren't evaluated by the rendering engine.
To do that, we use `t-call-context` owl directive. When using this
directive, the rendering context is the given one, + `this`. So the
component instance is still available, but through the `this`
keyword. We can thus use it in our compilers, to make them work as
before. Note that `this` can never be used in an arch directly.
Task 3085357
closesodoo/odoo#106045
Related: odoo/enterprise#34493
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
`getInSelection` had a check that depended on `closestElement` returning
an element (and not `undefined` or `null`).
closesodoo/odoo#107061
X-original-commit: 0eeff8266ab1c3bdd15d4587aaf83e299811c3fa
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
If you clicked on a pictogram, then previewed various colors for it by
hovering colors in the colorpicker of the toolbar, the toolbar started
flickering uncomfortably. That's because the selection was changed
at every color change, which was unnecessary.
closesodoo/odoo#107041
X-original-commit: f0ff5dc4bdaf5a1704f1af55d46b253e234712a4
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
If you clicked on a pictogram, then changed its color with the text
colorpicker in the toolbar, the toolbar was replaced with the regular
text toolbar, even though what was being edited was the pictogram.
That's because the information of the last media clicked was lost in the
process.
task-3045166
X-original-commit: fa1c7e68eaa544445621ca7e7e2c647ffe857447
Part-of: odoo/odoo#107041
A commit [1] has recently be added to fix an issue. It actually fixes
another issue too:
1. Create a product P
- Storable
- With one packaging PK for 10 x P
2. Create and confirm a PO
- Order Lines:
- 10 x P with PK
3. On the PO, decrease the quantity of P to 8
Without [1], a return is created for the difference. With [1], the
existing picking is correctly updated.
This commit adds a test to protect the use case.
[1] 20fa7c6f0f5c9cdfae2519ea8d0ff849d7fa3b9e
OPW-3027110
closesodoo/odoo#107045
X-original-commit: ccf771d19c5d7b7021c8d0411e11a3f7e9907899
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When decreasing the qty of a SOL, if there is already a packaging
defined, a return will be created for the difference
To reproduce the issue:
1. Create a product P
- Storable
- With one packaging PK for 10 x P
2. Create and confirm a SO
- Order Lines:
- 10 x P with PK
3. On the SO, decrease the quantity of P to 8
Error: a return is created for the difference. Instead, the existing
picking should be updated
At some point, we try to merge the stock moves (`10 x P` and `-2 x P`)
and, to do so, they must have the same `product_packaging_id`:
https://github.com/odoo/odoo/blob/08f53ffa30479cfb452ebaed61b42655eb0e6a95/addons/stock/models/stock_move.py#L808-L813
However, on the SO, when decreasing the quantity, an onchange tries to
find the best packaging. Because the new quantity is not a multiple of
PK, this one is not returned. As a result, the SO has no more packaging
and so does the new stock move (`-2 x P`). Therefore, the stock moves
can not be merged and a new picking (the return) is created.
This commit updates the onchange method so it behaves the same way as
purchase side:
https://github.com/odoo/odoo/blob/20fa7c6f0f5c9cdfae2519ea8d0ff849d7fa3b9e/addons/purchase/models/purchase.py#L1224-L1231
In this onchange, the same diff has recently be added for another reason
(see [1])
[1] 20fa7c6f0f5c9cdfae2519ea8d0ff849d7fa3b9e
OPW-3027110
X-original-commit: e92e960a36babf4daf8f79d210c7f53fb376aa74
Part-of: odoo/odoo#107045
Incorporate Ulises Rivadeneyra (UlisesRivadeneyra) as Vauxoo's contributor
I confirm I have signed the CLA and read the PR guidelines at
www.odoo.com/submit-pr
closesodoo/odoo#107063
X-original-commit: e943bfac0cb1eccf2231ac73b3f14bfced474f5f
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Simple refactor in order to make changes to these line trigger the CI/Security
closesodoo/odoo#107032
X-original-commit: 3c215581aa1f8f74f2d9daf1e15f30ee750ec3df
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit, when the editor was reset through updateWidget, the
options were not updated.
closesodoo/odoo#107029
X-original-commit: ffd77cf6aee37f8912e1367f8f9ca2f6344e9577
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When converting the list view to owl, the caret indicator for groups in
list view was incorrectly given the extra class `fa-fw` which gives the
icon a fixed-width. This is incompatible with using padding as spacers,
and caused the caret to overlap the group name in nested groups.
This commit fixes that by removing the `fa-fw` class.
closesodoo/odoo#106994
X-original-commit: ff1055ddd07653d156a5887081f3ebe22dcbcae0
Signed-off-by: Samuel Degueldre <sad@odoo.com>
When breaking a page from a Carousel or other slider snippet (eg by
hitting the backspace key at the beginning of a page), the editor's
history gets reverted but ends up applying the `active` class to all
pages. This is due is some way to the `_computeHeights` method of the
slider snippet, which applied the class to all pages to observe their
heights, then put them back in place. It seems in the labyrinth of ticks
the history step somehow started from a place where every page was
active, so we reverted back to that. The point where these classes were
applied should have never been observed in the first place since it's
purely technical. Not observing it fixes the bug.
task-3081259
closesodoo/odoo#106986
X-original-commit: be1d93edcfbd496c22a7c988b4570858a3d06c2c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
[ADD] l10n_ro: Add COA & tax & tax report data
Add the Coa and tax data for the peruvian
localisation (in english with translations)
task-2697901
closesodoo/odoo#104065
Related: odoo/enterprise#33176
Signed-off-by: William André (wan) <wan@odoo.com>
before this commit,
Users are unable to fold/unfold tickets
after this commit,
Users can fold/unfold tickets
task- 3081378
closesodoo/odoo#106992
X-original-commit: ae5df3e46559185773d2826bfbd74335df4d122d
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Stepts to reproduce:
Go to Time-off app > configuration > Public Holidays.
Try to create a new holiday and select working hours.
Issue:
It will show up all the working hours available for all companies even
if we are not in that company at the moment.
Solution:
We need to take into account the company for this field in order to only
show the working hours available for this specific company. I've added
to the field the `domain="[('company_id', 'in', [company_id, False])]"`
in order to follow the same behavior as next versions.
This issue affects 15.0 and saas-15.2
opw-3068827
closesodoo/odoo#106981
X-original-commit: 65f2861bf2728a7f9f991c47edc77fc557dfde14
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit description is in three parts: a generic explanation, a real
use case and the solutions
**Explanations**
1. When getting an odoo `Environment`, we first generate a tuple used as
an environment identifier:
https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L446
Then, there are two possibilities:
1. If such environment already exists in the environments list of the
transaction, we reuse it:
https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L448-L452
2. Else, we create a new one and store it in the transaction:
https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L454-L464
2. The `company` attribute of an `Environment` object is a lazy property
https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L537-L538
It means that its value won't be recomputed unless we delete it
https://github.com/odoo/odoo/blob/083c70bbb63f27839b2c9a4b549e216947bc4dd1/odoo/tools/func.py#L12-L17
3. When running a `SavepointCase` test class, the `setUp` method ensures
that, after each test, we do cleaning:
https://github.com/odoo/odoo/blob/a50a65be19b682201fc010d33c1b1f0b90cdf4d3/odoo/tests/common.py#L652-L662
The functions are added in a stack. So, in the execution order, we
will
1. Clear the current environment and the registry
2. Reset the environments list with the ones that were existing
before the executed test
4. Suppose a test class TC that inherits `SavepointCase`. TC has a
special `setUpClass`:
1. We create a new user U and replace the environment with a new one,
E1, based on U. This user has a company Comp_U. Because of [1], the new
environment E1 is added to the environments list of the transaction.
2. For some reasons, we need to do some operations in `sudo` mode:
again, because of [1], a new environment E2 (same as E1 but with the
`su` flag to `True`) is created and added to the environments list of
the transaction
5. TC contains a first test T1. In that test, we create a company
Comp_tmp and set it as default one to U. Therefore, E1 and E2 are
updated (their `company` attribute is now Comp_tmp)
6. At the end of T1, because of [3]:
1. E1 is reset (but its lazy properties are not deleted)
2. The environments list of the transaction is reset and still
contains E1 and E2 as they have been created in the class setup (i.e.
before the test setup)
7. In a second test T2, there will be an inconsistency: both E1 and E2
have an incorrect value for their field `company`: Comp_tmp, which is
not the value defined on `self.env.user.company_id` (the value Comp_tmp
does not even exist anymore)
**Real use case**
- The class `AccountTestInvoicingCommon` is an inheritance of
`SavepointCase`. In its class setup, we create a user and set it on the
current environment. Later on, we create a company (the sudo mode will
be activated during the company creation process)
https://github.com/odoo/odoo/blob/1e69c4fe5f8dd8a92d92f350b6d6a9539157f206/addons/account/tests/common.py#L38-L52
- The class `TestPurchaseOrder` inherits `AccountTestInvoicingCommon`
- The test `:TestPurchaseOrder.test_06_on_time_rate` creates a company
and sets it as the one of the current user
https://github.com/odoo/odoo/blob/87ffe5983be7f0f4a926b458c4bd1f13001048ec/addons/purchase_stock/tests/test_purchase_order.py#L313-L316
- Therefore, all next tests will have an issue with the environment
(unless we force the writing of the company on the current user to
bypass the issue)
```py
self.assertEqual(self.env.user.company_id, self.env.company) # will fail
self.assertTrue(self.env.company.exists()) # will fail
```
**Solution**
The above issue has been fixed from Odoo 15 on, thanks to commit C1.
Thanks to that diff, at step [3.1] in the above explanations, the lazy
properties of E1 are deleted (so, because of [2], the `company`
attribute of E1 will be correct again). However, once C1 is applied, we
can still add some lines in T2 to fail the test:
```py
sudo_env = self.env.user.sudo().env
self.assertEqual(self.env.user.company_id, sudo_env.company) # will fail
self.assertTrue(sudo_env.company.exists()) # will fail
```
The reason: at the end of the test T1, we reset the environments list of
the transaction ([6.2]). However, E2 has been created before the test
setup (it was in the class setup, see [4.2]). So, after the list reset,
E2 is still in that list and still has the value Comp_tmp for its
`company` attribute.
So... first we can conclude that C1 is not enough. Second, once the
environments list of the transaction is reset ([3.2]), we also have to
reset each environment to ensure that their lazy properties are correct.
We can then remove [3.1] since it will be included in that new step.
C1 a40511cd29closesodoo/odoo#106952
X-original-commit: a685f17ec9b0663d3632c903f4f0304d9a58f103
Signed-off-by: Raphael Collet <rco@odoo.com>
The association module was just overwriting a menuitem in membership. This
commit removes the association module and migrates the menuitem change to
membership.
task-3080120
closesodoo/odoo#106472
Related: odoo/upgrade#4075
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Romain Derie