The sales journal graph should show the cash-in forecast of invoices.
In order to do that we need to display residual amount to be received
based on the invoice due date.
The purchase journal graph should show the cash-out forecast from
invoices. In order to do that we need to display the residual amount to
be paid based on the invoice du date.
Was task: 1855081
Was PR #25344
When creating a journal entry manually, the value proposed as next line was not taken into consideration all existing lines.
Was PR #25298. Courtesy of Pieter Paulussen (Dynapps)
Previously, the use case where a cash basis tax and a regular one were combined on the same invoice line (for example) was not supported (technically, there's a single boolean for the tax exigibility of the sale/purchase line). Since it appears this is a real need, this have been improved in the generic tax report (in enterprise repo) in revision https://github.com/odoo/enterprise/commit/f7e33b8114d4d649551a155d0ca8cc4f43f1fc01 and this commit fixes the community side, to copy only the base line of the tax exigibile on payments in the cash basis move
Sale module has an option to show or hide discounts on order lines.
Pricelist also have a field to include the discount in the price or display the
full price strikethroughed.
Before this commit:
If the sale option was disabled, the pricelist option would be hidden, possibly
left enabled.
This will cause a strange behavior in frontend where user would still see the
strikethroughed price even if the sale module option was disabled.
Now:
If the sale option got disabled, we also disable the pricelist option
Closes#14741
Prevent the modification of a tax which is used in an opened POS
session. This avoids inconsistency between the payment and the order
accounting entries.
opw-1859092
Incoming email servers have an action_id field holding a server action to
run on newly created records. It comes from old implementation of mail
gateways in Odoo. Since then mail gateway has evolved. Incoming mail servers
are not linked to a unique model anymore. With aliases and automatic thread
creation mails can create records in various models.
As the server action is bound to a given model it causes issues. Either
we have to give back the result of the mail gateway processing to ensure
models match. Either we have to limit action_id to records created
using the "default model behavior" of incoming mail servers.
We choose to remove this field. Same result can be achieved with an
automated action running on create trigger. If exactly the same
behavior is intended the following rules should be applied
* add automated action with model linked to the one you want to
update depending on alias configuration and work flow;
* set trigger to create;
* set action as python;
* if it is necessary to be linked to the mail gateway, check in
record message_ids that there is a message with message_type
being 'email' meaning it has received an incoming email;
Using that heuristic migrating existing fetchmail action to server actions
should be quite straightforward and will give more flexibility.
This commit is linked to task ID 58641. Closes#23621 .
When manually registering a time on a Work Order, an error is raised
because of an incorrect value for `workcenter_id`.
The field is added in the view.
opw-1851766
- Stripe.js was limited to only a few pages, which means, if you tried to
implement a new payment route it would never work without modifying
stripe.js to support the new case.
This commit allows stripe.js to be generic and work with any page.
There exists two actions for the same mode
The mrp_production_report action is used for the graph and pivot.
The reporting view does not need a form view, which can be displayed in the
operation action
Closes#25239
The action action_pos_config_pos is to configure the PoS config record.
No need to display a kanban as to launch a new PoS
action_pos_config_kanban is the one that display the kanban view
Closes#25239
Before this commit, load_action and load_views were never resolved
in case of internet connection loss.
It's because the call is triggered by web.rpc direcly who uses
ajax.rpc without any response check.
Now the rpc response is checked in web.ajax.
Thereby all responses are handled whether they come from session.rpc
or rpc.query.
Plus, it was not the responsibility of the session to check the
rpc responses.
Steps to reproduce the issue:
(1) load_action:
- Go to the app switcher for the first time
- Force disconnected from the network
-> No notification appears and the user aren't notify
(2) load_views (mobile only):
- Go to Sales -> Quotation
(In this case, the first call is 'load_views' because we need to force
to load some views like kanban view)
- Force disconnected from the network
-> No notification appears and the user aren't notify
Note: It's now important to notify the user about connection loss
because a recent improvement in mobile app replaces the 'retry screen'
and lets the webclient handle connection issues by itself.
The single odoo mobile app is supposed to work with all databases
from 10.0.
Recently a ref() has been converted into a direct xml id match. As this
does not return a recordset but an ID, the .id that follows is not
necessary anymore.
In order to avoid the access error when trying to view a partner form
view we should hide the event count stat button for the users who don't have
access to it (must be event_user or event_manager to read this field).
Closes#25225
The controller /event/<model("event.event"):event>/registration/confirm
was broken since the portal user cannot read event.registration objects.
In 9.0 this was not an issue as we browsed and sudoed the
event.registration, but since in 10.0 this line disapeared so did the
sudo which this commit reintroduces.
This information does not add a real interesting value when dealing with jobs
as this is a concatenation of documents linked to the jobs and to applicants.
Computation is heavy and could lead to performance issues. We choose to therefore
not show the document count and keep the icon.
- Create a product with -4.0 Units in stock
- Set the Buy and MTO routes, assign a vendor
- Create a SO for 25 Units
- A PO of 25 Units is created => validate and receive products
- Check availability on the picking linked to the SO
Nothing is reserved, while 21 Units could be reserved.
opw-1850688
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
qdp-odoo