Purpose of the commit is to let user select only those
products which are being shared among companies or belongs to own company.
On purchase order user will only able to select those products
which are belongs to same company as purchase order or products
which are sharable by default.
task-2025168
closes: #34342
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Purpose of the commit is to make the multi company consistence with product,
sale order and order template.
So the Common Product Catalog setting is removed from generel settings
because its behavior wasn't really clean from a technical point of view
(disabling the rule on products access) and wouldn't work as well with
new multi-company logic.
The default logic of sharing products will be kept, but when someone
wants to limit products sharing, he will do so product by product, by
setting the company_id.
Also the default company_id on product will be blank so default product
will be a sharable by multi company.
and added company_id on sale templates so user can select his/her own
company or the templates which are common.
task-2025168
Closes: #34342
Having an assert that randomly breaks is quite annoying, as this assert
is not critical and breaks once every 100 - 120 builds. It can "safely"
be commented out before being fixed
closesodoo/odoo#35043
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
The default value for a many2one on res.currency should be a
res.currency object not a res.company one
closesodoo/odoo#35004
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
There was an error in this tax's repartition. A tag was wrongly added to its base.
closesodoo/odoo#34245
Signed-off-by: Josse Colpaert <jco@openerp.com>
Under certain unknown conditions, the range cannot be applied and
triggered an error. In order to allow the user to keep editing, we need
to prevent the dialog from showing, hence the use of `console.error`.
If this error appears, the carret is moved to the beginning of the focused
node.
If this error appears, then bullet can generate an error (I managed to
have the bug once or simulate it by manually breaking the dom and range)
We suspect a wrong snippet custom javascript code.
see: https://github.com/odoo/odoo/pull/34188closesodoo/odoo#34871
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Let's assume a form view with a readonly many2one field with a
default value. When creating a new record, the user can click on
the many2one value, which should open the related record in a form
view (stacked in the breadcrumbs).
Before this rev., this didn't work: we actually came back to the
previous view/action in the breadcrumbs, when trying to open the
related record.
closesodoo/odoo#33172
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Backport of https://github.com/odoo/odoo/pull/34132
The test case of alipay payment is going to failed due to:
1) Now the redirect_url from the return_url is removed in commit :
https://github.com/odoo/odoo/commit/0aefe72b773a21bdd38fdc86779d3030bd5127c6
but it's still it's there in test cases so removed from test case.
2) To make the transaction done it must be in draft, pending or authorised
state but in first test case payment process the transaction state is set to
cancel and in another payment process use the same transaction again to set
it success so before use the same transaction again just set the state to draft.
task- 2005926
closesodoo/odoo#34708
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When the 'before' (resp. 'after') hook is defined on a QUnit module,
it is executed once, before (resp. after) the whole module is
executed. When the test suite is executed several times, tests that
failed in the previous execution are always executed first,
separately from the other tests of their module. In that case, the
'before' hook is executed directly (before the execution of the
failed test), but the 'after' hook is only executed once the whole
module has been executed. This means that a lot of other tests,
coming from other modules, can be executed in the meantime.
In calendar tests, we used the 'before' and 'after' hooks to catch
scroll events. So, when a calendar test failed, and the suite was
re-run, some tests depending on the scroll failed.
To prevent this, we use 'beforeEach' and 'afterEach' hooks instead,
as they are executed before and after each test.
closesodoo/odoo#34932
Signed-off-by: Julien Mougenot (JUM) <Arcasias@users.noreply.github.com>
When posting a message (here is the livechat use case),
the _postMessage function can call the callback function.
but this parameter is not mandatory.
If the caller of this function doesn't need a callback function
to be called after execution, the _postMessage function was crashing
as callback is not defined.
This commit fix this _postMessage function by checking that
callback is defined before calliing it.
Pre-required for Task ID: 2028059
Fix Task : 2037048
PR #34917
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
1* Allow products access from product_id / product_template_id of sale.order.line
2* Allow use of optional products along rentals and events.
closesodoo/odoo#34170
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Put toogle_button or a favorite widget to handle a boolean field in an editable list
click straight up on the widget's button or link
Before this commit, the widget changed its appearence, but the changes were not
propagated to the model. This is because the controller will not force_save if its mode is edit
(to let changes piling up and save everything when clicking save), which is the case
of the editable list
After this commit, following what has been done at 2f5e44d40b
clicking on a widget in an editable list just activates the row for editing
but doesn't change the widget's value
OPW 2033700
closesodoo/odoo#34878
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
previously, when user tried to change the schedule_date, it
was being passed as a string instead of datetime. corrected
that.
Task-2034542
closesodoo/odoo#34873
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
The ready code warning timeout of 2 seconds can be confusing since
it is triggered just after the 2 seconds. We can log this message
at the end in order to give the real timeout.
In JS tests, when the ready code takes too much time, a warning is
logged. As a consequence, the runbot updates the github status as a
failure, causing real pain to people who simply wants to merge their
features.
With this commit the warning is changed into an info and the runbot will
be happy.
closesodoo/odoo#34865
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Steps to reproduce the bug:
- Select template type boxed in general settings
- Select show serial/lot number in Delivery slip (in inventory - settings)
- Print the delivery slip with a non tacked product
Bug:
The delivery slip report displayed wrong columns.
opw:2031985
closesodoo/odoo#34852
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Usecase to reproduce:
- Create a MO for 5 final units
- Reserve all the components
- Produce 3 units
- Post Inventory (debug mode)
- Edit/Unlock
- Edit a line to consume to an arbitrary amount of quantity
- Change the product qty and set it to 3.
At this point, the reserved quantity and the quantity to consume
still the same than intialy even if the final quantity was updated.
- Mark as done
Then a move is marked as done withtout quantity done and still have
reserved quantity.
It happens because the _update_raw_move function do nothing if the
new quantity to consume is equals to 0.
The arguments returns in _update_raw_move still exists for override
but are not used by the chang_prod_qty method. It's not possible to
cancel the move and then find its parents in order to log the activity.
opw-2023653
closesodoo/odoo#34471
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Previous versions of this action had a domain. It was removed at 2d3e6d7383
Set explicitly an empty domain to force the removal when upgrading the module
Similar to 2d03ed43a5closesodoo/odoo#34581
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In PostgreSQL, we can't CREATE OR REPLACE VIEW if there is the type of the column change.
To fix it, just drop the view before creating it
closesodoo/odoo#34851
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Since the conversion from account.invoice into account.move the new view
displaying invoices wasn't showing the onboarding banner
closesodoo/odoo#34819
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Now we can deselect all the optional fields to compute the predictive
lead scoring.
Task 2028666
closesodoo/odoo#34614
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This is an api.multi method, which should therefore not call self.field.
Fortunately there's a loop just below.
opw 2035374
closesodoo/odoo#34832
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Future runbot improvement may share sources between build,
meaning that sources will be readonly to avoid any interaction.
_touch() was supposed to handle ro filesystem but
f7130556 introduced a new test that was not working
in this case.
Instead of trying to touch file and pseudomocking the result
if the filesystem is readonly, this commit add a real patch
on getmtime.
cherry-pick of b295723c99closesodoo/odoo#34823
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
jbm-odoo