Probably but indeed the current design of project makes it difficult to manage such state because the field is on each work. Or we will need to have separate states for project and task.
Indeed I would prefer to have complete freedom on the definition of the states of a work.
Yes probably something like that. Project management workflow is not so standard as sale and neither very much constrained, each company has its own practice.
project_tracker provides a “category” (named “tracker”, the name was borrowed from redmine).
project_phase adds:
a model to store phases (would be the “state” you’re talking about). A phase also defines if it is a “final” phase (which would be equivalent to closed state)
a m2o field named “phase” to Tasks
a Workflow model where you define which phases are valid for each workflow (you may have a workflow for issues and another one for new features)
a m2o field named “workflow” to Trackers (you may define just three worfkflows but have 15 different trackers)
So once a task has a tracker assigned, only phases from the workflow of the tracker are valid
It is also useful to define which is the default phase for each tracker so it is filled with on_change once the tracker is set.
I’m not sure if it is really a good feature because it may appear unexpected to the user. I’m wondering if it will not be better to have a validation. If the progress is not equals or more to the progress of the state, the state is not valid.
But if you have total freedom over the states, how can I implement a workflow where fields are readonly in certain states? Do I have to ignore it and create the states in my own module? Because I prefer buttons to set the state (and eventually do some logic) instead of the dropdown (just a taste).
My experience shows me that if you set a fixed workflow for project, you will have trouble.
Instead it is better to just put constraint, the state definition can store such constraint like a field is required, the progress must be greater than etc.
In order to be know if the opportunity is won or lost we should know if a project is lost. So I think we should add an aditional mark on state to know if the project is still active or not. This should be able to negotiate the project state with the following conditions:
If project has empty progress and and active state is still in negotiation
If project has some progress is won
If project has no progress but and inactive state is lost
This will have an aditional benefit, that we can have a computed active field on project which will be used to “hide” cancelled and done projects
Yes, you can start working on a project but in order to prepare the project and start some qualification.
For me this will involve employees time sheets but no real progress on the project.
Once the project is accepted then you start progressing on the project so you can set 0% if none of the work is used for the project or an higher percentage if some of the previous work has some benefit for the project.
That does not sound right neither. You can not put on each task such value because only the root of a project concern the opportunity.
I think the best option is to manually convert an opportunity linked to a project as won or lost.