Module sale_opportunity

[yangoon1, 2010-03-26 17:47:01]

swapfile in tests by accident.

http://codereview.appspot.com/779041/diff/1/8
File __tryton__.py (right):

http://codereview.appspot.com/779041/diff/1/8#newcode9
__tryton__.py:9: 'description': '''Sales extension
Provides:

http://codereview.appspot.com/779041/diff/1/9
File opportunity.py (right):

http://codereview.appspot.com/779041/diff/1/9#newcode118
opportunity.py:118: :param opportunity_id: the id of the opportunity
param state missing

http://codereview.appspot.com/779041/diff/1/9#newcode134
opportunity.py:134: Return sale line values for each opportunity lines
Return sale line values for each opportunity line

http://codereview.appspot.com/779041/diff/1/9#newcode154
opportunity.py:154: Return sale values for opportunity
Return sale values for an opportunity

http://codereview.appspot.com/779041/diff/1/9#newcode342
opportunity.py:342: start_date = fields.Date('State Date')
State Date?

[sharoonthomas, 2010-03-26 18:33:13]

http://codereview.appspot.com/779041/diff/1/8
File __tryton__.py (right):

http://codereview.appspot.com/779041/diff/1/8#newcode13
__tryton__.py:13: - Record of lost leads
now includes oppportunities to sale orders?

[yangoon1, 2010-03-26 19:34:25]

After installing the module I have a question:

A lead could also be a contract, not necessarily a product.

Shouldn't the design be more generic to allow for
opportunity
opportunity_sale
opportunity_contract
?

[ced, 2010-03-28 09:57:25]

On 2010/03/26 19:34:25, yangoon wrote:
> After installing the module I have a question:
> 
> A lead could also be a contract, not necessarily a product.
> 
> Shouldn't the design be more generic to allow for
> opportunity
> opportunity_sale
> opportunity_contract
> ?

I don't see any advantage to share a common base.
Depending of the type of contract but most of it are products and become a sale
otherwise I don't see what it will be. Have you an example?

[yangoon1, 2010-03-28 19:46:56]

On 2010/03/28 09:57:25, ced wrote:
> On 2010/03/26 19:34:25, yangoon wrote:
> > After installing the module I have a question:
> > 
> > A lead could also be a contract, not necessarily a product.
> > 
> > Shouldn't the design be more generic to allow for
> > opportunity
> > opportunity_sale
> > opportunity_contract
> > ?
> 
> I don't see any advantage to share a common base.
> Depending of the type of contract but most of it are products and become a
sale
> otherwise I don't see what it will be. Have you an example?

https://app.vitrado.de/programminfo?id=11
https://app.vitrado.de/programminfo?id=65

It is in german, but can give you perhaps a notion. They sell contracts for
assurances. Sometimes you are paid per lead, sometimes per sale.

[ced, 2010-03-28 20:21:22]

On 2010/03/28 19:46:56, yangoon wrote:
> On 2010/03/28 09:57:25, ced wrote:
> > On 2010/03/26 19:34:25, yangoon wrote:
> > > After installing the module I have a question:
> > > 
> > > A lead could also be a contract, not necessarily a product.
> > > 
> > > Shouldn't the design be more generic to allow for
> > > opportunity
> > > opportunity_sale
> > > opportunity_contract
> > > ?
> > 
> > I don't see any advantage to share a common base.
> > Depending of the type of contract but most of it are products and become a
> sale
> > otherwise I don't see what it will be. Have you an example?
> 
> https://app.vitrado.de/programminfo?id=11
> https://app.vitrado.de/programminfo?id=65
> 
> It is in german, but can give you perhaps a notion. They sell contracts for
> assurances. Sometimes you are paid per lead, sometimes per sale.

I don't understand. Could you explain how will be the workflow? What will be the
advantage of mixing the different concept?

[yangoon1, 2010-03-28 21:29:08]

On 2010/03/28 20:21:22, ced wrote:
> On 2010/03/28 19:46:56, yangoon wrote:
> > On 2010/03/28 09:57:25, ced wrote:
> > > On 2010/03/26 19:34:25, yangoon wrote:
> > > > After installing the module I have a question:
> > > > 
> > > > A lead could also be a contract, not necessarily a product.
> > > > 
> > > > Shouldn't the design be more generic to allow for
> > > > opportunity
> > > > opportunity_sale
> > > > opportunity_contract
> > > > ?
> > > 
> > > I don't see any advantage to share a common base.
> > > Depending of the type of contract but most of it are products and become a
> > sale
> > > otherwise I don't see what it will be. Have you an example?
> > 
> > https://app.vitrado.de/programminfo?id=11
> > https://app.vitrado.de/programminfo?id=65
> > 
> > It is in german, but can give you perhaps a notion. They sell contracts for
> > assurances. Sometimes you are paid per lead, sometimes per sale.
> 
> I don't understand. Could you explain how will be the workflow? What will be
the
> advantage of mixing the different concept?

No change in workflow for me, but instead of products you could handle i.e.
contracts, newsletters etc., there can be many kinds of leads.
Restricting the type of a Sale Lead/Opportunity line by default to a product
seems not to be generic for me.

[yangoon1, 2010-03-28 21:41:52]

http://codereview.appspot.com/779041/diff/13001/14008
File opportunity.py (right):

http://codereview.appspot.com/779041/diff/13001/14008#newcode61
opportunity.py:61: 'History')
Should be set ot readonly to avoid display of activated icons. History lines are
readonly anyway.

[ced, 2010-03-28 21:59:46]

On 2010/03/28 21:29:08, yangoon wrote:
> On 2010/03/28 20:21:22, ced wrote:
> > On 2010/03/28 19:46:56, yangoon wrote:
> > > On 2010/03/28 09:57:25, ced wrote:
> > > > On 2010/03/26 19:34:25, yangoon wrote:
> > > > > After installing the module I have a question:
> > > > > 
> > > > > A lead could also be a contract, not necessarily a product.
> > > > > 
> > > > > Shouldn't the design be more generic to allow for
> > > > > opportunity
> > > > > opportunity_sale
> > > > > opportunity_contract
> > > > > ?
> > > > 
> > > > I don't see any advantage to share a common base.
> > > > Depending of the type of contract but most of it are products and become
a
> > > sale
> > > > otherwise I don't see what it will be. Have you an example?
> > > 
> > > https://app.vitrado.de/programminfo?id=11
> > > https://app.vitrado.de/programminfo?id=65
> > > 
> > > It is in german, but can give you perhaps a notion. They sell contracts
for
> > > assurances. Sometimes you are paid per lead, sometimes per sale.
> > 
> > I don't understand. Could you explain how will be the workflow? What will be
> the
> > advantage of mixing the different concept?
> 
> No change in workflow for me, but instead of products you could handle i.e.
> contracts, newsletters etc., there can be many kinds of leads.
> Restricting the type of a Sale Lead/Opportunity line by default to a product
> seems not to be generic for me.

For me contracts, newsletters are products.

[timitos, 2010-06-12 16:39:05]

When i click on a record in the list of history i get the following error on dev
version of tryton: 

Traceback (most recent call last):
  File "/trytond/protocols/netrpc.py", line 47, in run
    res = dispatch(host, port, 'NetRPC', *msg)
  File "/trytond/protocols/dispatcher.py", line 127, in dispatch
    res = getattr(obj, method)(cursor, user, *args, **kargs)
  File "/trytond/model/modelsql.py", line 613, in read
    context=ctx)
  File "trytond/modules/sale_opportunity/opportunity.py", line 373, in get
  File "/trytond/model/fields/one2many.py", line 101, in get
    [self.field], context=context):
  File "/trytond/model/modelsql.py", line 524, in read
    table_args + red_ids + history_args)
  File "/trytond/backend/postgresql/database.py", line 290, in execute
    res = self.cursor.execute(sql, params)
ProgrammingError: invalid input syntax for type numeric:
"2010-06-12T18:36:33.077752"

[ced, 2010-06-12 17:50:03]

On 2010/06/12 16:39:05, timitos wrote:
> When i click on a record in the list of history i get the following error on
dev
> version of tryton: 
> 
> Traceback (most recent call last):
>   File "/trytond/protocols/netrpc.py", line 47, in run
>     res = dispatch(host, port, 'NetRPC', *msg)
>   File "/trytond/protocols/dispatcher.py", line 127, in dispatch
>     res = getattr(obj, method)(cursor, user, *args, **kargs)
>   File "/trytond/model/modelsql.py", line 613, in read
>     context=ctx)
>   File "trytond/modules/sale_opportunity/opportunity.py", line 373, in get
>   File "/trytond/model/fields/one2many.py", line 101, in get
>     [self.field], context=context):
>   File "/trytond/model/modelsql.py", line 524, in read
>     table_args + red_ids + history_args)
>   File "/trytond/backend/postgresql/database.py", line 290, in execute
>     res = self.cursor.execute(sql, params)
> ProgrammingError: invalid input syntax for type numeric:
> "2010-06-12T18:36:33.077752"

It is not intended to work with trunk but only with 1.6 for now.
Is it happening on 1.6?

[timitos, 2010-06-12 18:07:11]

On 2010/06/12 17:50:03, ced wrote:
> On 2010/06/12 16:39:05, timitos wrote:
> > When i click on a record in the list of history i get the following error on
> dev
> > version of tryton: 
> > 
> > Traceback (most recent call last):
> >   File "/trytond/protocols/netrpc.py", line 47, in run
> >     res = dispatch(host, port, 'NetRPC', *msg)
> >   File "/trytond/protocols/dispatcher.py", line 127, in dispatch
> >     res = getattr(obj, method)(cursor, user, *args, **kargs)
> >   File "/trytond/model/modelsql.py", line 613, in read
> >     context=ctx)
> >   File "trytond/modules/sale_opportunity/opportunity.py", line 373, in get
> >   File "/trytond/model/fields/one2many.py", line 101, in get
> >     [self.field], context=context):
> >   File "/trytond/model/modelsql.py", line 524, in read
> >     table_args + red_ids + history_args)
> >   File "/trytond/backend/postgresql/database.py", line 290, in execute
> >     res = self.cursor.execute(sql, params)
> > ProgrammingError: invalid input syntax for type numeric:
> > "2010-06-12T18:36:33.077752"
> 
> It is not intended to work with trunk but only with 1.6 for now.
> Is it happening on 1.6?

With 1.6 everything seems to be ok.

[ced, 2010-06-12 18:07:32]

On 2010/06/12 17:50:03, ced wrote:
> On 2010/06/12 16:39:05, timitos wrote:
> > When i click on a record in the list of history i get the following error on
> It is not intended to work with trunk but only with 1.6 for now.
> Is it happening on 1.6?

It happens also on 1.6. I will check.

[ced, 2010-06-12 18:17:52]

On 2010/06/12 18:07:32, ced wrote:
> On 2010/06/12 17:50:03, ced wrote:
> > On 2010/06/12 16:39:05, timitos wrote:
> > > When i click on a record in the list of history i get the following error
on
> > It is not intended to work with trunk but only with 1.6 for now.
> > Is it happening on 1.6?
> 
> It happens also on 1.6. I will check.

Fixed with changeset 012afdea6fe7

[timitos, 2010-06-12 18:19:26]

On 2010/06/12 18:07:32, ced wrote:
> On 2010/06/12 17:50:03, ced wrote:
> > On 2010/06/12 16:39:05, timitos wrote:
> > > When i click on a record in the list of history i get the following error
on
> > It is not intended to work with trunk but only with 1.6 for now.
> > Is it happening on 1.6?
> 
> It happens also on 1.6. I will check.

Funny. I could not reproduce it with 1.6.

[ced, 2010-06-12 18:21:01]

On 2010/06/12 18:19:26, timitos wrote:
> On 2010/06/12 18:07:32, ced wrote:
> > On 2010/06/12 17:50:03, ced wrote:
> > > On 2010/06/12 16:39:05, timitos wrote:
> > > > When i click on a record in the list of history i get the following
error
> on
> > > It is not intended to work with trunk but only with 1.6 for now.
> > > Is it happening on 1.6?
> > 
> > It happens also on 1.6. I will check.
> 
> Funny. I could not reproduce it with 1.6.

This is because I have unpublished backport patches

[timitos, 2010-06-13 14:38:15]

i was able to produce another error:
Traceback (most recent call last):
  File "/trytond/protocols/netrpc.py", line 47, in run
    res = dispatch(host, port, 'NetRPC', *msg)
  File "/trytond/protocols/dispatcher.py", line 127, in dispatch
    res = getattr(obj, method)(cursor, user, *args, **kargs)
  File "/trytond/model/modelworkflow.py", line 123, in workflow_trigger_validate
    context=context)
  File "/trytond/workflow/workflow.py", line 210, in validate
    force_running=force_running, context=context)
  File "/trytond/workflow/workflow.py", line 328, in process
    signal, context=context)
  File "/trytond/workflow/workflow.py", line 451, in _split_test
    context=context)
  File "/trytond/workflow/workflow.py", line 463, in _join_test
    }, context=context)
  File "/trytond/workflow/workflow.py", line 300, in create
    self.process(cursor, user, workitem, context=context)
  File "/trytond/workflow/workflow.py", line 321, in process
    context=context):
  File "/trytond/workflow/workflow.py", line 371, in _execute
    context=context)
  File "/trytond/workflow/expr.py", line 74, in execute
    context=context)
  File "/trytond/workflow/expr.py", line 59, in eval_expr
    res = safe_eval(line, env)
  File "/trytond/tools/misc.py", line 605, in safe_eval
    }}, data)
  File "", line 1, in <module>
  File "/trytond/workflow/expr.py", line 21, in __call__
    self.obj_id, *args, **kargs)
  File "/trytond/modules/sale_opportunity/opportunity.py", line 257, in
create_sale
    context=ctx)
  File "/trytond/model/modelsql.py", line 397, in create
    values[field], context=context)
  File "/trytond/model/fields/many2many.py", line 109, in set
    if act[0] == 'create':
TypeError: 'int' object is unsubscriptable

[timitos, 2010-07-02 07:36:04]

i found one issue:
When i open the history and change after this for example the quantity on lines
i get a message that the record has been changed. this should not happen as only
the history has been opened.

[ced, 2010-07-02 07:41:17]

On 2010/07/02 07:36:04, timitos wrote:
> i found one issue:
> When i open the history and change after this for example the quantity on
lines
> i get a message that the record has been changed. this should not happen as
only
> the history has been opened.

Not linked to the module.

[udono, 2010-07-04 09:36:50]

Works on postgres and tip

http://codereview.appspot.com/779041/diff/45001/46007
File opportunity.py (right):

http://codereview.appspot.com/779041/diff/45001/46007#newcode45
opportunity.py:45: depends=['currency_digits'])
Here we could put some help text or another string like 'estimated revenue
amount'

[udono, 2010-07-04 09:40:48]

http://codereview.appspot.com/779041/diff/62001/63008
File opportunity.xml (right):

http://codereview.appspot.com/779041/diff/62001/63008#newcode748
opportunity.xml:748: </record>
Only a tree action?

[ced, 2010-07-04 10:01:20]

http://codereview.appspot.com/779041/diff/62001/63008
File opportunity.xml (right):

http://codereview.appspot.com/779041/diff/62001/63008#newcode748
opportunity.xml:748: </record>
On 2010/07/04 09:40:48, udono wrote:
> Only a tree action? 

I don't see which graph could be done.

[udono, 2010-07-04 10:30:35]

http://codereview.appspot.com/779041/diff/62001/63008
File opportunity.xml (right):

http://codereview.appspot.com/779041/diff/62001/63008#newcode748
opportunity.xml:748: </record>
On 2010/07/04 10:01:20, ced wrote:
> On 2010/07/04 09:40:48, udono wrote:
> > Only a tree action? 
> I don't see which graph could be done.
Yes, I do not see a graph representation for this. But I am unsure to have only
a tree view, even without a form view.

[udono, 2010-07-04 19:34:17]

Looks good!

[sharoonthomas, 2010-08-04 09:31:53]

My own bug!

http://codereview.appspot.com/779041/diff/73001/47009
File __tryton__.py (right):

http://codereview.appspot.com/779041/diff/73001/47009#newcode5
__tryton__.py:5: 'version': '0.0.1',
The version number is wrong, this will cause setup.py to crash because it will
split and search for the wrong version of tryton.