Purpose
=======
When you create a vehicle, there is no sense in adding it to the
"registered column", you always start at the first stage. And this
is also very subjective to create a contract for one year. Why ?
In addition, the contract is empty, excepted for the date.
Specification
=============
- When you create a vehicle, his stage is : New Request
- On the contract form view, make the vehicle's field editable,
the driver is always related to the vehicle.
- Allow to add property fields on vehicle and model
closesodoo/odoo#127298
Taskid: 3349871
Related: odoo/enterprise#43627
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This PR makes the following changes :
- In the demo data, add a fleet manager to the vehicle linked to Marc Demo & add a domain to that field to only list users from the selected company(ies)
- On the Launch Plan window change the dropdownlist for a radiobutton widget
- Remove the quick create and quick edit option on the launch plan screen
- Add a due date on the launch plan screen, the activities will be created on launch plan and the due date will be the one selected in the field
- On the activity type, hide the Schedule field if no value are defined on the previous field (suggest/trigger)
task-3337922
closesodoo/odoo#122298
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This PR :
- Adds 2 new default contract types to the data : Omnium and Leasing
- Lets the user search models by manufacturer name and model name
task - 3249291
closesodoo/odoo#117059
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Just doing the summer file cleaning. Move mail data into files named based on
their model, easing maintenance and searching for those data.
Spotted during Task-2207626 (Rating: Delay rating notification to ease feedback)
Part-of: odoo/odoo#98661
Description of the issue/feature this PR addresses:
In fleet, the demo data for service type have two entries for summer tires
The service types are sorted by alphabetical orders instead of id
Current behavior before PR:
The summer tires service type is appearing twice in the demo data
The service types are sorted by id
Desired behavior after PR is merged:
The summer tires service type is unique in the list
The services types are sorted by alphabetical order
task-2641484
closesodoo/odoo#76403
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Following the removal of read access on ir.model (odoo/odoo#69120),
the mail.activity.type model was not accessible to non-admin users due
to the res_model_id many2one field.
Before this commit, a project user could not access the Activity Type
menu.
Convert it to a selection field with the selection values being
computed in sudo.
closesodoo/odoo#74981
Related: odoo/enterprise#20214
Related: odoo/upgrade#2734
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Revamp the kanban view of fleet.vehicle.log.services.
Add some ux improvements (new filters, better naming,..).
Fix bug where contracts/services of archived fleet.vehicle were
not counted in statinfo.
When a fleet.vehicle is archived, archive its related contracts/services.
closesodoo/odoo#62556
Taskid: 2389823
Related: odoo/upgrade#2063
Related: odoo/enterprise#15036
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this change, we create an xid for every parent of a record
being imported, regardless of whether it already has an xid, or if
it's being created implicitly through the child.
This generates unnecessary extra xids on pre-existing objects
e.g. update 5 product variants -> the product gets 5 new xids despite
already having one.
We should *only* set a xid on parent records which are being
implicitly created by the creation of a child with a specified
xid. That is, we should never set a xid on the parent if it exists
before the child is created.
Update _process_end to try and see if "non-loaded" xids correspond to
an automatically generated "parent" xid: we're still setting a xid on
implicitly created records (if the child is created with a xid) so
they're properly removed if e.g. the module is uninstalled, but
because we're only doing so at creation these xids will not be visited
during update and _process_end will try to delete them.
A special case can be added to check that "unknown" parent xids don't
have children which _inherit them, in which case we want to protect them.
Task 2251039
closesodoo/odoo#53283
Related: odoo/enterprise#12023
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Purpose
=======
It is currently difficult to know exactly what is used for costs
and services on the contracts.
Hence it make it difficult to evolve the fleet application
We should clean the models in order to have something that is clearer
Specification
=============
Cleanup of models: removed Fuel and Cost. Contract and Services are no
longer inheriting Cost and are seperate models simplifying the use of
Fleet. A contract now has included services and they are no longer
generating cost.
closesodoo/odoo#34090
Taskid: 1931775
Related: odoo/enterprise#4572
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The big images are probably never going to be used for the following models:
- pos category
- fleet brand
- livechat channel
- mail channel
- payment acquirer
And if big images are needed some day the model should use image.mixin instead.
PR: #34925
This probably a bad idea for odoo but is definitly a bad idea for pofile
As shown in gettext reference, the spaces are used as separator in po files
https://www.gnu.org/software/gettext/manual/html_node/PO-Files.html
For instance
#: src/msgcmp.c:338 src/po-lex.c:699
#, c-format
msgid "found %d fatal error"
msgstr "..."
The line "model_terms:ir.ui.view,arch_db:website_sale.search count"
was considered as two references:
- 'model_terms:ir.ui.view,arch_db:website_sale.search'
- 'count'
Correct external id of fleet, even if not translatable
Basically when someone requests a new car, getting that car ready takes
some time, this means that during the waiting period, that person is
still driving its old car.
This commit adds a field future_driver_id on fleet.vehicle to tackle
that problem and a boolean plan_to_change_car on the partner to track
who wants to change car.
+ Apply some linting to the files
This commit cleans the vehicle form view, the vehicle contract form
view, the cost list view and adds a manager_id field on the
vehicle.model which is then used as a related on the vehicle.
Task: 1930298
closesodoo/odoo#31197
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This field is a non-sense. By using the same logic, it should be added
to any low level model.
Replace the check by a simple verification of presence of an XMLID.
A more generic opt-in solution should be integrated into ORM.
Partially revert commits 0db0e66e96 and
bbd64c22ab.
See #29257odoo/enterprise#3550closesodoo/odoo#31778
Signed-off-by: Christophe Simonis <chs@odoo.com>
Purpose of this merge is to update main addons and set activity types used
for automated activities as master data. This means they cannot be removed.
Indeed those activity types are used in business flow to generate activities
and removing them may break some flows.
This commit is linked to task ID 1907970 and PR #29257.
This commit improves fleet contracts management through a better integration
of activities and addition of automated activities. Several things are done
in this commit :
* fleet vehicle log contract does not inherit from mail.activity.mixin.
This commit adds the inherit so that fleet users and managers can now
schedule and manage activities on vehicle contracts. This will help them
in their daily job;
* automatic activities generation is added when contracts are nearly expired
and renewal is required;
* a menu to configure activity types is added. Indeed fleet managers should
be able to see and configure activity types related to their job;
* filters are added to be able to use the systray and to filter the kanban
view based on activities
Having automated activities allow to replace some messages posted on the
contract. Indeed currently there are messages posted on vehicles about
contracts to renew. As we now have automated activities on contracts to
remind assigned people to renew it the log can be safely removed. It will
lessen noise generated on chatter.
Purpose: Improve fleet for a better usability
Dashboard:
- Replace 'leasing' button by a contract status icon in kanban tiles
- Add a link to contract
- Link to vehicule form when clicking on the tile
Vehicle form:
- Track contract status in a chatter
- Add a model_year
Contracts:
- Imporve the states names
- Split service types in two list views service/contracts
- Execute a cron once a day to upgrade contract status
- Add a new contract status is introduced 'Expiring Soon' to help
spot contracts that will expire until 15 days with a filter.
- Add a 'group by vehicle' to improve list usability
Fuel logs view: Add an an odometer column
The purpose of this commit is to handle code execution only in server
action and delegate schedule management to ir_cron model.
ir.cron model now inherits from ir.actions.server. Fields model, function
and args are removed as well as the logic to handle them. There is no
more code manipulation and evaluation in ir_cron, only a call to the run
method of ir.actions.server.
Cron form view use server action form view as primary view. This way
automated actions use the same base form as server actions with
cron details added.
Thanks to @fpodoo for the original idea and preliminary work. Thanks to
@jpr-odoo for first developments. Thanks to @jem-odoo for reviewing.
Yannick Tivisse