| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This reverts commit 99f497b390e680629dce3a7e2e282ada74ee9884.
|
|
'project_time_mode_id' is the field used to determined the UoM to
use when logging timesheets. It is not used in project alone, but
in timesheet. Moving it make sense, and does not cause any problems.
For now, no UI allow the end user to change it: it is set with the
Hours UoM (hardcoded).
This is a technical move to prepare the feature that will allow
people timesheeting in Days or Hours.
Task #39079
|
|
Purpose of commit is to implement KPIs about opened tasks for project
digest emails. Opened tasks are nor archived nor in a final stage. Those
are added in the default digest template.
A tip is added to remind to use the mail gateway.
This commit is linked to task ID 30655 and PR #18318.
|
|
The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
|
|
This commit removes the inheritS between account.analytic.account and
project.project. This means :
- When a project is created, an analytic account is not necessarily
genareted
- project has now its own name, company_id and partner_id fields
- an analytic account can be linked to several project
- project module does not depend anymore of analytic, but hr_timesheet
does.
This change implied
- an analytic account is required on project to timesheet on
its tasks. So, when checking 'allow_timsheets', if an AA is not
provided at project creation, an AA will be generated.
- to timesheet on project, an active AA is required. We don't want
timesheeting on project linked to unused AA to avoid bad analytic
entries.
This prepare the fact a sale order can create multiple project, sharing
the same analytic account (the one from the SO).
|
|
Purpose
=======
User tests have been made by the Product Owners team. It showed that the planners are not used by new users on Odoo due to several reasons (They are too static, too heavy to use,...)
Specification
=============
Remove the module and its different applications. The onboarding on the business flow will be improvement in the weeks to come.
|
|
So, move analytic code into its own
file for a better understanding and
too fit the guidelines.
|
|
Now that we only have one model (res.config.settings). Uniformize everything according to the guidelines.
|
|
|
|
* LDAP import: python-ldap is not python3-compatible, pyldap is
Warning: only supported from debian Stretch (current testing)?
https://packages.debian.org/search?searchon=names&keywords=pyldap
* implicitly relative imports
* imports of moved or removed stdlib modules
issue #8530
|
|
|
