It's the unique group needed for a kiosk attendance. Avoid to give
to much rigths.
id=2088561
closesodoo/odoo#38954
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Use correct company to get fiscal positions and properties
Ensure company used to fetch fiscal positions is always the correct one
when coming from a company restricted model (company_id required, or
related.required).
NB: if the company_id isn't defined, with_company doesn't change the
environment.
purchase: get_fiscal_position doesn't consider company_id ctxt key
others: properties were accessed with potentially the wrong company.
From now on, if one wants to force following operations to happen in a given company,
use with_company(company) or with_company(cid) to update the environment.
If a warehouse is created without code (eg. when created as a new group
from a kanban view grouped by warehouse) we would get a traceback
instead of an error:
```
The operation cannot be completed:
- Create/update: a mandatory field is not set.
- Delete: another model requires the record being deleted. If possible, archive it instead.
Model: Warehouse (stock.warehouse), Field: Short Name (code)
```
opw-2124162
fix#40233closes#40267closesodoo/odoo#40382
X-original-commit: b6caa179e17199b29a9ca4009c53acb378423926
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Lead/Opportunity type
=====================
In the settings, if ``group_use_leads`` is checked, we add the group ``use_leads`` to all users in the group ``base.group_user``
To know if the setting is checked, in the model ``crm.lead``, we compute this code,
```
self.env['res.users'].has_group('crm.group_use_lead')
```
In 12.0
=======
When we compute ``sudo``, we are as the admin user.
The admin user is in the group ``base.group_user`` and so, he can be in the group ``use_leads``,
so everything work fine.
In 13.0
=======
When we perform a ``sudo``, we keep the same user.
But the visitor is not in the group ``base.group_user`` (he is in the group ``base.group_public``)
So, the visitor can never be in the group ``use_leads``
Fix
===
To fix it, we just need to compute the method ``has_group`` as the super user (which is in the group ``base.group_user``).
```
self.with_user(SUPERUSER_ID).env['res.users'].has_group('crm.group_use_lead')
```
Task #2124421closesodoo/odoo#40418
X-original-commit: 8758bdc24297032ba8fd65f637a6990c6351dd27
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Reproduce the issue
- Install Events
- Set the english default format date to %d/%m/%Y
- Create an event & edit the date
The date is set correctly in the backend
- Edit the date of an event on the website directly
The date format is still the old one
Cause
The `from_html` method of DateTime was using `parser.parse` and
ignore the user's date format.
This commit changes `parser.parse` into `datetime.strptime` taking
into consideration the user's date format.
closesodoo/odoo#40415
X-original-commit: d00c0e317f8affbe8bea231972c2b6da70b9f240
Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>
-In CRM, click the CREATE button.
-Only enter a title for the new lead and directly click ADD.
-Click on the newly created lead to view its details.
Before this commit:
although a probability could be computed based on the stage of the lead, this
field has a default value and, at creation time, this value doesn't end up in
the list of values from which the `_write_probability` function decide whether
to recompute the probability.
After this commit:
The `_write_probability` function, renamed `_update_probability`, doesn't check
whether it should or not update the probability. It just does it. This function
is directly called in the `create`. `_should_update_probability` is called
before `_update_probability` in the `write`.
Task ID : 2081480
closesodoo/odoo#40411
X-original-commit: 483a94116629e418ebb224bad375747cf9ab3c1d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When changing fields in Manager -> Allocation Form, the name (display_name) was recalculated only after the form was saved or only after the description was changed.
closesodoo/odoo#39553
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Now, we should either use:
- A we-select (in the end, same as collapse except it does not push the
elements in the UI)
- A simple div to always display the elements
Part of https://github.com/odoo/odoo/pull/38959
task-2066614
closesodoo/odoo#38959
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Previously, background size and position for snippets was configured in
a modal, the user could choose a "focus point", which is rather
unintuitive. They could also choose to use the "contain" background
mode, with or without repeat, or a third option, where they could
customize everything, from the background size in both directions to
whether to repeat the background in only one or in both directions.
This commit streamlines the background-sizing options, only the "cover"
and "repeat pattern" options have been kept, as they cover almost every
use case. Their configuration has been moved into the options menu for
consistency with the rest of the editor, and the background's position
is now chosen by clicking on the corresponding menu option, and dragging
the background to the desired place.
Part of https://github.com/odoo/odoo/pull/38959
maintask-2066614
task-2088304
This will allow to do the following:
1) Show a preview overlay over an element
2) Block preview overlays -> the overlay at step 1 stays no matter what
3) Encourage the user to do something that edits what the preview
overlay is currently showing.
4) The edition is finished, go back to normal by unblocking preview
overlays.
Part of https://github.com/odoo/odoo/pull/38959
task-2066614
* web_editor
This commit adds a slide counter in carousel snippets option menu, as
well as left and right buttons, this way the user can manage their
slides entirely from the options, instead of having to go to the block
itself to navigate to where they want before going back to the option
menu to add or remove a slide.
Part of https://github.com/odoo/odoo/pull/38959
maintask-2066614
task-2088291
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Currently we have:
- a colorpicker for background color of snippets
- a colorpicker for foreground and background text (topbar)
- a colorpicker for menu/footer/navbar/etc
These 3 are separate colorpickers with different options.
After this Commit
All 3 will use the same color palette wich allow you to select
theme color, common colors, custom color and transparent filter.
Part of https://github.com/odoo/odoo/pull/38959
maintask-2066614
task-2087383
* web_editor
Previously, the user could choose their anchor names using a modal
window, anchor names also have weird rules, this was not a great user
experience.
This commit makes the anchor button generate anchors automatically based
on the first title in a section, or the snippet name if there are none.
If the anchor name is already taken, it is suffixed by a number. After
it has been generated, it is also copied to the clipboard and the user
is shown a toast to tell them the anchor has been generated and copied.
The anchor is displayed in the toast along with an edit button that will
open the same edition modal as previously, but it is now less
restrictive.
Part of https://github.com/odoo/odoo/pull/38959
maintask-2066614
task-2088270
This commit adds buttons to move sections up or down and to move columns
left or right, which is more user-friendly than drag-and-drop in some
cases.
Part of https://github.com/odoo/odoo/pull/38959
maintask-2066614
task-2088265
* website
Now snippet options can be defined as a button which can be placed next
to the clone and delete buttons, through a new "isTopOption" method.
This commit also review the buttons and title design and take advantage
of the feature to review the way snippets options are added in their
container (that code indeed contained useless part since 13.0).
Part of https://github.com/odoo/odoo/pull/38959
task-2066614
* web_editor, website_blog, mass_mailing
In preparation of the new left panel UI, remove all snippet options UI
icons as we do not want them anymore to simplify the UI.
Part of https://github.com/odoo/odoo/pull/38959
task-2066614
Before this change the manual taxes widget in the invoice form view was
broken for Argentinian invoices, with this change now the widget is
working.
It was broke because this method is used for the report/portal and
manual taxes in widget in the form view, and for Argentinian case
report/portal invoice should not discriminate some of the taxes depending og
the responsibility of the customer/issuer and the type of document
(example: Factura A, Factura B).
Also update the method in order to match the original one in odoo
account module and add missing group_id
closesodoo/odoo#40400
X-original-commit: 6260da7604b2a831668be42bf8745c53a09e8d16
Signed-off-by: Josse Colpaert <jco@openerp.com>
Install accounting and activate a new language. Under
Accounting>Settings>Terms and Conditions input something, save and then
click on the near lanuage button.
A popup will appear with only the possibility to close and save but with
no text.
This is because no row is fetched from the ir.translation table, because
the domain for the search is
```
['&',
['res_id', '=', None],
['name', '=like', 'res.config.settings,%'],
['name', '=', 'undefined']
]
```
* wrong res.id "None" instead of the correct one (1)
* wrong name pointing to somewhat related to 'res.config.settings'
(the field name is "res.company,invoice_terms")
* another wrong condition on name equal "undefined"
The domain is malformed because in
addons/web/static/src/js/views/basic/basic_controller.js
record.res_id is unset while record.res_ids is it. Rewriting res_id to
make sure the id is there fix the issue
Thanks to mart-e
opw-2091779
closesodoo/odoo#40394
X-original-commit: 20e84558de476c17fed73f7ea5a11989401bffaf
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Since stdnum.ar.cbu is not available in odoo saas enviroment because is
using an old version of stdnum package, we add a try exept in order to
catch this and manage the error properly which is raise an exception and
leave a message in the log telling the user that the cbu was not able to
validate.
closesodoo/odoo#40383
X-original-commit: 25d483fc3fc05fd47c72c3d96c02fed12b998b0d
Signed-off-by: Josse Colpaert <jco@openerp.com>
Create a pricelist item with a fixed price, e.g. 10.20. The amount is
displayed as 10.200....01.
To avoid this, we format the float correctly.
opw-2122622
closesodoo/odoo#40391
X-original-commit: 1edcab8c8caabeb5ebfec4bc6fcba1b5506f73ca
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The field `account_id` has been removed from the tax, it is not on the
repartition line.
opw-2121720
closesodoo/odoo#40370
X-original-commit: 537dd88aced8b181f921e0daa0bf146fee9366cb
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create Product A:
Routes: MTO and Manufacture
Manufacturing Lead Time: 20 days
- Create Product B:
Routes: MTO and Buy
Add a supplier with Delivery Lead Time: 10 days
- Create a BOM: 1 unit of B to produce 1 unit of A
- Create a SO for A, validate
A MO is created with a Deadline set at SO order date - 20 days => OK
A PO is created with order date set at SO order date - 10 days => Not
OK, it should be - 30 days.
In v13, the raw materials expected date is the order date.
In v12, this date is computed as: order date minus Manufacturing Lead
Time
However, in both versions the PO order date is computed as the raw
materials expected date minus Delivery Lead Time of the supplier.
This comes from a change in the semantic of 'Planned Date' and 'Planned
End Date'. In v13, the Manufacturing Lead Time is only taken into
account in the Deadline, while in v12 it was taken into account in the
Planned Date. However, the expected date of the raw materials still
relies on the latter, not on the Deadline.
In order to solve this, we apply the 'Manufacturing Lead Time' of the
product and the company to 'Planned Date', 'Planned End Date' and
'Deadline' when the MO is created. Note that the solution is still not
ideal in case no routing is set on the BOM since 'Planned Date' and
'Planned End Date' won't be updated later in the process.
opw-2118951
closesodoo/odoo#40360
X-original-commit: b523f991572e32e69c5f8000a21553191ca54773
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before that, when trying setting to None the tag_name of a tax report line whose tags were referenced by some move lines, a exception was raised, telling that some account.move.line objects still referenced an account.tag we were trying to delete. Removing the tags from db was legit (since we're removing the tag_name, we need to remove the tags that it generated), but first needed to remove all these tags from the account move lines linked to them.
closesodoo/odoo#40375
X-original-commit: 3eb5a3e947bb371f90c9f2357ff410816419bbb0
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When a call to init_models() fails, the post-init queue still contains
callables that refer to a soon-to-be-closed cursor. If one calls
init_models() in another request, the post-init process will inevitably
fail because it refers to closed cursors.
closesodoo/odoo#40379
X-original-commit: 33f87ffebaa1cb38e3ce8ce44c8b8b538b49e5b9
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Commit https://github.com/odoo/odoo/commit/f6bbc40fbe16ea5ab01ad03b8e1519c4e559bf6d
introduced a method to destroy all current editors to refresh them when
necessary... but forgot to empty the array that contains them.
In a 12.0 without custo, this is only slowing down the editor but in
master (or with custo) this makes the editor crash.
closesodoo/odoo#40372
X-original-commit: 2b5661937d9772b98c73f9f64aa419fec7676052
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The company_id field is present twice in the view.
Fixes#40328closesodoo/odoo#40353
X-original-commit: 8d5b25417eb890aed56c9f1365100aa061b9bd8c
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Create a tax of type "Fixed".
- Put some name in its 'Label on Invoices' field.
- Change the type to "group of taxes".
The view hides the field Label on Invoices, since it doesn't make sense
any more. However, it doesn't actually remove the label on invoices.
As a result in the taxes list you can still see the old label on invoice
information, this behaviour misleading.
We modify an existing onchange to avoid that unfortunate situation.
opw-2115984
closesodoo/odoo#40346
X-original-commit: 1aea26c72d451e13754e911a6bb74fff0e2578df
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Currently, if the first week day was Saturday the calendar week view
would possibly get the wrong week.
This is because current heuristic would get date of current week from 6
(Saturday) to 12 (Sunday).
Thus if we were:
- on Friday 14th, we would have a week day ranges: 15-21 (wrong)
- on Saturday 15th, we would have a week day ranges: 15-21 (ok)
- on Sunday 16th, we would have a week day ranges: 22-28 (wrong)
So it would only get the right range when getting range from saturday.
If a week:
- start on monday, the week range would only be wrong on sunday.
- start on sunday, the week range would always be alright.
Added test without the fix fail:
- CalendarView: Saturday week start week mode
The domain to search events in should be correct
(domain range 14-20 instead of correct 07-13 whilst the day was 12th)
- CalendarView: Monday week start week mode
The domain to search events in should be correct
(domain range 16-22 instead of correct 09-15 whilst the day was 15th)
opw-2091448
closes#40244closesodoo/odoo#40327
X-original-commit: 6c3d74846581d6c1bfc0c6e3a7104440515ddbc5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
jbm-odoo