Force the quantity reserved on stock move line to be reserved to avoid
de-synchronisation with the reserved quantity on the quants.
Task : 2329116
X-original-commit: 08394c89407fba69b78ba1f82846501efd5c9c87
On the package level form view, stock move lines was hidden if the
package level is in draft state.
The state is set to draft when the package level contains no move lines.
This means removing the last move line should make disappear the one2many
widget. This is problematic if we want to add a new move line
after that.
Task : 2329116
X-original-commit: 12c96af6ab4efc3d4b885d4bc984e24683a18056
PURPOSE
Make various changes to the website.visitor views to improve readability and
ease marketing analysis.
SPECS
The changes include notably:
- Add/rename/move fields/filters elements
- Remove some unnecessary information or put it in optional="hide" in tree view
- Add website_id information (with the multi-website group)
- Slightly rework layouts (new widgets / spacing / images / buttons / ...)
- Move some technical information into the "debug mode"
LINKS
Task 2092302
ENT PR odoo/enterprise#14611
UPG PR odoo/upgrade#1902closesodoo/odoo#61417
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The `name` field is not required on the `payment.icon` model. Therefore,
in case the payment icon name is not set, a traceback is raised due to a
`False.lower()` statement.
opw-2409755
closesodoo/odoo#62646
X-original-commit: 54434a4fdd71b1e344255fb6f3e42d731ba91f3b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Create a BOM kit K with two components C1 and C2
Bug:
It was possible to set an operation on K
PS: Operation is not supported on BOM kit
opw:2393302
closesodoo/odoo#62455
X-original-commit: 2027721601890870e14b396ae4bb8b6c6dea1ac0
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Databases that already have issues are not able to fix the issues
because it is impossible to reset the items to draft in order to change
the date/sequence. Or do anything else, really.
By allowing to bypass the constraint before a certain date, users can
now edit problematic documents.
Disabling the constraint will however make it possible to entirely
break the sequences; use it with the lowest possible date.
closesodoo/odoo#62663
X-original-commit: a35d7e646d7ac419d09d5f97b2886eddc9dee0e0
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
Issue
- Install "Calendar" and "Studio" modules
- Go to Calendar app an open any event
- Switch to Studio mode
- Add a selection field X in the form then close Studio
- Go to list view and try group by X
Error message : "Grouping by X is not allowed."
Cause
`_get_public_fields` does not get custom fields created with studio.
Solution
Add custom fields to public fields.
opw-2402667
closesodoo/odoo#62640
X-original-commit: a2388931710e1043540bbf2de131d4783af17d0b
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Previously, in company form view, avatar was not clickable due to a
`block` div that was overlapping the avatar widget and preventing
clicking on it.
This commit fixes the issue by preventing the overlap and thus making
the image widget on company form clickable.
Note that another fix would be to remove `partner_gid` from the company
form view (it's already the case in 14.0).
In this case "oe_title" is directly followed by .o_form_view .oe_avatar
and a padding-right: 100px is applied:
.o_form_view .oe_avatar + .oe_title {
padding-right: 100px;
}
However, considering stable version, changing fields position
should be avoided.
Task Id: 2231950
closes odoo/odoo#62634
Pr: #53798
X-original-commit: 6e6847767b1c2ef741773a1a8a63cccbcf31e798
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Co-authored-by: D J <dja@odoo.com>
You may have inactive warehouses for some companies and then, when recreating missing warehouses, you try to create same warehouses for those companies, but you can't because there is an unique constraint.
closesodoo/odoo#62620
X-original-commit: 9b91f9d1bb41d05f445d745a9b8e5fa63edaf2a9
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
search_utils only allows to filter on last 3 months, in
spreadsheet we want to be able to filter on all the months
therfore we construct the datedomain manually and we need
the function constructDateRange to be able to do so.
task-id:2340623
closesodoo/odoo#62580
Related: odoo/enterprise#15042
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
In 13.0, create a statement line and process it by creating a custom journal item in any reconcile account.
At this point, a journal entry has been created and is linked to both a payment and a statement line.
Migrate to 14.0.
Now, try to reconcile manually the custom journal item with anything. Because the matching number is written on the line, it triggers the synchronization between the payment and the entry but it fails because the manual entry doesn't really look a valid payment.
closesodoo/odoo#62621
X-original-commit: 962195d85aa1f2fedb0647a5cd454740c1322281
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Create a automated action on deletion that send an email, delete a
related record. The email is not sent.
Email are linked to their chatter message, when the later is deleted the
former is deleted in cascade too. This is a known limitation of the mail
model.
closesodoo/odoo#62616
Task: 2151519
X-original-commit: f8904eb19d82d1d255c1ef091d1e47e0e016a62f
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Issue
- Install Sales
- In Sales > Configuration > Settings -> Enable "Sale Warnings"
- Go to Sales > Orders > Customers
- Pick a customer/company
- Go in Edit mode and go to "Internal Notes" tab
- Switch "Warning on the Sales Order" from "No Message" to "Warning" and add any warning message then save
- Press the "$ X Sales" smart button
- Create a new Quotation
- Validate the warning message
- Go back to the previous menu (using the breadcrumb) or save the quotation
- Create a new quotation
The quotation form editor does not appear.
Cause
If we use the breadcrumb (or save then create), it will call the `_reload` function
(instead of `load` when the form view hasn't been opened yet).
In this case, creating a new record, it will call `_makeDefaultRecord` without
setting `allowWarning` param to true (like it is done in the ref. commit bellow).
Solution
Set `allowWarning` param to true before calling `_makeDefaultRecord`.
related commit : https://github.com/odoo/odoo/commit/a41db9a2cf410bb233b021651a5633180eaddf18
opw-2374857
closesodoo/odoo#62608
X-original-commit: d5b5e7c8490e8de9e56f16cdef640dd733163175
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
This rule was generating a lot of noise for very little gain.
closesodoo/odoo#62611
X-original-commit: 1557a648d96bfa725aa7bfa44773e6bb92d41112
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
- Multi-warehouse + Multi-company setup
- Create Company A with warehouse and 1-step delivery
- Create Company B with warehouse and 1-step delivery
- Switch to Company A: Set Logistics route on product category
All/Saleable : 1-step delivery
- Switch to Company B: Set Logistics route on product category
All/Saleable : 1-step delivery
- Switch to Company A, make sure Company B is turned-off
- Create new product and set category to All/Saleable
- Save product
Multi-company error is coming.
This is due to the field `route_from_categ_ids` which is a related, and
therefore fetched as `sudo` by default:
https://github.com/odoo/odoo/blob/f0330d92b31bdae4637ae0c26f40ee07282ab449/odoo/fields.py#L368
Actually, the field doesn't seem to be useful since it is only used in a
view.
Fixes#58357
opw-2390983
closesodoo/odoo#62609
X-original-commit: b68b45d5105a4d797da12ee6a5df6162b52b2d61
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps:
- Install Contacts
- Have Multi-Companies enabled
- Go to a Contact of type "Company"
- Click "Sales & Purchases"
- Assign it the company you're on
- Save and Edit again
- Remove the assigned company
- Go to a contact of type "Individual" linked to this company
- Click "Sales & Purchases"
Bug:
The company has not been deleted on the linked Individual
Explanation:
When we delete the company of a contact, the value of `vals.get('company_id')` is `False`.
This is why it didn't enter the propagation process.
This fix makes sure we can still remove a company from a contact linked to a user.
Related: https://github.com/odoo/odoo/pull/62418
opw:2391464
closesodoo/odoo#62591
X-original-commit: 59413ad88a97b3221526c2b560178a0f94ddee05
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
This commit cleans the default_* keys of the context before creating mail.mails
and mail.notifications when notifying the record by email.
Without this change, there can be a collision when the ORM tries to compute
default values for the state field (for example):
- Model "A" has a 'state' field ;
- Create an action that redirects to model "A" form view, setting some default
values in the context such as {'default_state': 'done'} ;
- Model "A" has an inherit on 'mail.thread' and a 'user_id' field to set a
responsible user ;
- Model "A" record is created with a responsible user, who is automatically
notified by email that the record "has been assigned to him" ;
(see mail_thread#_message_auto_subscribe_notify)
- A 'mail.mail' is in turn created ;
- The 'mail.mail' model ALSO has a 'state' field, and the context is propagated
so the ORM will try to assign 'done' to that field, which is an incorrect
value ;
- -> Crash.
If we ensure that the default_* keys are cleaned from the context, the default
values computation of the mail.mail record will not be affected and everything
works fine.
A test was added to ensure this behavior.
Task 2393259
closesodoo/odoo#62589
X-original-commit: 6b6e546ac95d9acb2964121dd52aa2896d31bc33
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
We provide a new helper class to help redact x2many commands for create
and write methods. To ensure best compatibility with the xmlrpc layer we
do not change the protocole, the commands are still 3-elements tuples
where the first element is still an integer in between 0 and 6. The
helper class provide the cannonical constants and static methods to ease
working with the commands. The new helper class is also available in QWeb.
Developers are encouraged to transition their code so it uses this new
helper class.
Task: 2366606
This commit fixes the step trigger:
'#o_website_links_link_tracker_form
#generated_tracked_link:contains("/r/")' that was taking too long
because of a call to _get_title_from_url happening during the creation
of a 'link.tracker'.
Before this commit the automated tests of website_links did trigger an
http request on the 'contactus' page which sometimes took too long to
respond and reached the test failure timeout.
After this commit the information obtained from this request is
hard-coded to avoid the unpredictable timing of the test.
This commit is a manual port of #62479.
task-2397724
closesodoo/odoo#62582
X-original-commit: db3296c034fe4c82d19580418fd5cdecdf578395
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
From python code, import a module class and print one of its field, it
shows garbage because the `model_name` and `name` fields are None. We
provide a default str/repr of the field.
closesodoo/odoo#46996
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This commit is mainly a revert to 13 functionalities in project_*
modules as functional changes introduced in 14 do not seem to be well
accepted by users.
Details:
- sale_timesheet: rename 'Ordered quantities' service_policy into 'Prepaid' project, sale_project, sale_timesheet: refactor task form view
- sale_timesheet: modify sale_line_employee_ids many2one widget on project form
- sale_timesheet: add link between ticket and sale order
- sale_timesheet: remove the option 'link to an existing SOL'
- sale_timesheet: remove the warning messages in project.task
- sale_timesheet: reword labels in customer_type and pricing
- sale_timesheet: adapt timesheet section on invoices in portal
- sale_timesheet: add timesheet section on orders in portal
- sale_timesheet: remove employee rate related warning on projects in Kanban view
- sale_timesheet: update sale_line_id of all the not invoiced timesheets accordingly to the employee mappings
- sale_timesheet: timesheet entries for employees that have no mapped SOL in project get the sol of the task or project
task-2388500
closesodoo/odoo#62568
Related: odoo/enterprise#15040
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The table picker was hard to use because its container scrolls instead of letting it overflow.
closesodoo/odoo#61783
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Behavior prior to the fix:
- when adding a filter on "Quantity < 0" (or > 0) on the forecast
inventory report the quantity reported becomes incorrect: for example if
there is a restock on Tuesday and a shipment on Friday that drives the
forecasted quantity into a negative, the forecasted inventory report
instead reports a negative quantity on Monday.
- the problem occurs because the view the report is based on is built
using positive and negative entries that are supposed to cancel each
other when accounting for stock items (quant). This way the quantity is
reported as 0 before the quant is moved in the inventory (there is a
positive entry for the quant, and a negative entry for the move up to
the move effective date). But when a filter on quantity is placed the
"cancelling" entries are not loaded and the report ends up with just the
negative value
Behavior after the fix:
- the quantities are reported as expected: with a negative on Friday,
and 0 on the days before
- to achieve this the view was modified to perform the grouping of
forecast entries inside of the view. This way we have one row per
product / day / state and we don't risk selecting only part of the
report.
- as the view is only read in aggregate there will not be any visible
changes to its consumers
opw-2379098
closesodoo/odoo#62574
X-original-commit: c16d4b5e7b9181c2c792f595a117de10510d45be
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
During the accounting tour, users are invited to upload one of their
bill, send one by mail, or use a sample bill.
For the last one, the returned action which opens a list view with the
new move does not have the correct context, which makes clicking on
'create' launch the creation of a journal entry and not a vendor bill.
This will make sure the context is correctly set in this case.
task id #2368810closesodoo/odoo#62332
X-original-commit: 3df9da9a712e719812b14085a4020e8a78db656a
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
In order to avoid eventual futur issues, this PR add a filter on the
journal field of journal entries to only allow selecting misc journals
task id #2371198closesodoo/odoo#62331
X-original-commit: 1b273d4c11e3e8d8583de302b71b2522a71f4d1d
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The kanban quick create is meant to stay open if a click event is triggered
within a modal, which was working for most cases before this commit.
However, there are some specific tricky cases when the behavior is incorrect.
Issues were mainly observed when using the many2one widget inside a quick
create card.
When typing something into a many2one widget and then focusing out of it, the
widget has a built in feature that asks the user if he wants to create the
record (based on options and necessary create rights).
This implies to open a modal asking the user to create or discard his input.
When you combine a many2one widget IN a kanban quick create card, then type
something in the many2one and click outside of the quick create, it triggers
BOTH the focus out event of the many2one and the click event of the kanban
quick create that verifies if it should be closed.
This click event creates a race condition but the following behavior happens
most of the times:
- The many2one 'focusout' is triggered first, creating the modal to confirm
record creation (see FieldMany2One#_onInputFocusout) ;
- The click event is registered second, triggering the quick create check to
see if it should be discarded (see RecordQuickCreate#_onWindowClicked) ;
- The click is technically registered outside of the modal since the modal was
not created yet. This behavior differs a bit between browsers:
- On Firefox the click event correctly targets the actual element that was
clicked (ex: another kanban card) ;
- On Chrome it varies between the actual element (same as Firefox) and
sometimes the raw 'body' element.
- The quick create card will then incorrectly consider the click as outside of
any condition to keep itself open and will close and destroy itself ;
- Which in turn destroys the FieldMany2One and the record creation modal ;
- (If you look carefully on the screen you can see a slight flicker when that
happens).
During all my testing, only one condition will stay consistent when focusing
out of the FieldMany2One by clicking somewhere else: the body element will
always have the "modal-open" class by the time the click event is triggered in
the RecordQuickCreate.
This is why relying on the condition that an element exists with the
"modal-open" class to avoid closing the quick create card provides reliable
results and seems to suit all necessary conditions and behaviors.
Task 2388450
closesodoo/odoo#62561
X-original-commit: 4930871701da2e2792e73ae3941f336046876f0e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
In the 12.3 editor revert, the handler for the getRecordInfo event was
removed, but the code that triggered this event was forgotten and now
doesn't do anything. This commit removes this dead code.
closesodoo/odoo#49126
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit fixes two bugs, the first one is a reinstall bug that
happens whenever the modules `payment` or `payment_test` are uninstalled
then reinstalled and the second one is a bug in which for some payment
acquirers, a journal is never created.
For the first bug, the problem is that when uninstalling the
aforementioned modules, the journals linked to each provider are not
deleted (which is ok from a business POV) and thus when reinstalling
said modules we simply recreate new journals, but journals have a
unicity constraint on (name, code, company_id), therefore the
re-creation of these journals will most likely fail.
This bug doesn't happen with other payment_* modules because all *main*
acquirers are defined in the payment module, except for payment_test
that defines its own acquirer (thus the fact that it fails to reinstall
too).
The solution chosen is to try to force the creation of the journals,
even if it may fail, within a try/except block: if it does fail, we
simply do a lookup for matching (name, code, company_id) and assign
whatever we find to the acquirer's journal_id. This approach was chosen
because the most common case is that of an install (journal creation),
so checking for existing journals first would make the most common case
less performant.
For the second bug, the part of the code that creates journals for
providers being installed made a false assumption: To find the acquirers
for which to create journals, it would gather the name of the
acquirer/provider from the module name of the modules being installed
(or that were already installed) and would compare them to existing
acquirers whose provider would match the names extracted from the module
name. However, not all payment_ modules contain the actual name of the
provider in the module name! payment_ingenico is one such case, while
the module name contains ingenico, the technical name for the provider
is 'ogone', meaning that the heuristic would never find an existing
acquirer with provider set to 'ingenico', therefore no journal would be
created for that specific payment provider.
The fix is trivial, payment.acquirer has related fields that point to
the modules that implement each provider, meaning that one can simply
check for all payment.acquirer whose module_state is 'to_install' or
'installed'.
This bug does not happen in v12 because when v12 was released ogone was
still ogone and not ingenico, and all payment acquirers actually
followed the convention of module name == provider name, but for
simplicity's sake we keep this change for v12 too since it's in the same
scope as for the first bug and the code is cleaner anyway.
closesodoo/odoo#62563
X-original-commit: 0b70f188ca441d6cf53b2ef63f4856239bbee8e4
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
What are the steps to reproduce your issue ?
1. Install "website_sale_comparison"
2. Create a product with only one variant with one attribut
3. Click on "Go to website" smart button
4. Enable "Customize/List View Variant"
5. Click on "Compare" button
What is currently happening ?
Nothing
What are you expecting to happen ?
Add product to the comparison list
Why is this happening ?
Because the product has just one variant and attribut so odoo don't
display it on the product page. The system cannot find the ids as
they are not on the page
How to fix the bug ?
Specify the product id in this case
opw-2377711
https://www.odoo.com/web#id=2377711&action=4043&model=project.task&view_type=form&cids=1&menu_id=4720closesodoo/odoo#62559
X-original-commit: 7ce7452c246ac97dcd5afeee3bd1906ecf9c82b0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
Reproduce:
* On a fresh db, create a payment
* Change the date to another month
* Validate
Issue:
* The name is computed before creation because it is the first of
journal/period.
* It is not visible
* It is given to the create vals of the move_id, so it is not correctly
recomputed
* The sequence/name are not in sync.
opw-2390747
closesodoo/odoo#62554
X-original-commit: 3a8247f603a02a05173ef917f9f07189ff5e01db
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
In some situation, the overlay does not reappear after disappearing.
Steps to reproduce:
1. add a title
2. add a few elements between title and footer so you can scroll title out of view
3. click title
4. scroll it out of view
5. click footer
6. scroll back up
7. click title
-> overlay is not reappearing[FIX]
Now overlay should not do that anymore.
closesodoo/odoo#62547
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When generating an efaktur, an error is raised
To reproduce the error:
(Use empty DB)
1. Set the company's country to Indonesia
2. Install Accounting (account_accountant)
3. Accounting > Customers > e-Faktur
4. Create & Save
5. Accounting > Customers > Customers
6. Create a customer
- Set country to Indonesia
- Add a TVA number
7. Accounting > Customers > Invoices
8. Create one for this customer
- Add a product
9. Save & Confirm
10. In Action, "Download e-faktur"
=> An error is raised.
OPW-2387843
closesodoo/odoo#62544
X-original-commit: 978e1168dddabebc31076eaebb5e20739bed4147
Signed-off-by: adwid <adwid@users.noreply.github.com>
William Henrotin