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>
- take advantage of runbot multi-build capabilities
- get similar result when running them locally during dev
- better detect when other modules add extra queries
Query counts are split in the base value (testing with just test_mail installed)
+ the extra modules overhead.
Part of task-2178641
closes odoo/odoo#43666
Pr: #43666
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
After this commit, x2many fields can have options like
create/delete which accept a domain, to make create/delete on
x2many conditional, say for example x2many field can have options
like:
options="{'create:' [('foo', '=', True)]', 'delete:' [('foo', '=', True)]'}"
With this when foo field is True, Create and Delete actions will
be available, but if foo is False then they won't.
In case of one2many fields, if 'create' is false, then 'Add a line'
(list) or 'Add' button (kanban) won't be displayed.
In case of many2many fields, 'Add a line' or 'Add' button will
always be displayed even if 'create' condition is false as it
doesn't really create records (but rather links existing ones).
Same applies for delete.
Task-2092953
closesodoo/odoo#42919
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Parth Chokshi <pch@odoo.com>
Co-authored-by: Aaron Bohy<aab@odoo.com>
This commit will fixed the error when product has some stock quants
and product category with 'Automated' valuation method, is set to that product.
==============================
Steps to product the above mentioned error:
1. Create product with any category which has 'Manual' valuation method.
2. Update 'On Hand' quantity for the same product.
3. Create product category with valuation method set to 'Automated'.
4. Now set the above product category to the same product which you created in step 1.
5. And Click on the save button.
==============================
Also edit the test case.
closesodoo/odoo#43755
Task: 2155804
X-original-commit: c62dea6a7ce6b63f708831707811e922cd6bddd0
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Display the `display_name` rathe rthan the `name` in order to include
the variant specification.
opw-2170400
closesodoo/odoo#43753
X-original-commit: c395eb91c769ea4bd3b74b89b0ee980f4169c3e0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit the search would search for phone numbers that contained a part of a string. The mobile phone would only look at exact matches so if we'd search for '0492700' the only result would be contacts with this exact match. After this commit every mobile phone that contains '0492700' will match and be shown. This allows for quickly finding customers by a partial mobile, just like the phone number does.
closesodoo/odoo#43752
X-original-commit: 8a34a6a66f3f06829231e5d0ba536fcdd27d17ea
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Task 2092079
Accounting firms that want to give access to their customers avoiding
mistakes and risks will love this profile that can't do anything
wrong... Maybe as well as companies auditors..?
closesodoo/odoo#39860
Related: odoo/enterprise#6576
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- Create some stock in WH/Stock for product A
- Create some stock in WH/Stock/Shelf 1 for product B
- Create a Repair Order for Product A in WH/Stock
- Add a line in Parts with B, leave the location to WH/Stock
- Process the order until the end
Negative quant is created in WH/Stock for B instead of using the
quantity in WH/Stock/Shelf 1.
We do a best effort in order to reserve the quantity in the
sub-locations.
opw-2177352
closesodoo/odoo#43716
X-original-commit: 2158f07cb2d32480f0db2a8e82aaea73ac266271
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Correct the rounding of several currencies which should be 0.001.
opw-2172122
closesodoo/odoo#43715
X-original-commit: 71f01060ea359814ffdb9ef506a01a2543dfc9ea
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a FIFO product, Automated
- Make some stock
- Create a SO, add the product
- On the SO, add an analytic account
- Validate the picking, create the invoice
=> the analytic info are propagated to the invoice, as expected
- Validate the invoice
The analytic info is propagated on the COGS entries, in particular the
the output account, which is incorrect.
opw-2008567
closesodoo/odoo#43690
X-original-commit: e831868fe648d3a3a4981a1cf9c135e4e4102279
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
`AttributeError: 'tuple' object has no attribute 'startswith'`
When given headers that are tuples. They are expected to be string, as per [1].
The issue was introduced with [2], indeed the code was moved from inside a dict
where `,` was the usual dict separator to outside of a dict where `,` at the end
made them tuples.
To reproduce the issue, run the `test_mail` suite after having
`website_mail_channel` installed.
Issue highlighted as part of task-2178641
[1] https://docs.python.org/3/library/email.policy.html#email.policy.Policy.header_store_parse
[2] cae1c3977fclosesodoo/odoo#43698
X-original-commit: 7e5a7245e86d8a3bcdab83c740cb4d188d009a40
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This is the second move to replace Filipino by Tagalog language
Using Filipino (code fil_PH) is problematic as conflicts with Finnish
(code fi_FI) and users having their browser in Finnish were redirected
to the Filipino version of the website (cf discussion at opw-2172710).
This problem was also raised in other softwares like in the below
discssion in Mozilla L10N groups
https://groups.google.com/forum/#!topic/mozilla.dev.l10n/TW2qYyDDNoE
Quoting the discussion in above thread:
> Filipino is the national language of the Philippines, but it is
> commonly referred to (and registered as) Tagalog, since most of the
> terms therein were derived from it (Tagalog).
This commit targets the master (future 14.0 as of today), adds a new
Tagalog language and removes the Filipino.
In 12.0, only the Tagalog was added.
As fil_PH is only translated on odoo-com project but remains at 0% in
other Transifex project, it is assumed the language switch won't
impact too many people.
closesodoo/odoo#43634
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
This commit fix most `t-set` errors that either led to:
1. unwanted text to be considered as translatable.
eg: `<t t-set="classes">text-left bg-100 p4</t>` would create an
`ir.translation`.
2. text that should be translatable were not.
eg: `<t t-set="text" t-value="'Both'"/>` would not create an
`ir.translation` while it should.
If a text should be translatable, it should never be inside a `t-value`:
- `<t t-set="text">Both</t>`
If a text should not be translatable, it sould either be inside `t-value`,
`t-valuef` or the `<t>` tag should have `t-translation="off"`:
- `<t t-set="classes" t-translation="off">text-left bg-100 p4</t>`
- `<t t-set="classes" t-valuef="text-left bg-100 p4"/>`
- `<t t-set="classes" t-value="'text-left bg-100 p4'"/>`
https://github.com/odoo/odoo/pull/43660https://github.com/odoo/enterprise/pull/7839https://github.com/odoo/design-themes/pull/203closesodoo/odoo#43660
Related: odoo/enterprise#7839
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
shreya thakrar