PURPOSE
Make aliases usage more unique, prevent re-using bounce or catchall aliases
and remove auto-uniqueness of aliases.
SPECIFICATIONS
Before this commit, user could create an email alias having same name as
catchall/bounce email alias, which should not happen. Also, while creating
or duplicating alias, if the same name was already available, a new unique
name was generated by adding a sequence number to existing name.
This behavior is not considered as a good one as it magically creates aliases
different from what user expects. User could even not own the newly-created
alias, leading to a broken mail gateway.
In this commit we improve that behavior by ensuring that no duplicate alias
name should be entered while creation / updation for both catcall/bounce and
mail alias. Also, while duplicating an alias, name will now be blank by default
to force user to enter the name. Finally when creating an alias an error is
raised if the name is already taken.
Task ID 2160070
* Code cleanup
* Avoid a safe evaluation of the field value when loading those records.
closesodoo/odoo#44883
Related: odoo/enterprise#8283
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The mail.message.subtype model contains a field internal,
which decides if the messages are visible to external users or not.
Such a value should not be overriden at module update,
so all subtypes should be in noupdate.
opw 1946043
closesodoo/odoo#32214
Signed-off-by: Nans Lefebvre (len) <len@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.
When a user is assigned as responsible of request, we want him to get a
mail saying that he's a assigned to this request, a standard behaviour
exists in Odoo to perform such a thing, which consist of having a field
named 'user_id' which is tracked, so to avoid overriding the method, we
renamed the field 'technician_user_id' in 'user_id'.
Wre also set teh mail subtype 'request create' with default false, to
have the same behaviour as the on in project, meaning that it is true
only if you have the parent subtype set to true.
TASK-ID: 58645
This commit improves maintenance requests management through a better
integration of activities and addition of automated activities. Several
things are done in this commit :
* automatic activities generation is added for maintenance requests.
Activities are generated to remind assigned users about maintenance to
perform. They are also automatically removed or updated if the scheduled
date is changed or if the request is done to avoid bloating users with
unnecessary activities;
* a menu to configure activity types is added. Indeed equipment managers
should be able to see and configure activity types related to their job;
It is simpler to have data split by main model or application like we
already do for models and views. It allows to easily have an overview
of data a module holds.
As we will work on mail related data like adding activities or tweaking
subtypes and templates, having them all in a single file and not lost
between other data helps finding and working with it.
This commit only moves code. No functional change should occur.
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.
- rename models from hr.equipment.something to maintenance.something
- add concept of maintenance team and dashboard
- remove generic alias for maintenance
maintenance is not dependant on hr anymore. A new module hr_maintenance is
added that adds hr-related fields (employee owner, ...). This way maintenance
is a stand alone application.
hr_equipment module is renamed to maintenance. No change is performed to the
module itself. It prepares further changes, mainly splitting maintenance from
hr_maintenance.
Siddarth Gajjar