Link between sales and projects


(Cédric Krier) #7

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.

(Sergi Almacellas Abellana) #8

You mean allow the user to set custom states for task via a configuration table?

(Cédric Krier) #9

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.

(albert) #10

Then, you could be interested in project_phase:

which requires:

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.

(Sergi Almacellas Abellana) #11

I was thinking in something more simpler like create a new model ( to store the following fields:

  • Type: Project or task
  • Name: The name of the sequence

Then the state will depend on type and dynamically get the values from the table.

And maybe we can include the following flags:

  • Add tab domain: If set a new tab domain will be added for each action of project work that does not have any domain
  • Count tab domain: Set if the count should be set for the tab domain.

(Cédric Krier) #12

I would add a sequence on it.

So we also need a way to get the default value, or at least set the state with an on_change on the type.

(Cédric Krier) #13

Also in order to make state flexible, the invoice method should no more rely on it.

(Sergi Almacellas Abellana) #14

So I’m wondering if it makes sense to mark some states as Completed, which will be used to automatically set the work progress to 100%.

(Cédric Krier) #15

Probably as in some way we have starting state which are for 0% progress. So I would use the terms start and stop to describe both.

(Sergi Almacellas Abellana) #16

I’m wondering it won’t be better to add the progress on the state and automatically update the work progress when changing the state if it is lower.

(Cédric Krier) #17

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).

(Cédric Krier) #19

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.

(Sergi Almacellas Abellana) #20

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

(Cédric Krier) #21

For me, it is a wrong assumption. You can start working on a project even if it is no won. For example you can prepare the quotation.

Idem the project may have some progress and still be lost.

(Sergi Almacellas Abellana) #22

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.

(Cédric Krier) #23

I do not agree. There will be a task “Quotation” and it will probably go up to finished before knowing if the project is won or not.

As I said previously, a project workflow is and should be very flexible. And so there are very few assumption that can be done.

(Sergi Almacellas Abellana) #24

Your right, haven’t though about this case :man_facepalming:

Then I think the unique option is to explicity mark on each state if the opportunity is “Won” or “Lost” by using an optional Selection field.

(Cédric Krier) #25

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.

(Sergi Almacellas Abellana) #26

I’ve created Issue 7986: Link between opportunities and projects - Tryton issue tracker which implements it.

Which does not require to have total freedom over the project states