- Set a specific expense account on an expense product
- Send an email to the expense alias
The specific expense account is not used; a default account is used
instead.
opw-1838174
Do not try to keep the reservation when creating a backorder for two
reasons:
1) it doesn't make sense since the backordered move will only be
confirmed while it got some reserved move lines
2) with badly configured uom's rounding, it is possible that the
initial demand of the backorder is inferior to the now reserved
quantity
We also fix another "cannot unreserve more than available" cause that
could happen in the second case ; let's imagine in the second case that
the backordered quantity is 0.999, `_update_reserved_qty` will reserve
0.999 on the quants but do not create a move line as range (0, 0.999)
will not return anything.
We remove `test_split_1` as it tested a behavior we removed and add a
new test showing a new flow with what we fixed.
Please note that setting the rounding of unit to 1.0 would have
prevented all the issues here.
Followup of rev 383947646f
Let's say you have 6 units and you try to reserve a dozen while the
rounding of the dozen is 1.0. The previous commit correctly only allows
to reserve 12 units, and handle correctly forced quantities in other
compatible UOM, all that with extra moves/backoders.
But we missed an important issue: if now you have 12 units, you will
reserve them. If these 12 units are split across quants, i.e. some are
in another sublocations or are assigned a special lot_id, then we'll
again have rounding issue because the reservation was always expressed
in the move's uom while sometimes it is not possible to go back and
forth between the move uom and and the product's uom. In other word,
we'll reserve 12 times 0 dozen and get stuck at the next step.
This patch now only reserve a quantity if the quantity is expressible in
the rounding's UOM. If this quantity is split across multiple move
lines, we'll make the move line reserved in the UOM of the quants if
necessary. We also do not apply the rounding down -> halfup dance if
`_update_reserved_quantity` is called with the force argument set as
True (meaning, in an mto scenario). The change in
`_prepare_move_line_vals` will make the move lines in the uom of the
qants and everything should be good. With the last change, we need to
adapt the test added by the previous patch, else we won't be able to
make a chain of 2 move moving producst tracked by serial number if the
rounding of the dozen is set at 1.0.
opw-1835186
opw-1835946
In order for the user to easily add the date of the events to his
calendar we need to facilitate the integration with Outlook/ Google
Calendar.
For this we add two buttons at the end of the subscription phase (one
for Google Calendar and one for Outlook [ics file download])
Task ID: 39315
Closes#21854
When computing the amount of the anglo saxon entry, if it's a vendor
bill only consider IN move, if it's a credit note only consider out move
(the returns).
opw-1819353
In order for the user to understand what the chat_input_placeholder
field means we should add a tooltip.
We should reorganize the fields in order to put them in logical order.
This commit is related to task 1837812.
Closes#24336
- Set up Paypal as described in
https://www.odoo.com/documentation/user/11.0/ecommerce/shopper_experience/paypal.html
- Buy a product on the eCommerce.
The vendor might receive an email mentioning that Instant Payment
Notifications (IPN) are failing.
When completing the paypent process with Paypal, 2 confirmations of the
transaction will occur. The first one is through the route
`/payment/paypal/dpn` (Payment Data Transfer (PDT)), which takes place
right after the payment validation. The second confirmation comes
through the route `/payment/paypal/ipn` (Instant Payment Notification
(IPN)), which might arise with some delay (and potentially being run
several times).
Both confirmations will trigger the method `_generate_and_pay_invoice`,
which can raise an error if no invoiceable line is found ('There is no
invoiceable line.' in `sale` module). In this case, we should log the
error and move forward instead of crashing and stopping the workflow.
More information on PDT and IPN at
https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNPDTAnAlternativetoIPN/
opw-1837196
Purpose
=======
Move some internal development into the standard solution.
Specification
=============
- Add a default value for 'acquisition_date'
- Make the license plate not required
- Display all the stages on the fleet.vehicle kanban view
- Remove the unicity constraint on the driver
- Order cars by plate, then by acquisition date
- Add an informative 'First Contract Date' field
- Add 'Next Activities' on vehicles
- Create a related contract when creating a new car
- Archive related contracts when archiving a vehicle
- Allow to search vehicles based on the driver name
- Set default values on model onchange
- Add subtype to track driver modifications
- Introduce fleet.vehicle.assignation.log model
- Add track_visibility='onchange' on some fields
- Rename purchaser_id from 'Contractor' to 'Driver'
- Modify slightly some fleet views
TASK ID: 1839868
1/ Remove 'odometer' from vehicle tree view
2/ Replace 'Activation Cost' by 'Driver' on contracts tree view
3/ Add fields to search on in contract search view
4/ Hide 'Renew Contract' button if in open state
5/ Move models menuitem from 'Configuration' to 'Vehicles'
1/ Use track_visibility instead of overriding write method on a fleet.vehicle
Instead of posting messages in the write method to notify that the record value
changes, use the attribute track_visibility='onchange' instead.
2/ Add track_visibility='onchange' on some fields
3/ Track visibility on 'recurring_cost_amount_depreciated'
Purpose
=======
Currently it's impossible to know who was driving a given car at a given time.
We have some piece of information like the immatriculation date of a vehicle
or the date of the first contract. But it's not enough.
This is problematic to solve a rather common issue:
- Who is gonna pay the fine for having exceeded the speed limit?
Specification
=============
Introduce a simple model fleet.vehicle.assignation.log, containing info about:
- The driver
- The vehicle
- The start Date
- The end Date
A simple button on the fleet vehicle should be sufficient to solve the issue.
We cannot generate data from the salary package as these dates can't be predicted
at the contract signature.
The goal of this field is to be able to keep the value of the first contract
even if it has been closed/deteled.
It could be used to compute the depreciation of the car.
In case of changing the quantity on hand of two variants of the same product,
the two message created will have the same name (the name of the
product.template).
Show the name of variant instead.
* Reconciliation
Change the way the reconciliation method was written to optimize performances.
Remove the "skip_full_reconcile_check" stuff that is more confusing than helping.
* Object creation
Remove the creation of tax_line from tax_ids in the account_move_line create method.
Remove a bunch of context that were invalidating the cache way too often
Was PR #21498
Was task 37976
In the wizard for payment several invoices with one payment, there was a
error when making the previous fix: 29c6c06de7.
The patch still worked because of a particularity of readonly and
related on account.payment but the check_amount_in_words would possibly
not be set when it should have.
opw-1839720
closes#24476
- When a quotation if viewed by a customer, a note is posted in the quotation's chatter saying "Quotation viewed by customer".
This is causes issues if the quotation is accessed without the access token and by a partner that do not have the rights to write on the model "sale.order".
To address this issue we provide to the "_message_post_helper" function the sale order's access token to bypass the accesses checks.
OPW-1839183
* when refunding an invoice/bill with the option 'modify', it now opens the draft document in form view (chatter reworked for more clarity)
* payments list views are now using filters instead of domain, so that user can easily find back any payments (also transfer that haven't their dedicated menuitem)
* when clicking on a ling to create a new payment from the dashboard, the form view is directly open instead of the list view
Was PR #23402. Was task 58392
Rev. 69c9500e recently added option 'keepSearchView' to doAction in
the ActionManager. When set to true, the searchview of the current
action is re-used by the executed action.
This caused issues with the dashboard, as the wrong action id was
used to save the current action to the dashboard (it was the one
of the action for which the searchview was instantiated, not the
one of the current action, executed with option keepSearchView set
to true). For instance, go to Website (in enterprise), in the
new dashboard (view) expand the graph view, try to add the graph
action to the dashboard (board).
Task 1835670.
When validating a delivery order with automated inventory,
some accounting moves are created.
Since an inventory user might not have accounting rights,
the validation of delivery orders might fail.
We simply had a sudo when in the internal method creating the move.
Moreover if the inventory valuation is set in FIFO,
the product price might be updated.
It might fail for lack of additional rights.
We add a sudo for this price update.
opw 1836761
When validating a delivery order, some stock moves might be merged by an
internal function, which thus might delete some stock moves.
Since an inventory user has no right to unlink stock moves,
the validation might fail.
We simply had a sudo when doing the unlink, since this is an external method.
opw 1836761
The copy-paste feature of summernote was messy and led most of the time
to breaking the template you were trying to edit. While it is difficult
to solve as it mostly comes from the lib itself and that the lib is in
a complicated state as Odoo had to overridde part of its internal code
for its own purposes, this commit hopes to solve the problem by updating
only the copy-paste feature to the latest summernote version.
Of course, as summernote changed a lot meanwhile, it was not possible to
just take the up-to-date summernote file. This commit refactores the
up-to-date summernote clipboard code so that it fits the old summernote
version Odoo is using.
Note: the main problems occurred while using Windows/Mac and not Linux.
opw-1837818
Commit 542201eed3 added the possibility to configure a set of countries for a
given payment acquirer.
Commit 194d52e8fd refactored the payment form, but forgot to take the country
into acount.
opw 1837819
- Create a message with 100k+ smileys
- Send it to a colleague you hate
- His (and your) web browser starts eating up all the memory
- Go cry to the technical guy because you can't use Odoo anymore.
On some browsers, like Chrome, the image rendering consumes a lot of
memory up to the point it makes it unusable.
opw-1831610
In firefox the range when doing CTRL+A is the first level content of the
contenteditable element, but this was not taken into account when
"remembering" the range after clicking on buttons or features of the
editor.
In chrome the selection begin with the first displayed element (so it
may not be a direct child of the editable and is taken into account in
the code).
opw-1824017
closes#24424
Since 1a58e108 (on 10.0 and over) parameters are no longer present when
logging sql queries.
This removes some of the usefulness of the feature, and this commit adds
them back.
Since mogrify returns a byte string in the database encoding, we decode
it using the corresponding python encoding.
opw-1839241
closes#24446
Having a different behavior from other apps present in the systray about
activities is not understandable.
Done after feedback from saas-11.3 internal testing phase. This commit is
linked to task ID 1838917.
Otherwise users that already exist when installing note module do not have
any default columns for note leading to an incoherent behavior, especially
with reminders.
Done after feedback from saas-11.3 internal testing phase. This commit is
linked to task ID 1838917.
Steps to reproduce:
-Create company A
-Create company B
-Admin user with both companies but currently in company B
-Create Demo user only with company B
-Create fiscal position A to company A
-Create fiscal position B to company B
-Create vendor with fiscal position A with company A and the same vendor with fiscal position B in company B
-Create product and add the vendor created before
-Set like Create a draft purchase order
-Logging with Demo user
-Create sale order with one sale order line with route make to order
-Validate sale order
Bug:
The purchase order created by sale order had the fiscal position company A.
Backport of this commit: 5bb6517072Closes#23561
opw:1825098
Here is the story of the problem: back in 10.0, everything *seemed*
fine with button rendering except it was very messy duplicated codes.
The system was still not consistent:
-> In Header, button with:
no class -> btn-default
btn-primary -> btn-default btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-default btn-link
oe_link -> btn-default oe_link
btn-danger -> btn-default btn-danger
some_class -> btn-default some_class
-> Not in header, button with:
no class -> no class
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> oe_link
btn-danger -> btn-danger
some_class -> some_class
So, outside the header, the system seemed to not process anything except
transforming the oe_highlight class. In the header, the btn-default was
always added, except if using the oe_highlight class. The style is fine
for those, except for .btn-default.btn-link and .btn-default.oe_link
where the link class has no effect (which is fine as header are not
supposed to contain links).
In 11.0, the new views were introduced alongside websitepocalypse. The
new system led to:
-> In Header, button with:
no class -> btn-default
btn-primary -> btn-default btn-primary
oe_highlight -> btn-default oe_highlight
btn-default -> btn-default
btn-link -> btn-default btn-link
oe_link -> btn-default oe_link
btn-danger -> btn-default btn-danger
some_class -> btn-default some_class
-> Not in header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> oe_highlight
btn-default -> btn-default
btn-link -> btn-link
oe_link -> oe_link
btn-danger -> btn-danger
some_class -> some_class
So, it worsened the header buttons by not processing the oe_highlight
class and adding the btn-default class in all cases. This is even
worse since in 11.0 .btn-default.btn-link do have a specific style and
thus not appear as .btn-default anymore. Those may be invisible "bugs"
though as .btn-link are not supposed to be in header and oe_highlight
is styled correctly in css. For buttons outside the header, a little
processing was added to add "btn-default" class for buttons which did
not specify a class (and oe_highlight is not processed anymore there
too).
In master, with the less2scss task, the system had to change again but
led this time to visible bugs:
-> In Header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> btn-link
btn-danger -> btn-danger
some_class -> some_class
-> Not in header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> btn-link
btn-danger -> btn-danger
some_class -> some_class
As you can see, the system is now the same for both header button and
normal buttons. The system is also better for all cases as it produce
only *one* *bootstrap* class for all cases. However, the problematic
case is the last one for header buttons: it did not receive the
btn-default class automatically. Even though this is the API for the
rest of odoo (dialogs, renderButton (old WidgetButton), ...), this is
a problem here as fixing this would require to add the 'btn-default'
class in every view which is using this case.
While waiting for a better solution, this commit is instead forcing
the btn-default class in that header case only (so only when a class
was mentioned but it did not contain any bootstrap btn type class).
So the new system gives:
-> In Header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> btn-link
btn-danger -> btn-danger
some_class -> btn-default some_class
-> Not in header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> btn-link
btn-danger -> btn-danger
some_class -> some_class
This commit also adds tests which will prevent the system to change
again without noticing it.
Closes https://github.com/odoo/odoo/pull/24443
Nicolas Martinelli