Steps:
- Install Contacts
- Have Multi-Companies enabled
- Go to a Contact of type "Company"
- Click "Sales & Purchases"
- Assign it the company you're on
- Save and Edit again
- Remove the assigned company
- Go to a contact of type "Individual" linked to this company
- Click "Sales & Purchases"
Bug:
The company has not been deleted on the linked Individual
Explanation:
When we delete the company of a contact, the value of `vals.get('company_id')` is `False`.
This is why it didn't enter the propagation process.
This fix makes sure we can still remove a company from a contact linked to a user.
Related: https://github.com/odoo/odoo/pull/62418
opw:2391464
closesodoo/odoo#62591
X-original-commit: 59413ad88a97b3221526c2b560178a0f94ddee05
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
This commit cleans the default_* keys of the context before creating mail.mails
and mail.notifications when notifying the record by email.
Without this change, there can be a collision when the ORM tries to compute
default values for the state field (for example):
- Model "A" has a 'state' field ;
- Create an action that redirects to model "A" form view, setting some default
values in the context such as {'default_state': 'done'} ;
- Model "A" has an inherit on 'mail.thread' and a 'user_id' field to set a
responsible user ;
- Model "A" record is created with a responsible user, who is automatically
notified by email that the record "has been assigned to him" ;
(see mail_thread#_message_auto_subscribe_notify)
- A 'mail.mail' is in turn created ;
- The 'mail.mail' model ALSO has a 'state' field, and the context is propagated
so the ORM will try to assign 'done' to that field, which is an incorrect
value ;
- -> Crash.
If we ensure that the default_* keys are cleaned from the context, the default
values computation of the mail.mail record will not be affected and everything
works fine.
A test was added to ensure this behavior.
Task 2393259
closesodoo/odoo#62589
X-original-commit: 6b6e546ac95d9acb2964121dd52aa2896d31bc33
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
We provide a new helper class to help redact x2many commands for create
and write methods. To ensure best compatibility with the xmlrpc layer we
do not change the protocole, the commands are still 3-elements tuples
where the first element is still an integer in between 0 and 6. The
helper class provide the cannonical constants and static methods to ease
working with the commands. The new helper class is also available in QWeb.
Developers are encouraged to transition their code so it uses this new
helper class.
Task: 2366606
This commit fixes the step trigger:
'#o_website_links_link_tracker_form
#generated_tracked_link:contains("/r/")' that was taking too long
because of a call to _get_title_from_url happening during the creation
of a 'link.tracker'.
Before this commit the automated tests of website_links did trigger an
http request on the 'contactus' page which sometimes took too long to
respond and reached the test failure timeout.
After this commit the information obtained from this request is
hard-coded to avoid the unpredictable timing of the test.
This commit is a manual port of #62479.
task-2397724
closesodoo/odoo#62582
X-original-commit: db3296c034fe4c82d19580418fd5cdecdf578395
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
From python code, import a module class and print one of its field, it
shows garbage because the `model_name` and `name` fields are None. We
provide a default str/repr of the field.
closesodoo/odoo#46996
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This commit is mainly a revert to 13 functionalities in project_*
modules as functional changes introduced in 14 do not seem to be well
accepted by users.
Details:
- sale_timesheet: rename 'Ordered quantities' service_policy into 'Prepaid' project, sale_project, sale_timesheet: refactor task form view
- sale_timesheet: modify sale_line_employee_ids many2one widget on project form
- sale_timesheet: add link between ticket and sale order
- sale_timesheet: remove the option 'link to an existing SOL'
- sale_timesheet: remove the warning messages in project.task
- sale_timesheet: reword labels in customer_type and pricing
- sale_timesheet: adapt timesheet section on invoices in portal
- sale_timesheet: add timesheet section on orders in portal
- sale_timesheet: remove employee rate related warning on projects in Kanban view
- sale_timesheet: update sale_line_id of all the not invoiced timesheets accordingly to the employee mappings
- sale_timesheet: timesheet entries for employees that have no mapped SOL in project get the sol of the task or project
task-2388500
closesodoo/odoo#62568
Related: odoo/enterprise#15040
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The table picker was hard to use because its container scrolls instead of letting it overflow.
closesodoo/odoo#61783
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Behavior prior to the fix:
- when adding a filter on "Quantity < 0" (or > 0) on the forecast
inventory report the quantity reported becomes incorrect: for example if
there is a restock on Tuesday and a shipment on Friday that drives the
forecasted quantity into a negative, the forecasted inventory report
instead reports a negative quantity on Monday.
- the problem occurs because the view the report is based on is built
using positive and negative entries that are supposed to cancel each
other when accounting for stock items (quant). This way the quantity is
reported as 0 before the quant is moved in the inventory (there is a
positive entry for the quant, and a negative entry for the move up to
the move effective date). But when a filter on quantity is placed the
"cancelling" entries are not loaded and the report ends up with just the
negative value
Behavior after the fix:
- the quantities are reported as expected: with a negative on Friday,
and 0 on the days before
- to achieve this the view was modified to perform the grouping of
forecast entries inside of the view. This way we have one row per
product / day / state and we don't risk selecting only part of the
report.
- as the view is only read in aggregate there will not be any visible
changes to its consumers
opw-2379098
closesodoo/odoo#62574
X-original-commit: c16d4b5e7b9181c2c792f595a117de10510d45be
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
During the accounting tour, users are invited to upload one of their
bill, send one by mail, or use a sample bill.
For the last one, the returned action which opens a list view with the
new move does not have the correct context, which makes clicking on
'create' launch the creation of a journal entry and not a vendor bill.
This will make sure the context is correctly set in this case.
task id #2368810closesodoo/odoo#62332
X-original-commit: 3df9da9a712e719812b14085a4020e8a78db656a
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
In order to avoid eventual futur issues, this PR add a filter on the
journal field of journal entries to only allow selecting misc journals
task id #2371198closesodoo/odoo#62331
X-original-commit: 1b273d4c11e3e8d8583de302b71b2522a71f4d1d
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The kanban quick create is meant to stay open if a click event is triggered
within a modal, which was working for most cases before this commit.
However, there are some specific tricky cases when the behavior is incorrect.
Issues were mainly observed when using the many2one widget inside a quick
create card.
When typing something into a many2one widget and then focusing out of it, the
widget has a built in feature that asks the user if he wants to create the
record (based on options and necessary create rights).
This implies to open a modal asking the user to create or discard his input.
When you combine a many2one widget IN a kanban quick create card, then type
something in the many2one and click outside of the quick create, it triggers
BOTH the focus out event of the many2one and the click event of the kanban
quick create that verifies if it should be closed.
This click event creates a race condition but the following behavior happens
most of the times:
- The many2one 'focusout' is triggered first, creating the modal to confirm
record creation (see FieldMany2One#_onInputFocusout) ;
- The click event is registered second, triggering the quick create check to
see if it should be discarded (see RecordQuickCreate#_onWindowClicked) ;
- The click is technically registered outside of the modal since the modal was
not created yet. This behavior differs a bit between browsers:
- On Firefox the click event correctly targets the actual element that was
clicked (ex: another kanban card) ;
- On Chrome it varies between the actual element (same as Firefox) and
sometimes the raw 'body' element.
- The quick create card will then incorrectly consider the click as outside of
any condition to keep itself open and will close and destroy itself ;
- Which in turn destroys the FieldMany2One and the record creation modal ;
- (If you look carefully on the screen you can see a slight flicker when that
happens).
During all my testing, only one condition will stay consistent when focusing
out of the FieldMany2One by clicking somewhere else: the body element will
always have the "modal-open" class by the time the click event is triggered in
the RecordQuickCreate.
This is why relying on the condition that an element exists with the
"modal-open" class to avoid closing the quick create card provides reliable
results and seems to suit all necessary conditions and behaviors.
Task 2388450
closesodoo/odoo#62561
X-original-commit: 4930871701da2e2792e73ae3941f336046876f0e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
In the 12.3 editor revert, the handler for the getRecordInfo event was
removed, but the code that triggered this event was forgotten and now
doesn't do anything. This commit removes this dead code.
closesodoo/odoo#49126
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit fixes two bugs, the first one is a reinstall bug that
happens whenever the modules `payment` or `payment_test` are uninstalled
then reinstalled and the second one is a bug in which for some payment
acquirers, a journal is never created.
For the first bug, the problem is that when uninstalling the
aforementioned modules, the journals linked to each provider are not
deleted (which is ok from a business POV) and thus when reinstalling
said modules we simply recreate new journals, but journals have a
unicity constraint on (name, code, company_id), therefore the
re-creation of these journals will most likely fail.
This bug doesn't happen with other payment_* modules because all *main*
acquirers are defined in the payment module, except for payment_test
that defines its own acquirer (thus the fact that it fails to reinstall
too).
The solution chosen is to try to force the creation of the journals,
even if it may fail, within a try/except block: if it does fail, we
simply do a lookup for matching (name, code, company_id) and assign
whatever we find to the acquirer's journal_id. This approach was chosen
because the most common case is that of an install (journal creation),
so checking for existing journals first would make the most common case
less performant.
For the second bug, the part of the code that creates journals for
providers being installed made a false assumption: To find the acquirers
for which to create journals, it would gather the name of the
acquirer/provider from the module name of the modules being installed
(or that were already installed) and would compare them to existing
acquirers whose provider would match the names extracted from the module
name. However, not all payment_ modules contain the actual name of the
provider in the module name! payment_ingenico is one such case, while
the module name contains ingenico, the technical name for the provider
is 'ogone', meaning that the heuristic would never find an existing
acquirer with provider set to 'ingenico', therefore no journal would be
created for that specific payment provider.
The fix is trivial, payment.acquirer has related fields that point to
the modules that implement each provider, meaning that one can simply
check for all payment.acquirer whose module_state is 'to_install' or
'installed'.
This bug does not happen in v12 because when v12 was released ogone was
still ogone and not ingenico, and all payment acquirers actually
followed the convention of module name == provider name, but for
simplicity's sake we keep this change for v12 too since it's in the same
scope as for the first bug and the code is cleaner anyway.
closesodoo/odoo#62563
X-original-commit: 0b70f188ca441d6cf53b2ef63f4856239bbee8e4
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
What are the steps to reproduce your issue ?
1. Install "website_sale_comparison"
2. Create a product with only one variant with one attribut
3. Click on "Go to website" smart button
4. Enable "Customize/List View Variant"
5. Click on "Compare" button
What is currently happening ?
Nothing
What are you expecting to happen ?
Add product to the comparison list
Why is this happening ?
Because the product has just one variant and attribut so odoo don't
display it on the product page. The system cannot find the ids as
they are not on the page
How to fix the bug ?
Specify the product id in this case
opw-2377711
https://www.odoo.com/web#id=2377711&action=4043&model=project.task&view_type=form&cids=1&menu_id=4720closesodoo/odoo#62559
X-original-commit: 7ce7452c246ac97dcd5afeee3bd1906ecf9c82b0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
Reproduce:
* On a fresh db, create a payment
* Change the date to another month
* Validate
Issue:
* The name is computed before creation because it is the first of
journal/period.
* It is not visible
* It is given to the create vals of the move_id, so it is not correctly
recomputed
* The sequence/name are not in sync.
opw-2390747
closesodoo/odoo#62554
X-original-commit: 3a8247f603a02a05173ef917f9f07189ff5e01db
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
In some situation, the overlay does not reappear after disappearing.
Steps to reproduce:
1. add a title
2. add a few elements between title and footer so you can scroll title out of view
3. click title
4. scroll it out of view
5. click footer
6. scroll back up
7. click title
-> overlay is not reappearing[FIX]
Now overlay should not do that anymore.
closesodoo/odoo#62547
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When generating an efaktur, an error is raised
To reproduce the error:
(Use empty DB)
1. Set the company's country to Indonesia
2. Install Accounting (account_accountant)
3. Accounting > Customers > e-Faktur
4. Create & Save
5. Accounting > Customers > Customers
6. Create a customer
- Set country to Indonesia
- Add a TVA number
7. Accounting > Customers > Invoices
8. Create one for this customer
- Add a product
9. Save & Confirm
10. In Action, "Download e-faktur"
=> An error is raised.
OPW-2387843
closesodoo/odoo#62544
X-original-commit: 978e1168dddabebc31076eaebb5e20739bed4147
Signed-off-by: adwid <adwid@users.noreply.github.com>
- Create Product A with UOM of type Unit
- Create Product B with UOM of type Unit
- Create BOM of type Kit on Product A with Product B as a component
with UOM of type Unit
- After saving BOM, change the UOM of Product B with UOM from another
categories (e.g. kg) and save the product
- Try to access product list
A warning appears and prevent showing the products in any way.
It is caused by the call to `_compute_quantities`.
In this case, it is ok to skip the error. Indeed, it will raise later on
when trying to use the kit. But at least, it gives the possibility to
the user to access the product list.
opw-2393711
closesodoo/odoo#62537
X-original-commit: 6de2537ac82d9dad3cb3f56a7b9b35856681a6ad
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
What are the steps to reproduce your issue ?
1. Install "website_sale_comparison"
2. Create a product with only one variant with one attribut
3. Click on "Go to website" smart button
4. Enable "Customize/List View Variant"
5. Click on "Compare" button
What is currently happening ?
Nothing
What are you expecting to happen ?
Add product to the comparison list
Why is this happening ?
Because the product has just one variant and attribut so odoo don't
display it on the product page. The system cannot find the ids as
they are not on the page
How to fix the bug ?
Specify the product id in this case
opw-2377711
https://www.odoo.com/web#id=2377711&action=4043&model=project.task&view_type=form&cids=1&menu_id=4720closesodoo/odoo#62424
X-original-commit: ea1f23ea75c457c615968f3cb632fd7db7d39d6e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
Megamenu snippet should appear in the snippet editor "block" section ONLY if a megamenu element is selected.
In the current version, trying to filter snippets would make the megamenu snippet block appear.
closesodoo/odoo#62414
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The "active" field is a non-working deprecated alias to "auto_install",
it does not work and was confusing users (see #59850). It has been
removed.
closesodoo/odoo#62086
Task: 2361729
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
A manually created decimal precision won't have any impact on the system
unless used in custom code, and in this case, the record should be
specified directly in the custom code datas.
Furthermore, it can still be created/deleted in superuser mode if really
necessary.
closesodoo/odoo#60744
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The names of the decimal precision shouldn't be modified as this field
is used as reference in the code.
Modifying (e.g. translating) the name of a decimal precision will
disable the precision, always using 2 as precision fallback when the
specified precision is not found.
1) forbid deletion of main uoms & categories
2) warn modifications of main uoms data.
Except for the working Hours uom, which isn't a strict UoM
representation and could change between countries (and/or be deleted).
3) Also move the Dozen UoM to demo datas, it's a confusing UoM and isn't
used by the majority of databases.
4) Restrict deletion of used uoms on main models.
On sale orders and account moves the uoms couldn't be deleted thanks to the
SQL constraint covering the display_type logic, but the generic error message
is more clear for a user when deleting an uom.
Before this commit, Filter `Confirmed` was showing all Sales order irrespective of `website_id` while filter `Unpaid` was showing order having `website_id`.
Now, we have are showing all the sales order on `Unpaid` filter as we already have default filter "From Website" applied on action. So Both filters `Confirmed` and `Unpaid` will have no effect of `website_id` field.
closesodoo/odoo#60662
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Without this commit, when the compare/reset view feature was reading the arch,
it would translate it.
3 issues :
- When reading from file (hard reset), it would translate the file version
- When reading current arch, it would translate it
- When reading compare view arch, it would translate it
closesodoo/odoo#62521
X-original-commit: 1aa4d3cb57844c24d8520b6b974bb36526392ecf
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
There is a situation in pos_restaurant such that when an order
is deleted from the ticket screen, it persists to show when the
table is opened. To reproduce:
1. Create an order in T1 then add items to it.
2. Get out of the table (back to floor).
3. Open ticket screen.
4. Delete the order in T1.
5. Close the ticket screen.
6. Open T1, the order is still there (bug).
This commit fixes this behavior such that in step 6, new order should
show and not the deleted order.
Note that we also made a change in the template in order to allow
checking the number of synced orders during testing. We want to make
sure that the table is clicked when the sync finishes to prevent
concurrency issue during testing.
closesodoo/odoo#62488
X-original-commit: e6e2a7392a5dd518c3f0df1c1ac0f90b0cba78f4
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Joseph Caburnay (jcb) <caburj@users.noreply.github.com>
Behavior prior to this commit:
- when the warehouse uses a 3-step manufacturing process, if I create a
Sales Order, the MO generated does not show the SO# as "Source", instead
it shows the MO#
Behavior after this commit:
- the MO source shows the SO# (similar to how it works when using the
2-step or the 1-step manufacturing process)
- the origins are assigned thus:
- Delivery Picking = SO name
- Post-prod Picking = SO name
- MO = SO name
- Pre-prod Picking = MO name
Note:
- there is no implementation change in this commit - we just ported the
test from the original commit in 13.0 (the behavior in 14.0 was already
OK)
opw-2380717
closesodoo/odoo#62512
X-original-commit: 0281dee6da75e68403772ebd368d57c1feb98c37
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
Consider the following situation:
- have a form view with an x2many field displayed as a list
- the x2many field has a form view that contains an x2many field,
which isn't in the list
- for that x2many field, we can also open a form view to see/edit
the related records.
As the x2many field isn't in the list, when we open a subrecord, we
modify the fieldsInfo to add the information about the x2many field
we didn't know before. Doing so automatically applies raw changes
that we might have stored earlier (from onchanges) for that field,
because we couldn't apply them before knowing the type of that
field.
Before this commit, the function that applies the raw changes was
called recursively on the dataPoint and all its children (thus on
the x2many list datapoint), which produced a crash as this function
is designed to work on dataPoints of type record.
Actually, calling it on sub datapoints is useless, as it properly
works recursively, and applies raw changes on x2many fields itself
when necessary.
This commit ensures that we don't call this function on list
datapoints anymore.
Closes#62334
OPW 2389991
closesodoo/odoo#62511
X-original-commit: 2b7670e6d709cd311c630c99cb9da7d3d6ae90f4
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Only updates outdated requirements which actively cause issues:
* freezegun broken in 3.8 (removal of time.clock)
* xlrd broken in 3.8 (removal of time.clock)
* also monkeypatches xlrd.xlsx for 3.9 (removal of
Element.getiterator, breaks because of defusedxml)
* jinja triggers DeprecationWarning in 3.8
* pillow triggers warning in 3.9
* lxml, greenlet don't compile in 3.9
* reportlab doesn't work in 3.9
New versions try to match those of Debian Bullseye.
Also adds a script to more easily compare dependency versions between
the requirements files and what's in various distributions (currently
supports checking against debian and ubuntu).
Furthermore updates warnings filtering:
* removes xlrd (mischeck was monkeypatched as noted above)
* removes setuptools (was for older versions, one would hope this
isn't an issue anymore)
* adds babel: python-babel/babel#684 fixes the deprecation warning but
is not part of any release yet
* ignores error related to `random.sample` on a set, this is a
diagnostics bug because recordsets implement both Sequence and Set,
and the stdlib checks for Set first (bpo-42470)
See #59980Closes#61103closesodoo/odoo#62510
X-original-commit: 648635deca67df09417ae55c6eb181c98524b74d
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps to reproduce:
Create a new local Odoo DB
Create another company on the DB
install the CRM module
Create an opportunity on the CRM app for each company.
Execute This server action (CHANGE THE res_id TO THE IDs OF THE OPPORTUNITY CREATED):
```
for _ in range(0, 300):
for _ in range (0, 75):
env['ir.attachment'].sudo().create({'name': 'test','res_model': 'crm.lead', 'res_id': 31, 'type': 'binary'})
for _ in range (0, 75):
env['ir.attachment'].sudo().create({'name': 'test','res_model': 'crm.lead', 'res_id': 45, 'type': 'binary'})
```
go to the Settings / Technical / Database Structure / Attachments.
Server will look in endless call because the search try to retrieve
`limit` records, but after applying company record rule we have
`limit - e`, so it begin a second search for e records.
Even the second search will look for limit and possibly will find less,
starting a third...
If the sub call is aware of how much records we actually need after
checking permission, we can return the recordset if we have collected
enough
opw-2369722
closesodoo/odoo#62456
X-original-commit: 6a8f28c4d0f9df7cd8451f4caf4f3bf7d64330da
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Create a sale order for a stored product, save and confirm.
Validate delivery
Return and validate.
Return (the return, so delivery again) and validate.
Try return again.
The quantity to return in the widget will be 0.
Attempting to fix manually will worsen the situation creating negative
quantities on further action.
This occur because when creating the return the system tries to identity
other sibling return moves to set the correct quantity
This commit fine tunes 73de0645b730e1f1183b7c770e878b4c4ff1e0f1 aiming
to collect quantities only on actual sibling returns (moves sharing the
same parent)
opw-2379663
closesodoo/odoo#62169
X-original-commit: fe8c6db1323061f3e6a0fd3f8b294ea6ddb86acf
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Prior to this commit:
* The portal timesheet section was only visible in invoices when
invoicing policy was set to delivery.
* The portal timesheet section was not visible on orders.
After this commit:
* The portal timesheet section will be displayed for both delivery and order invoicing
policies.
* The portal timesheet section will be available for orders.
task-2388500
closesodoo/odoo#62516
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- Install website_slides
- Connect with an user (i.e. Mitchell Admin)
- Go to Website and open a Course quiz for the first time
(i.e. "Test Yourself" from "Basics of Furniture Creation" Course)
- Answer correctly
The number of won karma is the one from the last attempt reward and is not saved
in user's total xp.
When submitting the quiz, quiz_attempts_count is incremented via a SQL query,
but its value is not updated in cache directly.
When the karma gain is computed from the attempts count, the value used is the
old one in cache.
opw-2389969
closesodoo/odoo#62500
X-original-commit: d8254c130d4b04a0f1ff80990fe28e795bf9ad51
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
The mock implementation of `name_get` does not fully reflect
the real server implementation.
The real implementation is described in tests added in
this commit.
Note: in my wildest dreams, the mock server tests would be run
against the real *and* the mock implementation to ensure they
do not diverge.
closesodoo/odoo#62430
X-original-commit: c8f59bfd5c8ddb7c7abf1108111507e667393208
Related: odoo/enterprise#15017
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
nie