If the new project of the task or issue has the current record stage among its own stages do not reset it. It avoids unnecessary changes and chatter logs.
Because task has an html file and issue was jealous. And also to have clickable links.
hr.recruitment.report is not necessary anymore as it can be replaced by classic pivot and graph views on hr.applicant model. Applicant has been slighty modified to ease reporting * adding group_operator average on both days to computation; * adding group_operator average on working hours computation;
In Python 3: * various builtins and dict methods were changed to return view/iterable objects rather than lists * and the separate Python 2 view/iterable builtins and methods were removed altogether This is problematic when using these items as list (which the happens repeatedly in Odoo), but more viciously when iterating *multiple times* over them (which also happens, which I've messed up multiple times while writing this, and which is a pain to debug even when you've just created the issue). Convert all code using these to semantics-matching cross-version helper functions to get the LCD behaviour between P2 and P3, and forbid the builtins via lint. issue #8530
When a message is posted through the chatter and creates a new partner the issue is now updated so that the partner field is correctly set to the newly-created partner. Chatter on issue now uses the reload option so that the view is reloaded after posting a message. The user therefore sees that the record has been updated accordingly.
This is some leftovers of old implementation of activities. Activity mixin field should be used instead now.
Currently timezones were not or incorrectly taken into account in resource computation. Indeed complexity comes from attendances being expressed in naive timezones valid for all users, whereas dates and leaves are computed into UTC. Computation should always be done in user timezone so that there are no overlapping days and all time intervals are correctly computed. A new timezone field is added on leaves to know in which timezone they were originally encoded. Indeed putting them in naive user timezone require its original timezone, not the current user timezone, as those can be different. This commit also contains code cleaning in resource to be a bit more pythonic, simplify method parameters and offer a more simple api to other modules. Eventually code field is removed on resource as it is not really necessary for resources. It is explicitly added on workcenter model who use it.
Old methods are still present since a long time and are deprecated since saas-3. This compatibility layer adds unnecessary complexity to the module API. Those methods should now be removed. Some renaming is also performed to ease resource api understanding, notably to better differentiate internal methods from other methods. All addons are updated accordingly.
Companies now always have a default calendar configured. All methods in resource module should therefore be able to use a real resource.calendar. This commit removes the computation based on a pseudo 8-17 calendar given as weird method parameters. Project is updated in order to use the company calendar by default.