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
This commit has several purposes:
- Group public/portal/employees access rights into a single selection field
- Rename the 'Employee' access right into 'Internal User'
- Remove the groups reified view on the user form and replace it by real
computed fields: Selection fields for the application groups, and
Boolean fields for the isolated groups.
For more information about the specification please check the related commits
Task ID: 32258
- Create a binary field which takes some time for computation. For
example:
```
ding_dong = fields.Binary(compute='_compute_ding_dong')
def _compute_ding_dong(self):
if not self.env.context.get('bin_size'):
while True:
3*3
for x in self:
x.ding_dong = x.product_id.image_medium
```
- Run the server with a limited CPU time, for example:
`--workers=2 --limit-time-cpu=10`
- Download the file
A JS traceback occurs, without any information about the real crash.
The error management is simply not working: `JSON.parse` is called on a
string which is not JSON-parseable.
opw-1838832
The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
Purpose
=======
Allow to define users groups on a res.user with computed fields based on the 'groups_id' field.
Specification
=============
Add compute/inverse methods to manage specific groups on a res.users.
These methods should be used on fields defined like one the following cases:
1. A boolean field with the compute/inverse method and an attribute group_xml_id.
Example:
has_group_discount_per_so_line = fields.Boolean(
"Discount on lines",
compute='_compute_groups_id', inverse='_inverse_groups_id',
group_xml_id='sale.group_discount_per_so_line')
2. A selection field with the compute/inverse method, the selection got from '_get_group_selection'
and an attribute 'category_xml_id'
Example:
group_sales_team_user = fields.Selection(
selection=lambda self: self._get_group_selection('base.module_category_sales_management'),
string="Sales", compute='_compute_groups_id', inverse='_inverse_groups_id',
category_xml_id='base.module_category_sales_management')
The fields will be set according to the groups defined in the 'groups_id' field, and the 'groups_id'
field will be modified according to the modifications made on theses fields when saving the users's
form.
- Create a product named 'toto'
- Perform a call to `name_search`:
`self.env['product.product'].name_search('pouet', [], 'not ilike')`
Product 'toto' doesn't show up in the result list.
The domain should take into account that `default_code` can be `False`.
Note: the bug also occurs if the product is called 'trululu'.
opw-1837957
Yannick Tivisse