Before this change, the apikeys' ``_check_credentials`` override would
hard-check the ``'interactive'`` key. This turns out to be less than
ideal for compatibility with older code which might not properly
forward the environment (or might call ``_check_credentials`` from a
non-override and pass in an empty env) as it straight crashes.
Update the override to assume an interactive login if the information
is missing (as that seems like the more secure option: it ignores
apikeys and takes 2FA in account if enabled). Also trigger a warning
if the key was missing from the environment, such that the maintainer
hopefully takes a look at the issue.
Also allow a ``user_agent_env`` of ``None``, this will also trigger
the warning so seems OK.
closesodoo/odoo#62683
X-original-commit: ee2625a9311f308b9df3fc160dc5c9fe4cc5a497
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The copyright part of the footer could be edited but not saved.
Now it can be saved.
closesodoo/odoo#62614
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The sign of tax tags sometimes could get inverted explicitly. It typically happened for misc operations, so :
- manual entries
- CABA entries
- writeoffs created from the reconciliation widget
We had to do things this way in stable to fix those use cases, but it's not ideal, as the tags shown to the user were inverted, so it was a bit confusing, as one would have expected to see the exact same tags as on tax configuration.
We fix that by using a boolean field on account.move.line telling whether or not the sign must be inverted. This allows keeping the same tags as in the tax config, and simplifies the computation of the tax report's multiplicator, making the overall model more intuitive for both user and developper.
Task 2363287
closesodoo/odoo#62536
Related: odoo/enterprise#15031
Related: odoo/upgrade#1983
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Currently stock moves are auto-assigned (i.e. reserve free stock) both
when the scheduler is run and when a corresponding stock move that can
assign a move is completed. This strictness was causing issues for
prioritization of moves to assign, for example a picking with a
scheduled_date far in the future could automatically reserve all stock
if it was created before another picking that an immediate
scheduled_date. To ease this, an extra setting has been added to
stock.picking.type to let users choose how reservations should occur for
moves assigned to that picking_type (or picking with that picking_type)
when the move is already confirmed:
1. 'at_confirm' = automatically when new stock becomes available or
when the scheduler is triggered.
2. 'manual' = user must always manually click "Check Availability"
button (scheduler will no longer reserve).
3. 'by_date' = automatically when new stock becomes available or when
the scheduler is run within the move's reservation_date.
'by_date' has an extra option of # days before the move's scheduled
date that affects the move.reservation_date.
Additionally, because this new feature overlaps with the `procurement_jit` module's functionality, we remove the module and ensure its logic is reproduced directly in `sale_stock`.
Task: 2359317
Upgrade PR: odoo/upgrade#1868
ENT PR: odoo/enterprise#15050
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#60300
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Due to accounting custom setupclass user in environment is not admin but a
custom user having only accountant rights. This is hidden in accounting
override that changes test user and mix data creation and ACLs tests.
Current tests in sale crash when a flush is involved during data creation
as test user (accounting) has no rights to create users.
In this commit we fix locally sale data creation as fixing accounting
test structure is out of scope compared to this task.
Spotted when working on task ID-2086889
closesodoo/odoo#62672
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to avoid the use of sets in convert wizard. This set
is used to compute ids of leads to merge and to convert. Using a set make order
impossible to predict. Using lists allows to have reproducible tests notably.
Spotted when working on task ID-2086889
- Activate Anglo-Saxon accounting
- Set a foreign currency rate to 2.0
- Create a product A:
Inventory Valuation: 'Automated'
Costing Method: 'Standard Price'
Cost: 10.0
Public Price: 100.0
- Create an invoice in foreign currency
- Add 1 unit of A => the total amount is 200.0
- Confirm the invoice
The Amount Due is 100.0 instead of 200.0.
This happens because the Anglo-Saxon lines have the company currency,
while the other lines have the foreign currency. Because of this, the
`_compute_amount` method considers the move as multi-currency to compute
the various amount. However, the Anglo-Saxon lines should be neglected.
This happens from 14.0 because all lines have a currency. In previous
versions, lines in the company currency didn't have the `currency_id`
set.
opw-2390107
closesodoo/odoo#62657
X-original-commit: 9e1aec7873a935b287b4b3c5dbc2688acee5422a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit adds a footer on the package level form view to close it
automatically on button press.
Task : 2329116
closesodoo/odoo#62625
X-original-commit: a3296b46d35ef42e601e4c9c7b8d7a3206ab2998
Related: odoo/enterprise#15051
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Instead of having a module handle the procurement_jit, we now
incorporate it directly within sale_stock._action_launch_stock_rule and
make it dependent on the new stock.picking.type reservation_method option
rather than applying to all deliveries.
Note that only picking scheduler trigger has been moved to sale_stock,
since the action_assign portion of its moves are now handled directly in
stock.move.
Also we add a new test to ensure new reservation_method logic works
as expected with sale orders.
Task: 2359317
Upgrade PR: odoo/upgrade#1868
Currently stock moves are auto-assigned (i.e. reserve free stock) both
when the scheduler is run and when a corresponding stock move that can
assign a move is completed. This strictness was causing issues for
prioritization of moves to assign, for example a picking with a
scheduled_date far in the future could automatically reserve all stock
if it was created before another picking that an immediate
scheduled_date. To ease this, an extra setting has been added to
stock.picking.type to let users choose how reservations should occur for
moves assigned to that picking_type (or picking with that picking_type):
1. 'at_confirm' = automatically when:
- stock is available when the move's associated picking/MO is
confirmed,
- when new stock becomes available,
- when the scheduler is triggered (+ stock available).
2. 'manual' = user must always manually click "Check Availability"
button (scheduler will no longer reserve).
3. 'by_date' = automatically when within the move's reservation_date
and:
- stock is available when the move's associated picking/MO is
confirmed,
- new stock becomes available when move is already confirmed, or
- the scheduler is run (+ stock is available).
'by_date' has an extra option of # days before the move's scheduled
date that affects the move.reservation_date.
Task: 2359317
Upgrade PR: odoo/upgrade#1868
ENT PR: odoo/enterprise#15050
Since 29d8fc091a, stock moves in immediate transfers are automatically
assigned. In case of configuration implying to show details action, new
moves disappear in stock picking
Task : 2329116
X-original-commit: 0d3f32988a862bbf13fcfbad37cce903ab4e9d60
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>
Xavier Morel