account: the field was present twice in the view
purchase: was not using the right group, same as c9e8ec50ca1c
Fixesodoo/odoo#35073closesodoo/odoo#62910
X-original-commit: c3f0d0387f2cab7e45cd298858038be25e113185
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In 376891294 the default purchase.order view tree was changed to have
different view with dashboard.
But the current view referenced:
('parent.state', 'not in', ('purchase', 'done'))
which seems incorrect because an x2many view towards purchase.order
could currently only be used for purchase.requisition (doesn't have
purchase/done as state value) and stock.production.lot (doesn't have
state field) or a customization that might not have state field.
With this change, we copy what there was originally on this field.
opw-2381767
closes#62903closesodoo/odoo#62964
X-original-commit: 4628675caf37c1699d8c25fe2ff6ef8b7bbc72a0
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The creation of a Stock Valuation Layer is useless in case of a
Consumable product. At best it is useless, at worst it causes
inconsistencies when the user switch from a Consumable to a Storable
type.
closesodoo/odoo#62936
X-original-commit: 7e9d052beabe15d932e5d403f8ca2f4837c7d24f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Changing a product type from Consumable to Storable usually gives
unexpected results once some stock movements have been performed
(negative inventory, wrong valuation...).
While it should remain possible to do it (as long as the user knows what
he is doing), it is worth pointing the fact that unexpected results
are... to be expected.
To do so, we raise a non-blocking warning.
X-original-commit: 383b12977062cacc6ff0f553d7012029268be1ec
Issue:
The `_update_available_quantity` will flush the all environment due to
the savepoint (at each call). When we working with the package,
it becomes bottleneck due to the `_compute_package_info`. Indeed,
it computes two compute store field (`location_id` and `company_id`) and
depends of multiple field of related quants `quants_ids.xxx`. It means
that each time we enter/exit in the savepoint to update quants, this
compute will be execute (because of flush + compute_store).
Solution:
Avoid flushing when enter in the savepoint of
`_update_available_quantity` (`flush=False`)
Performance gain:
To validate a Delivery with 1000 move lines with package (source and
dest):
- Without patch: +- 120 sec
- With patch: +- 17 sec
opw-2371161
closesodoo/odoo#62841
X-original-commit: b2d57323caf9f7fe47c4fe9ac26b0e955d9987b9
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When a picking contains a lot (> 10000) of stock move line, the time
to open the picking become a issue (for 50000 sml, +- 6.5 sec) because of the
`_compute_has_packages`. Use a search with a limit=1 to avoid fetching
all `stock.move.line` with `result_package_id`
(for 50000 sml, +- 2.5 sec).
opw-2371161
X-original-commit: e78ca55997dfbf13c0798c1f59408450071e1452
When there are a lot of stock move line related to a stock move
(> 50000), the `_compute_lot_ids` become a time issue (for 50000 sml,
+- 3 sec).
Use a read_group to increase the performance (for 50000 sml, +- 1.2 sec)
opw-2371161
X-original-commit: b79364910e94bbb0216d3cb682a3c4550713e134
Before this commit, refresh the forecast report can lead to error if
this report refer to a product variant (`product.product`).
As it lost to which model the report is supposed to refer, it take the
one by default (`product.template`) which can lead to error (display a
traceback if the ID doesn't exist or display the report for another
product if the ID exists).
How to reproduce:
Open the Forecasted Report for a `product.product` (from the stat button
or from the `sale.order.line` widget for example) then refresh the page.
task-2362313
issue #59924closesodoo/odoo#62668
X-original-commit: 5b07432af890794742697641a593fc649630316f
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
`setSelectionRange()` on Safari has side-effect to focusing the
input element, which is not the case in Chrome and Firefox.
Task-2410311
closesodoo/odoo#62886
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
RATIONALE
Events often have sponsors displayed on their front page. This should be
a real standalone feature of Online Event application. However currently it
cannot be used without tracks managements
PURPOSE
Purpose of this task is to allow to use and display sponsors on an Event front
page without using tracks. Moreover online and chat capabilities should be
part of a sponsor feature, located within website_event_exhibitor module.
SPECIFICATIONS
Move everything related to event.sponsor model from website_event_track
to website_event_exhibitor. Functionally feature should be the same as
before except that we should be able to configure and display sponsors
directly with website_event_exhibitor application without using tracks.
Website_event_exhibitor should also define the sponsor template used to
display sponsors below an event.
Merge website_event_track_exhibitor into website_event_exhibitor and remove
dependency on website_event_track. That way all features related to sponsors
are now located within website_event_exhibitor
SPECIFICATIONS: CSS
Purpose of this commit is simply to try to reorganize css currently split across
two files without any real clear difference between those files. We now
have 3 files: a common for all event-related webpages, a file for event list
view (displaying events in frontend) and event page view (display a specific
event details in frontend).
Sponsor specific CSS is moved into website_event_exhibitor so that it contains
its own specific CSS
SPECIFICATIONS: SPONSOR MANAGEMENT
Introduce a new category field containing sponsor, exhibitor or online
exhibitor. Meaning is
* sponsor: display as a sponsor (sponsor cards at the bottom of events).
No publish management is done at sponsor level: a sponsor is always
displayed in the sponsor widget;
* exhibitor: display as a sponsor in sponsor cards. An exhibitor is also
displayed in /exhibitors page and allow publish management. Also allow
to edit description as it is used in front-end page view of exhibitor;
* online exhibitor: same as exhibitor and allow to configure jitsi (online)
capabilities. It also activates display of jitsi in frontend;
An exhibitor would be a sponsor that has a physical stand but no online
support. Online exhibitors hold a jitsi room to chat with online visitors.
Also add field in kanban view.
In frontend rename "Connect" to "More info" when exhibitor has no online
capabilities. That way we don't connect with an exhibitor that has only
a published description.
SPECIFIATIONS: B2B
Clearly separate sponsorship levels (gold, silver) from exhibitor type
(sponsor, exhibitor, online). Propagate this new naming through views and
menus as well as frontend filters.
Reword sponsor form view, notably to have a clean 2 column display. Left
column holds customer related information. Right column holds event and
sponsorship information.
SPECIFICATIONS: FIXES
Apply various fixes
* fix unpublished badge on exhibitor cards;
* fix display of sponsor content when image overflows;
* improve display sidebar flag / description columns in page view;
* show opening hours in exhibitor frontend page;
LINKS
Task ID-2326433
COM PR odoo/odoo#61781
ENT PR odoo/enterprise#14752
UPG PR odoo/upgrade#1931
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This is a minor issue, but determinism is better than non-determinism.
closesodoo/odoo#62904
X-original-commit: 1b0869554d8755f8fdeb73dd2aa2ae7426522e84
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
In case a user has installed a module where the code becomes unavailable or during migration a module was removed and needs to be removed after migration it is impossible to uninstall the module from a database still holding the fields or the models.
In order to disable prefetch based on information from the database it is needed that the module and models of the unavailable module are initialized with related fields and models.
closesodoo/odoo#62895
X-original-commit: e4a1121e572d07cc720ede8c1b1116d4f1d7ae98
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Purpose
=======
The goal of this commit if double:
- Prevent employees to change the m2o address_home_id, that could lead
to future inconsistencies on future HR processes
- Allow the employee to modify it own private address, even if the
access is restricted to administrators for private addresses
closesodoo/odoo#62891
Taskid: 2412387
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
What are the steps to reproduce your issue?
1. Install "stock"
2. Go to Inventory/Inventory Overview/Internal Transfer
3. Create new record and set manually a date with year < 1000 like "0008-10-10 18:35:00"
4. Save
What is currently happening?
An error arises when saving the record, and it is then no longer
possible to reopen the records or any view containing it.
This also prevents us from correcting the date to no longer have the error
Why is this happening?
The root cause is an inconsistency in `strftime` for years < 1000 [1, 2]. To take it into
account, a zero-padding is needed in the DateTime parser.
How to fix the bug?
The missing padding is added.
However, such dates lead to problematic behaviors in Python:
```
DT_FORMAT = "%Y-%m-%d %H:%M:%S"
new_date = "0008-02-05 18:10:10"
datetime.strptime(
datetime.strptime(
new_date, DT_FORMAT
).strftime(DT_FORMAT),
DT_FORMAT
)
```
This raises:
```
ValueError: time data '8-02-05 18:10:10' does not match format '%Y-%m-%d %H:%M:%S'
```
As of today there was no reported business cases where dates with year < 1000 would be
necessary. Therefore, we limit the range to years >= 1000.
[1] https://bugs.python.org/issue13305
[2] https://docs.python.org/dev/library/datetime.html#strftime-strptime-behavior
opw-2408260
closesodoo/odoo#62889
X-original-commit: b873bda1e560bc49ab707aa238fdc962f23bc1e4
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
Previously, the check to see if a statement ending balance is the same as the computed balance was only done when moving from draft to posted which is wrong as people can modify the balance of posted statement programmatically which is the case when using online synchronization for example. Now perform that check at each change of state: draft->posted and posted->processed. Also the indication in the view to indicate that the balance was not the same was only displayed in draft, we removed that constraints as user should always see if there is a problem.
closesodoo/odoo#62879
X-original-commit: 69fc9b71e991983b5bcddc948ac4c3749e305a3f
Related: odoo/enterprise#15155
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Signed-off-by: Florian Gilbert <FlorianGilbert@users.noreply.github.com>
There is now two lists of attachments : first one with images and second
one with non-images. Attachment viewer allows to navigate through
previews of all viewable attachments in the order they're shown.
task-2272587
task-2401325
closesodoo/odoo#62719
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
SPECIFICATIONS
Currently finding information on opening hours of a sponsor is not easy.
If sponsor is online it jitsi is available in opening hours. This is quite
clear to the user. However an exhibitor that holds a physical stand but
no online presence does not have its opening hours displayed.
In addition to description field that may hold any relevant information we
now display opening hours after name of sponsor in its "About" section in
frontend page view.
LINKS
Task ID-2326433
COM PR #61781
ENT pr odoo/enterprise#14752
UPG PR odoo/upgrade#1931
SPECIFICATIONS
Currently depending on flag and sponsor type name left- and right- parts of
aside exhibitors may have different sizes. This leads to a stairway-like
display which is kind of ugly.
In this commit we use grid system to force having columns of same width.
LINKS
Task ID-2326433
COM PR #61781
ENT pr odoo/enterprise#14752
UPG PR odoo/upgrade#1931
SPECIFICATIONS
It sponsor image is higher than sponsor information, sponsor description is
moved on the right due to image. It leads to a strange display.
With this fix sponsor description begins below image, leading to a cleaner
display of sponsor data.
LINKS
Task ID-2326433
COM PR odoo/odoo#61781
ENT pr odoo/enterprise#14752
UPG PR odoo/upgrade#1931
SPECIFICATIONS
It is currently displayed at the bottom of the card with some strange opacity
leading to badge not being readable at all. It is now put under image like
unpublished events in /events page. It is also made readable.
LINKS
Task ID-2326433
COM PR odoo/odoo#61781
ENT pr odoo/enterprise#14752
UPG PR odoo/upgrade#1931
PURPOSE
Improve sponsor management, especially when dealing with publication at
sponsor level, exhibitor level, or exhibitor using chat (jitsi).
SPECIFICATIONS
Introduce a new category field containing sponsor, exhibitor or online
exhibitor. Meaning is
* sponsor: display as a sponsor (sponsor cards at the bottom of events).
No publish management is done at sponsor level: a sponsor is always
displayed in the sponsor widget;
* exhibitor: display as a sponsor in sponsor cards. An exhibitor is also
displayed in /exhibitors page and allow publish management. Also allow
to edit description as it is used in front-end page view of exhibitor;
* online exhibitor: same as exhibitor and allow to configure jitsi (online)
capabilities. It also activates display of jitsi in frontend;
An exhibitor would be a sponsor that has a physical stand but no online
support. Online exhibitors hold a jitsi room to chat with online visitors.
Also add field in kanban view.
In frontend rename "Connect" to "More info" when exhibitor has no online
capabilities. That way we don't connect with an exhibitor that has only
a published description.
SPECIFIATIONS: B2B
Clearly separate sponsorship levels (gold, silver) from exhibitor type
(sponsor, exhibitor, online). Propagate this new naming through views and
menus as well as frontend filters.
Reword sponsor form view, notably to have a clean 2 column display. Left
column holds customer related information. Right column holds event and
sponsorship information.
LINKS
Task ID-2326433
COM PR odoo/odoo#61781
ENT pr odoo/enterprise#14752
UPG PR odoo/upgrade#1931
RATIONALE
Events often have sponsors displayed on their front page. This should be
a real standalone feature of Online Event application. However currently it
cannot be used without tracks managements
PURPOSE
Purpose of this task is to allow to use and display sponsors on an Event front
page without using tracks. Moreover online and chat capabilities should be
part of a sponsor feature, located within website_event_exhibitor module.
SPECIFICATIONS
Merge website_event_track_exhibitor into website_event_exhibitor and remove
dependency on website_event_track. That way all features related to sponsors
are now located within website_event_exhibitor.
LINKS
Task ID-2326433
COM PR odoo/odoo#61781
ENT pr odoo/enterprise#14752
UPG PR odoo/upgrade#1931
PURPOSE
Purpose of this task is to allow to use and display sponsors on an Event front
page without using tracks. Moreover online and chat capabilities should be
part of a sponsor feature, located within website_event_exhibitor module.
SPECIFICATIONS
Purpose of this commit is simply to try to reorganize css currently splitted
in two files without any real clear difference between those files. We now
have 3 files: a common for all event-related webpages, a file for event list
view (displaying events in frontend) and event page view (display a sepcific
event details in frontend).
Sponsor specific CSS is moved into website_event_exhibitor so that it contains
its own specific CSS
LINKS
Task ID-2326433
COM PR odoo/odoo#61781
ENT pr odoo/enterprise#14752
UPG PR odoo/upgrade#19311
RATIONALE
Events often have sponsors displayed on their front page. This should be
a real standalone feature of Online Event application. However currently it
cannot be used without tracks managements
PURPOSE
Purpose of this task is to allow to use and display sponsors on an Event front
page without using tracks. Moreover online and chat capabilities should be
part of a sponsor feature, located within website_event_exhibitor module.
SPECIFICATIONS
Move everything related to event.sponsor model from website_event_track
to website_event_exhibitor. Functionally feature should be the same as
before except that we should be able to configure and display sponsors
directly with website_event_exhibitor application without using tracks.
Website_event_exhibitor should also define the sponsor template used to
display sponsors below an event.
LINKS
Task ID-2326433
COM PR odoo/odoo#61781
ENT pr odoo/enterprise#14752
UPG PR odoo/upgrade#1931
RATIONALE
Events often have sponsors displayed on their front page. This should be
a real standalone feature of Online Event application. However currently it
cannot be used without tracks managements
PURPOSE
Purpose of this task is to allow to use and display sponsors on an Event front
page without using tracks. Moreover online and chat capabilities should be
part of a sponsor feature, located within website_event_exhibitor module.
SPECIFICATIONS
Create a void module ``website_event_exhibitor`` that will soon host
* sponsor model from ``website_event_track``;
* all exhibitor feature from ``website_event_track_exhibitor``;
* without any dependency on tracks;
When installing website_event_exhibitor people will gain access to all features
related to sponsoring, from the simple cards to a complete jitsi-based chat
capability on frontend.
LINKS
Task ID-2326433
COM PR #61781
ENT pr odoo/enterprise#14752
UPG PR odoo/upgrade#1931
Before this commit, if extra products are added in a delivery generated
by a sale order, the added products will not be take in account to the
invoice. Now, the corresponding SO line will be created.
Also, the price for the SO lines added this way will be either 0 or the
product's sale price, depending of the product's invoicing policy.
task-2372938
closesodoo/odoo#62874
X-original-commit: 1f0835a9d01b46b5cc617756f854c25541b644a7
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
Commit 49b965eb1ec6a7ec6c07fa643cc6ae35ee8b5d91 introduced
`product_tmpl_ids` into the context for displaying kit components but
did not use it in the domain due to a missing `s`.
This commit adds the missing `s` in the domain.
closesodoo/odoo#62870
X-original-commit: aa135eb966810311837f4d446962850bb5aec82d
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
`mailing_list_id` is m2o field and this form is only used in
one2many field, so there is no point to display many2one field inside
form view of o2m.
closesodoo/odoo#51923
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Upon the first call to `onchange`, the `values` dict is filled with
default values. But the fields without a default are left unassigned.
This allows to compute fields when accessing them, but non-computed
fields will ask again for their default value, which is a waste of time
because we know they don't have one. This may even be a performance
issue on forms with many fields.
Fix this issue by completing `values` with falsy values, and consider
the fields with some initial value (given or default) as the assigned
ones for triggering onchanges. This explicitly triggers the computation
of fields that depend on fields with some initial value, without forcing
them to `False`.
Also avoid accessing x2many fields on the record in `snapshot.diff()`.
Enable the prefetching by simply putting the right value in cache.
closesodoo/odoo#62844
X-original-commit: 80c1dad6d9124da9459ce38d9e8c03e5c461c180
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit the existing tags list contained the unsaved newly
added tags.
After this commit the existing tags list does not contain the unsaved
newly added tags.
Fixes https://github.com/odoo/odoo/issues/62647closesodoo/odoo#62829
X-original-commit: 8520a3ef14dd1e79ace1dea70eebeffb4f21f0eb
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, the method who check if the user is in
multiwarehouse wasn't call when a warehouse is archived/unarchived.
closesodoo/odoo#62615
X-original-commit: 1ca34276e7684927d8628df9aa592fad7c1a5871
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This commit adds a pylint checker that will check every override of
`BaseModel.unlink` to verify that there are no raise statements within
the body of the method, if that is the case, an error will be raised.
closesodoo/odoo#58517
Related: odoo/enterprise#13557
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
With this commit, all instances of errors being raised inside
`BaseModel.unlink` overrides are moved into methods decorated with
`api.ondelete` which is safer.
With this commit, a new ORM api decorator is introduced:
`api.ondelete(*, at_uninstall)`.
This decorator is to be applied to Model methods that check for specific
business conditions when attempting to unlink a record via the
interface.
E.g. trying to unlink a validated journal entry
This decorator allows this logic to exist outside the `BaseModel.unlink`
method and is automatically bypassed when in uninstall mode, this means
that during an uninstall any and all data related to a module can and
will be removed easily and cleanly while still being able to apply
business logic to manual deletion of records.
This feature opens the gates to solving a very big problem with
uninstalls: records and tables that remain in a database despite the
relevant module being uninstalled, because if an override to unlink
raises an error, the data will never be deleted from the database.
Henceforth, overrides of unlink shall solely be used for data-cleaning
purposes, i.e. deletion or modification of data that is related to the
one currently being deleted but cannot be automatically deleted because
there are no proper SQL relations.
In certain very specific, low-level scenarios an unlink may be
overridden to raise an error, but this should only be done if you know
what the fuck you're doing, most of the time you'll want to resort to
`@api.ondelete`.
Note that this new decorator includes a keyword-only, required argument
called `at_uninstall`, in most business cases this argument shall be
False as this argument dictates whether or not this method should be
executed in the `unlink` call during uninstall. It should only be set to
True if you are certain of all the implications which most likely means
that the records of the model in which this ondelete function is defined
will NOT be removed during uninstall, they will forever linger in the DB
until manual intervention, this in turn can mean a wide range of
undefined problems due to crap left on the database.
Following commits will replace any `unlink` overrides that raise
business errors by methods decorated with `api.ondelete`, another commit
will introduce a pylint checker that will raise a warning any time that
an unlink override raises an error.
When you are configuring the picking type used in the point of sale to
not use existing lots and not create lots, the POS still ask you to
encode a lot for product tracked, and the picking created don't use
existing lots in stock because no reservation is made when a picking is
valaidated from point of sale.
As we want to reserve only in this specific case, we are now checking
the options on the picking type to reserve or not product tracked.
We are also not asking anymore for lot or serial number if picking type
is configured that way.
OPW-2377008
closesodoo/odoo#62857
X-original-commit: f9dd1d88d0d24914028464cc12b69ff0878346f8
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Before this commit, in case of Google Translate is enable, some content
can be wrapped in extra node.
Use currentTarget is more secure to get the right element clicked.
**Steps to reproduce:**
1. Add a website and multiple language
2. Create a page in 2 languages
3. Visit the website in Chrome and enable the translation by Google translate
4. Change the language and you should get an error similar to:
Error:
Uncaught TypeError: Cannot read property 'replace' of undefined
closesodoo/odoo#62849
X-original-commit: a2ebc05c83de305bc0323f2793ac06dbc15c63cd
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
After a migration, if the payment is using the bank account instead of the oustanding one, we shouldn't block the user in any case when checking the payment consistency.
For example, when writing the matching number on a journal item will trigger the check consistency on the payment. So, you are unable to reconcile any journal items until you replace the account by the outstanding.
closesodoo/odoo#62842
X-original-commit: 28bc59e794f15bf4f7de31e24f496e707ba639dc
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
