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
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
When you define recurring maintenance requests on an equipment, the
maintenance duration and the maintenance team is not set on the created
requests.
The problem comes from the creation method called by the cron that
doesn't use the duration and maintenance team to create new requests.
We now use these fields in the request creation
The xml file with the cron that creates the recurrent
preventive requests was not loaded in the system, so we needed to add
it.
Before, the cron was foreseen to only create the maintenance request on
the day that the request was foreseen (in the morning). Now, it will
create a request if none exists on the next_action_date. That way the
requests can be planned for.
The other problem is that the '_compute_next_maintenance' method
for calculating the next_action_date does not take into account
the possibly manually already created requests. So, now, the next
maintenance is calculated with the closed requests and the open ones.
If the first new one is in the past, it takes that date in the past. If it is in
the future, it will see if the gap is big enough to put a maintenance
in between the last done maintenance (or now) and the first new one.
If none exists, it is today + period.
That's why we have to add the 'request_date' in the depends. And take
into account the preventive requests existing on an equipment.
Several modules defines records with the external ID `base.foo_bar` while it is
created inside this module (typically menus and groups).
While there is no technical reasons to do so but this may introduce issues:
- these records will not be deleted during uninstall
- if a language is loaded before the installation of the module, it won't be
translated
The uninstallation will only remove the records with an external id linked to
this module (these would only be removed when removing base).
Installing a language before the module will drop the translations not linked
to an existing external id (as it can not be resolved).
This commit correct all the external ids tagged as from base or other incorrect
modules.
- rename models from hr.equipment.something to maintenance.something
- add concept of maintenance team and dashboard
- remove generic alias for maintenance
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