Purpose
=======
When an employee leaves the company, the fleet manager must ask to the insurance company
a claim report for this employee. But in oddo, there is no easy way to have an history
of the drivers.
Specification
=============
1/ On the employee form, add a stat button: "x cars". The button shouldn't be displayed if the count = 0.
Make a bridge (auto_install: True in the manifest) depending on hr (hr.employee) and fleet (fleet.vehicle.assignation.log)
- Add a field employee_cars_count (computed) to count the amount of cars the employee drove.
- Add an method action_open_employee_cars, that return an action (ir.actions.act_window)
that open on the fleet.vehicle kanban filtered on cars the employee had driven.
2/ In this bridge module, add on the fleet.vehicle.assignation.logs a button (like in expense) to upload
documents about the car for a particular employee (PV, rapport d'assurance, blabla). On the employee
form view, add an action button (with groups fleet_manager) to print all the related documents
(all the attachements on the fleet.vehicle.assignation.logs for the employee).
closesodoo/odoo#28077
The module lacks demo data to have a nice visual display when testing the application
Add allocation requests and leaves request for several employees
TaskID: 1906478
closesodoo/odoo#28427
Since the split between hr.leave and hr.leave.allocation (See https://github.com/odoo/odoo/commit/a0f4f6548bdb9a26151fc8a292d152fc67d1a13c),
the field manager_id has disappeard from the hr.leave.allocation model.
When modifying the parent_id field on an employee, the change is reflected
on the related employee leaves and allocation by overriding the write method.
As the field doesn't exist anymore, this obviously leads to a warning.
The correct fix it to reintroduce this field.
The module lacks demo data to have a nice visual display when testing the application
Add allocation requests and leaves request for several employees
TaskID: 1906478
[IMP] stock: don't show move fully in package
When the move lines in a move are all linked to a package level,
we don't want to see the move anymore. We cannot keep only a domain on
moves their-selves as it depends on the move lines linked to it.
So we use a compute field to filter the moves to show, and the inverse
function just appends the new/modified moves to the move_lines.
TASK-ID: 1865671
closesodoo/odoo#28401
When the move lines in a move are all linked to a package level,
we don't want to see the move anymore. We cannot keep only a domain on
moves their-selves as it depends on the move lines linked to it.
So we use a compute field to filter the moves to show, and the inverse
function just appends the new/modified moves to the move_lines.
TASK-ID: 1865671
After 12744bc81ebdaa1671a953c14ba54c637d6a9255, x2m operations are
fully batched, and deletions are processed last when the operations are
flushed, regardless of the order in which they were specified by the
write() or create() call.
This carries a risk of violating (non-deferred) unique SQL constraints,
when the operations for deleting previous lines and re-creating new
ones are processed in the same batch.
This patch executes the deletions before other operations during a
flush, which should be safer with regard to SQL constraints.
An extra constraint is added in test_performance.line to simulate this
corner case, then covered by an extra unit test.
Another unrelated test had to be altered to avoid violating the
new constraint.
This can be reproduced easily by upgrading the `project` module in master,
due to the unique constraint[1] on `ir.actions.act_window.view`, that
gets violated when processing the batch write on this o2m[2].
[1] https://github.com/odoo/odoo/blob/ccc42f16/odoo/addons/base/models/ir_actions.py#L288-L289
[2] https://github.com/odoo/odoo/blob/ccc42f16/addons/project/views/project_views.xml#L394-L396closesodoo/odoo#28314
The ir.mail_server Model includes a sequence field, promising that the
lower sequence number have higher priority when multiple server
configurations are available.
The servers are already used based on that parameter since 00bd7274c4 but this
was not enforced at the _order level.
Make it coherent everywhere
closesodoo/odoo#28313
Current behavior before PR:
When a lead or res.partner click in the 'unsubscribe' link in a mail that was sent to him via the mass mailing module (not via a particular mailing list), he is blacklisted from the whole mass mailing system. The only message he gets is "you have been successfully unsubscribed".
Desired behavior after PR is merged:
The user is told that he was unsubscribed, but in addition a warning is displayed telling him explicitly :
- to which mailing lists he was subscribed
- that he won't receive any mail from them anymore.
Purpose : Warn the user that unsubscribe via a lead or res.partner mass mailing that he won't receive any mail from the mailing lists (listed in the warning) he had subscribed, if any.
closesodoo/odoo#27678
Add an 'enableRelationalFetch' option in _readGroup who force to make
only one rpc for x2m and reference fields.
Usefull to avoid useless (and blocking when too numerous) rpcs (tags
field in a kanban view for example).
Task #1878113 (2/2)
closesodoo/odoo#27731
The model inheritance concept was explained with abstract example which is
often confusing.
Change to a real world example that will be better understood.
closesodoo/odoo#27396
The received quantity on Purchase Order line can be compared
to the delivered qty on Sales Order line. It is now time for
both to share the same mecanism (introduced in
3bf8a62e0d).
This commit sets `qty_received` as a computed field, depending
of a method (`qty_received_method` field) to compute it. The
value can be computed based on
- manual value; for services (all the time), and consummable
products (when stock is not installed).
- stock moves; for stockable and consummable products (when
stock is installed)
This is now easier to extend the way the received quantity
need to be computed (like in sale).
Task #1850689closesodoo/odoo#27663
This commit fixes the following bug:
* On a new DB, install account
* Settings > Technical > Email > Digest emails
* Open Weekly Digest, set Next Send Date to current day
* Settings > Technical > Scheduled Actions > Digest Emails
* Run manually
AttributeError: 'res.company' object has no attribute
'resource_calendar_id'
The field resource_calendar_id is provided by the module resource
closesodoo/odoo#28239
Purpose
=======
Before this commit, it was not straightforward to use leave records in salary
rules programatically.
This commit implements the standard and python-code compatible way of defining
leave codes which then can be used in the salary rules in the used way.
This way, the naming of leaves will not be restricted to python-attribute
compatible naming, when one wants to use this feature.
Leave names (translatable) are an unreliable identification in python code salary rules.
A language switch would break python salary rules that use a leave type as input
TaskID: 1903964
Closes#28240
Co-authored-by: blaggacao <david@elaleman.co>
Purpose of this merge is to clean a bit link_tracker and utm as well as their
use in mass mailing. Main things done in this merge are
* reorganize link_tracker and utm according to guidelines. Purpose is
to ease code understanding and prepare future improvements in those
modules;
* clean views, add missing fields in views;
* better integration of link menus and views in mass mailing;
This commit is related to task ID 1896681.
closesodoo/odoo#27975
Purpose
=======
Some parts of the code are quite old-api-style and could be modified to use recordsets and thus improve performances.
closesodoo/odoo#28182
Purpose is to ease use of mass mailing by improving the action linking to
statistics. Form / graph view is added as well as informations related
to mass mailing and campaign.
This commit is linked to task ID 1896681 and PR #27975.
Purpose
=======
These classes are utils classes for the payslip computation.
It's better for the code readability to isolate them into a single file,
and keep the business logic into the payslip model code.
Purpose
=======
This method has nothing to do on the payslip model.
Specification
=============
Move the method on the hr_contract module, on the hr.employee model.
Rename the method and return and recordset instead of a list of ids.
Some variables were placed at the beginning of the backend helper.
While it was working, the normal convention is to place them at the
end of the variables helper.
closesodoo/odoo#28203
Purpose is
* to clean a bit views;
* to improve link.tracker form view to have information better displayed;
* to remove unused views;
This commit is linked to task ID 1896681 and PR #27975.
This was not correctly done when splitting the module at fd5361c0f7.
Future commits will clean a bit the code in order to better understand how
this module works.
This commit is linked to task ID 1896681 and PR #27975. No functional change
should occur with this commit as it contains only renaming / move.
This module still holds old code and deserves some love. This commit cleans a
bit the init and manifest files as well as renaming view file according to
guidelines.
This commit is linked to task ID 1896681 and PR #27975. No functional change
should occur with this commit as it contains only renaming / move.
Purpose is to give a quick polish to this module code concerning views.
Some ids are updated, indentation is fixed.
This commit is linked to task ID 1896681 and PR #27975.
This module holds old code and is still not updated according to guidelines.
Let us update a bit the naming in this module to have readable code.
This commit is linked to task ID 1896681 and PR #27975. No functional change
should occur with this commit as it contains only renaming / move.
Given a country code is specified and the country only has one timezone, it is
safe to assume that the admin user is operating from that timezone.
Set the default timezone to simplify the onboarding in such particular case.
If a country has more than one timezone, we can not make safe assumptions and
don't provide a default tz.
closesodoo/odoo#26365
If a supplier had a refund, it was not included in the supplier invoice count
nor in the results in the statbutton
On the customer side, fields like total_invoiced works on both the out_invoice
and out_refund
closesodoo/odoo#28161
If a supplier had a refund, it was not included in the supplier invoice count
nor in the results in the statbutton
On the customer side, fields like total_invoiced works on both the out_invoice
and out_refund
Otherwise, the product is a service based on delivered
quantity which is not a covered case by the service_policy
field on product form view (the selection will be empty).
Asked in Task-1859308
closesodoo/odoo#28162
The utility function xml_to_json, which is mainly used by the views to
parse their arch (from string to xml tree) had a peculiar behaviour: it
tried to process some attributes as json. If by chance, these
attributes are valid json, then they are replaced by their parsed value.
It is difficult to say why it could be useful. Maybe this was done to
prevent using pyeval many times later on. But if that is the case, it
should be done by the view code and not the utility function (the view
can precompute all attributes once).
Also, this behaviour is annoying for code later in the chain, which
needs to check if what it gets is an object or a string. With this
change, attributes are always returned as string (at this point).
closesodoo/odoo#28133
Adds 3 smart buttons with count to see :
- Groups
- Access Controls
- Record Rules
Buttons available in debug mode only
Every user that have access to user form has at least admin / Settings or Admin / Access rights.
Admin / Settings includes Admin / Access Rights
Create and delete are not allowed for those views.
Indeed users may think they are modifying current user's access
whereas they are modifying the whole group access.
To avoid confusion, the user's access rights list is now not editable.
Clicking on a row redirects to form view that can be edited.
A warning has been added on access rights form to be sure the user
is aware of what he is doing.
Task ID : 1830142
Closes PR #25587
Co-authored-by: David Beguin <dbe@odoo.com>
Co-authored-by: FMDL <florent.mirieu@gmail.com>
jbm-odoo