In this commit:
- On done MO's form, add an Unbuild button, it would open a
wizard with the form view of an unbuild, and some pre-filled fields
such as MO, product, BOM, quantity and total quantity finished which
can be edited.
- In the unbuild order, improve the on_change of mo_id:
if the selected product is tracked by serial number,
set quantity to 1 by default and readonly
- Also clean the testcase of unbuild order.
task-2144636
closesodoo/odoo#43719
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Co-authored-by: Ankita Raval <anr@odoo.com>
Improve the inherited wizards of 'stock.warn.insufficient.qty' by adding
some piece of information about the quantity involved. Also
change titles to integrated the related product into.
task-2144636
Co-authored-by: Ankita Raval <anr@odoo.com>
In this commit, on the product form, in purchase tab, the quantity
and the company fields of the vendor pricelist should be set
with optional = hide.
taks-2144636
In case of MTO (+buy) on products used in a MO,
add the link between the MO source and the PO generated.
Also add links between MO's when MTO+manufacturing.
task-1913392
closesodoo/odoo#43366
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
In case of MTO+Mufacturing on product in a confirmed sale order,
add a stat button to the MO generated by this SO. Also add the inverse,
from MO to SO source document.
task-1913392
In order to improve the navigation between of SO and PO in the case of
MTO, add a direct link between PO<->SO. When the SO is confirmed
(with storable product(s) with MTO + buy),
PO is/are generated, in this case, add a stat button on each model form
to avoid to manually search the related SO with the source field (name).
task-1913392
With this commit, the start time of single day events is displayed
in the calendar view, in month mode. This only applies to non allday
events. This can be disabled by setting (already existing) option
'hide_time' to true on the calendar arch.
task-2058477
Co-authored-by: Mohammed Shekha <msh@odoo.com>
currently if boolean_toggle widget is inside listview and if it is clicked and
set to false then listview row text set to text-muted, we want to remove this
behaviour as it is inconsistent and breaks any decoration-xxx set on the
treeview.
task-2179066
closesodoo/odoo#43754
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
- install contacts and purchase
- go to purchase > configuration > settings > activate "purchase agreements"
- go to general settings and activate multi-currency
- go to contacts > select a contact > edit > sale & purchase > change the currency
- go to purchase > purchase agreements > create
- change the agreement to a blanket order > add your modified contact as the vendor
Previous behavior:
the currency is not updated
Current behavior:
the currency is updated on vendor change
opw-2177431
closesodoo/odoo#43877
X-original-commit: 764135630949eb01cb2b3a4a19d6ec5b1bd39400
Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
Improve handling of JS logging in headless runner in order to avoid losing logs
and errors e.g. the issue fixed by odoo/odoo#41231 passed because it occurred
during module loading, which happens during initial page loading (browser_js >
navigate_to > _websocket_wait_event), which ignored logs (and exceptions though
here it's a console.error log), and as a result reported no failure (and would
simply miss that specific test as well as every test following it).
This requires additional modifications as we have a fair amount of silent
failures (exceptions or logging.error calls) at the moment:
- downgrade one error to a warning (which becomes an info at the python level)
- cleanup some synthetic / mock errors to better match what comes over RPC (and avoid transient or setup failures)
- tours which end in an action, leading to JS code executing during browser cleanup (and blowing up)
- if the last step triggers a default (implicit) run, replace by a no-op
- fix tours for which that does not work by either modifying the last step or adding an additional check step
closesodoo/odoo#43588
Forward-port-of: odoo/odoo#43567
Forward-port-of: odoo/odoo#41334
Related: odoo/enterprise#7813
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Issue
- Install Employees & Studio
- Configuration > Check Skills Management
- Go on an employee form
- Remove all data in Experience, Education & Skills
- Open Studio
- Click in the blank space before Skills
- Edit Form View
Traceback
Cause
The ORM tries to get the parent fields because the generated
datapoint includes them. (45bc7c9)
Normally the parent model is the same than the child model
but not in studio.
Solution
Merging the fields in the datapoint only if the models are the same.
OPW-2125214
closesodoo/odoo#43695
X-original-commit: d2dbc4faaad0988d71f591be7f50c94d455541b0
Related: odoo/enterprise#7849
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Small fix on the template to ensure the size of the partners's
images will never be larger than 128px.
closesodoo/odoo#43875
X-original-commit: 4879ace6868e02703069bcf420bd77275ee381f7
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before, when city_id was not set, both city and city_id
were shown, so when you created a new partner, you would
see 2 city fields in a weird way.
Now, we only show both fields when city is set, but not city_id
That way, in case you have some old partners before the installation
of the module, it will still work.
opw-2178992
closesodoo/odoo#43871
X-original-commit: 0a2cf833f9935c44d09ff7c46513dbc37c57bfe8
Signed-off-by: Josse Colpaert <jco@openerp.com>
We added min-height for `o_form_sheet` in form view with a commit[1] restoring
the views design (after views refactoring).
However, the min-height isn't very useful when form view is opened witin a
modal (FormViewDialog). Especially, when the form view is having only few
fields, the `o_form_sheet` container occupies unnecessary height and looks
a bit ugly.
This commit fixes the issues by setting the min-height to `0` for
`o_form_sheet` container in such cases.
[1] - https://github.com/odoo/odoo/commit/250e716c3a12#diff-01e46b3171a7282967199e5d45fca0e6R15
TaskID: 2150471
PR #41619closesodoo/odoo#43865
X-original-commit: 144d720bdc54ce762b84b1a78aa7e517ec1c3dd2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The move snippet arrows where not hiding properly when the target was
not movable.
closesodoo/odoo#43864
X-original-commit: ab32882ff0ecaf9995e52b062b880cd8ea0b6efa
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Probably coming from a conflict / rebase / forward port. Or several of those
keywords.
LINKS
Task ID 2180521 (add tests for crm wizards)
Task ID 2056759 (remove crm.partner.binding mixin)
Task ID 2088565 (crm onchange -> compute)
Community PR odoo/odoo#43473
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
As crm will soon evolve (onchange -> compute, code improvements, better
management of sales teams) cleaning and improving tests is necessary to avoid
regressions.
SPECIFICATIONS
This wizard has no tests at all. Even if it not really complex it is better
to have some tests ensuring at least marking a lead as lost with a reason
correctly updates it.
LINKS
Task ID 2180521 (add tests for crm wizards)
Task ID 2056759 (remove crm.partner.binding mixin)
Task ID 2088565 (crm onchange -> compute)
Community PR odoo/odoo#43473
PURPOSE
As crm will soon evolve (onchange -> compute, code improvements, better
management of sales teams) cleaning and improving tests is necessary to avoid
regressions.
SPECIFICATIONS
Improve and clean tests about leads and opportunities merge.
Some strange behaviors spotted :
* user_id / team_id interaction is somehow unclear;
* probability is not taken into account in confidence level, which is very
very strange;
LINKS
Task ID 2180521 (add tests for crm wizards)
Task ID 2056759 (remove crm.partner.binding mixin)
Task ID 2088565 (crm onchange -> compute)
Community PR odoo/odoo#43473
PURPOSE
As crm will soon evolve (onchange -> compute, code improvements, better
management of sales teams) cleaning and improving tests is necessary to avoid
regressions.
SPECIFICATIONS
After ff6b35f759 that added some first tests, this commit will add more tests
notably about convert wizards.
Notably
* add tests for crm.lead2opportunity.partner wizard, notably options about
action (do nothing, exist or create partner), as well as some corner cases
like stage update, lost leads, ...
* rewrite and improve tests about crm.lead2opportunity.partner.mass, aka the
mass converted wizard that implements some random behavior on top of the
crm.lead2opportunity.partner wizard;
Some strange behaviors spotted
* partner action works on lost leads, but not the convert;
* user_id / team_id / stage_id coherency is not enforced during convert
as it relies mainly on onchanges that are not called;
LINKS
Task ID 2180521 (add tests for crm wizards)
Task ID 2056759 (remove crm.partner.binding mixin)
Task ID 2088565 (crm onchange -> compute)
Community PR odoo/odoo#43473
This commit adds a wrapper element around the form view's notebook
tabs headers to allow the use of `overflow` and make it scrollable (e.g.
on smaller screens) without breaking the tabs' styling (e.g. the bottom
border).
This commit fixes an issue introduced by odoo/enterprise@e07aafbe6f.
closesodoo/odoo#43843
X-original-commit: 967777793cf2a7591ef3d9325497b105eb86577c
Related: odoo/enterprise#7906
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
1) Add the following stat buttons on the right of the Tasks one:
- (fa-tasks) Late Tasks: tasks whose deadline is exceeded (do not include tasks that
don't have a deadline set)
- (fa-tasks) Tasks in Overtime: tasks whose Effective hours are strictly greater than
their Planned hours (if the latter is stricly greater than 0)
2) Remove the sheet view (should be like financial reports)
3) Add an 'Other Revenues' metric under the Profitability section below 'To Invoice'
- It should represent all the revenues other than from timesheets linked to the analytic
account of the project.
- Only visible if greater than 0
4) Allow to fold/unfold the details by SO. It should be folded by default.
Note: Although qweb views have a generic mechanism to manage fold and unfold, this standard
behavior is not used here.
It would imply refactoring the entire code preparing the template data (700+ lines of
code which are hard to read). The quick and dirty way is used for now.
(I wish good luck for the dev if it's one day necessary.)
Task 2119567
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#40852
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Clean the context to get rid of residual default_* keys
that could cause issues afterward during the mail.message
generation. Example: 'default_parent_id' would refer to
the parent_id of the current record that was used during
its creation, but could refer to wrong parent message id,
leading to a traceback in case the related message_id
doesn't exist
closesodoo/odoo#43830
Taskid: 2176445
X-original-commit: 82d2d581a2590a9c782cbc71b5005a4198b70d77
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The order of the view is gantt,calendar,list but if you come form the saas-12.3 the view_id will remain defined with a calendar view
So we need to erase that value to have the gantt view by default
closesodoo/odoo#43829
X-original-commit: 3415ebd5702094d6903b1f4aa550c45d8d74da32
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This kind of companies (because of the AFIP responsibility type) should not have purchase tax defined by default and before this commit we have a default purchase tax named perception with actually is a optional tax that the user could set if needed but should not be set automatically set as default in all the invoice lines. This commit remove this default purchase tax when loading the chart of account to avoid this bad behavior.
closesodoo/odoo#43832
X-original-commit: b6df9291555ac79b6f1d64cb27235d8191d710b8
Signed-off-by: Josse Colpaert <jco@openerp.com>
Before this commit, in the list of invoices the customers were displayed
using only their names and not the company that they belong.
For instance, if 'Brandon Freeman' is part of the 'Azure Interior'
company, only his name was shown.
Now, the company names is also shown. In our example, the customer will
be displayed as : 'Azure Interior, Brandon Freeman'.
This behaviour was already the case in version 12.
opw-2179722
closesodoo/odoo#43824
X-original-commit: ca57cdeb80729a3e3b4bc2cc91376b625e1934ed
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Main
-----
For Huge Amount Invoices with small residual being paid and the Invoice and the
initial payment which almost paid, the invoice in full can render the
reconciliation of the Tax Entry Lines as fully reconciled.
Description
-----------
In case of multi-currency transactions where CABA Journal Entries are involved,
there could be a case where, in Mexican Localization, so far, a small entry
line cannot be reconciled with their counterpart because the previous
counterparts are already reconciled. (Though this is still unproved in a lab,
i.e. UnitTest, can be seen in the wild, i.e.Customer's Production Instance)
The following is an hypothetical case yet to be proven:
Test to validate tax effectively receivable
My company currency is MXN.
Invoice issued two days ago in USD at a rate => 1MXN = 0.80 USD.
Booked like:
Receivable 1450 1160 USD
Revenue 1250 -1000 USD
Taxes to Collect 200 -160 USD (Hypothetical Fully Reconciled with A1)
Payment issued today in USD at a rate => 1 MXN = 1.25 USD.
Booked like:
Bank 927.99 1159.99 USD
Receivable 927.99 -1159.99 USD
And a Tax Cash Basis Entry is generated for the ratio being paid
Booked like:
Tax Base Account 800 1000.00 USD (sometimes this base can be rounded up and instead of being 999.99 it ends up as 1000.00 which leads to taxes to be as fully reconciled)
Tax Base Account 800 -1000.00 USD
Taxes to Collect 128 160 USD (Hypothetical Fully Reconciled with A1)
Taxes to Paid 128 -160 USD
I will neglect to depict here the FX Journal Entry for Tax to Collect account for the hypothetical reconciliation A1. And any other FX Journal Entries.
At this moment Invoice has a USD 0.01 residual which on same date will be tried to write-off manually.
Write-off 0.01 0.01 USD
Receivable 0.01 -0.01 USD
At this moment Invoice has a USD 0.01 residual which on same date will be tried to write-off manually.
This small amount will create while running in run-time following CABA Journal Entry:
Tax Base Account 0.01 0.01 USD (sometimes this base can be rounded up and instead of being 0.00 it ends up as 0.01 which leads to taxes to be created and be tried to reconcile)
Tax Base Account 0.01 -0.01 USD
Taxes to Collect 0.01 0.01 USD (Hypothetical This will be tried to reconcile with the items in Full Reconciliation A1 but raise an error)
Taxes to Paid 0.01 -0.01 USD
closesodoo/odoo#43819
X-original-commit: 00861974c259fbbf381a597ed9d233525185a005
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
This reverts commit 976e560a87.
Even if it didn't looked like a bad idea, this need some more thinking.
This new version of query count creates random failure of runbot builds.
closesodoo/odoo#43820
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since the renaming of image fields to image_resolution (image_1920 in our case)
slide upload widget is using invalid field.
This commit adapt the field name to use the new naming (image_1920) instead.
Task id: 2179219
PR #43663closesodoo/odoo#43816
X-original-commit: 5991eb5b3ba9c6fb9426db235da7c8eb3821f0e1
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes the insert_record override where, after calling super,
the visitor is linked a lead with the id got from result, no matter if the
model is lead or not.
This commit adds the check to apply the link between visitor and lead only if
the current model is crm.lead.
Task ID: 2179631
PR #43731closesodoo/odoo#43814
X-original-commit: 37d4fa4385c6c98bff6b5adc7b6aa0ee325c49eb
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- install accounting
- go to accounting > configuration > charts of account
- create a chart of account with a code containing leading zero's
(ex: 000022)
- duplicate the previously created chart of account
Previous behavior:
leading zero's are not kept trough duplication
Current behavior:
the new code is padded with leading zero's to keep the same length
opw-2172816
closesodoo/odoo#43802
X-original-commit: c458c8ecee6b544b4056ccf5a9af591622238182
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In some flows, a planned_datetime_start/finished will contains
milliseconds. In these cases, we can detect overlaps/conflicts between
workorders but these conflicts can't be see in the web interface
(because datetime is truncate when it is display).
Then, change the conflicts computation to remove milliseconds
in search of conflicts.
task-2169447
closesodoo/odoo#43013
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Now, the fields date_planned_start and date_planned_finished is
required in views, because it was strongly related to the leave date_to, date_from
which are required.
- Change the name_get in case of single WO in MO and replace the dot
by a dash.
- Improve the WO form view to be more responsive when it is open from the
gantt view.
- Change name of a Operation in the demo data
task-2169447
- Before, the auto-planning of workorder autorize overlaps between then.
E.g. if a workorder (WO1) begin at Now + 30min with a duration of 60 minutes
and we try to plan a new workorder (WO2) Now, this one will be plan now
until Now + 120 min (30 min of WO2 + 60 min of WO1 + 30 min of WO2).
In our case we don't want this behavior by default,
because in real case, it is not efficient to work on job A during
30 min, after change to pass to a other job B, and rework on A after
the job B.
But in a other hand, we need to accept overlaps with no-working hours
intervals. Then, rewritte the _plan_workorders method to take
these features in account.
Also small fix about the planning has been done:
- Due to the strong link of date_planned(_...) between the MO and WO,
the replan of the late first WO was wrong.
If the MO is planned before now, then don't take in account
date_planned_start and try to plan WO as soon as possible.
- Also, fix error handling when the WO is planned before the
previous one.
task-2169447
When migrating a database, load_marked_modules will be called multiple times, alternating
to upgrade and to install modules. The main reason for this is still a litle confusing
but it as the side effect to log "Unmet dependencies" error multiple time in add_modules,
even if the dependency will be resolved later.
This commit removes the error level for this log, and replace it by another check,
performed at the end, logging any module in "to install"/"to upgrade" state.
Also log removed module as info (25), not warning. This may be changed latter
closesodoo/odoo#43797
X-original-commit: c5d6a3977de85fb974a4940fb11d54ef847e08e4
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit fixes the visitor's time_statistics computation. When creating a
new visitor, last connection datetime is not set, so it's not retrieved in the
search_read and crash at search_read_result[visitor.id].
This fix also speeds up and simplifies the time_statistics computation.
As time_connection_datetime is always set (for already created visitor) and in
the depends, no need to read values before looping, the data is already fetched
in memory. We can then use directly the value for each visitor in self.
Task ID: 2120464
PR #40199closesodoo/odoo#43780
X-original-commit: 1f0c9f272ea5b6b7b891fcb8d00eb81e7fe33f81
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
At 795c7b0a94 the external dependencies was changed from trying
to import 'ldap' to checking than 'pyldap' package was installed.
The problem is that pyldap is a unmaintained library that should no
longer be used, as explained on the package page:
https://pypi.org/project/pyldap/
"The pyldap fork was merged back into python-ldap, and released as
python-ldap 3.0.0."
Having pyldap version >= 3.0 installs python-ldap automatically and
will not cause any issue.
The Debian control file package name is adapted to use the latest.
The "ldap" externalm dependency defined in __manifest__.py will cause
pkg_resources.get_distribution() to fail in both case ("python-lap" or
"pyldap"), but the "import" fallback will succeed. For that reason, the
log warning is turned into a log info.
closesodoo/odoo#43769
Note: This library should be replaced by the pure python "ldap3" library.
X-original-commit: 1afd0ccf20881ba97e3c07dffb33e9a3a0b2cda4
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Before this commit, if the records had to be sorted according a
many2one field, and there was a sequence field on the many2one
comodel, the sequence was ignored. Now, the sequence is taken into
account like the actual server does.
Linked to odoo/enterprise/pull/7407
closesodoo/odoo#43763
X-original-commit: 714e52f98eec5c64a224523cee4b1e14463ed191
Related: odoo/enterprise#7869
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
