add story field also on custRequest header

[hans_bakker]

At the moment i am looking to create a customer service component.

The usage of the custRequest entity in this case never will need
custRequestItem's

The long description field called 'story' is however only available in
the custRequestItem and not on the header.

In order to simplify the implementation i would like to have the story
field also on the header in order not to have to use a 'dummy'
custRequestItem to use the story field.

Any objections?

--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Myself on twitter: http://twitter.com/hansbak
Antwebsystems.com: Quality services for competitive rates.

[Scott Gray-2]

Hi Hans,

I would recommend using the custRequestItem for the story, the implementation can be simple enough by using a service to create the header and item in a single call and a view entity could could them back to you as a single record.  Conceptually what you really have is a customer request with a single item.

I don't like the idea of modifying the data model when it is already quite capable of meeting your needs.

Regards,
Scott

On 11/03/2010, at 7:19 PM, Hans Bakker wrote:

> At the moment i am looking to create a customer service component.
>
> The usage of the custRequest entity in this case never will need
> custRequestItem's
>
> The long description field called 'story' is however only available in
> the custRequestItem and not on the header.
>
> In order to simplify the implementation i would like to have the story
> field also on the header in order not to have to use a 'dummy'
> custRequestItem to use the story field.
>
> Any objections?
>
> --
> Ofbiz on twitter: http://twitter.com/apache_ofbiz
> Myself on twitter: http://twitter.com/hansbak
> Antwebsystems.com: Quality services for competitive rates.
>

[Bilgin Ibryam-2]

Scott Gray wrote:
> Hi Hans,
>
> I would recommend using the custRequestItem for the story, the implementation can be simple enough by using a service to create the header and item in a single call and a view entity could could them back to you as a single record.  Conceptually what you really have is a customer request with a single item.
>
> I don't like the idea of modifying the data model when it is already quite capable of meeting your needs.
>
> Regards,
> Scott
>  
 Agreed with Scott. Having two places for the same information will be
confusing/redundant and such a change should not go to ofbiz svn in that
case.

Bilgin

[Jacques Le Roux]

Anyway a sole -1 is enough for reverting code without explanations
Needs 3 +1  (and more + than -) for a release.
These are Apache rules (inherited from HTTPD project) as it's well explained in the release management document Bruno gave a link)

Jacques

From: "Bilgin Ibryam" <[hidden email]>

> Scott Gray wrote:
>> Hi Hans,
>>
>> I would recommend using the custRequestItem for the story, the implementation can be simple enough by using a service to create
>> the header and item in a single call and a view entity could could them back to you as a single record.  Conceptually what you
>> really have is a customer request with a single item.
>>
>> I don't like the idea of modifying the data model when it is already quite capable of meeting your needs.
>>
>> Regards,
>> Scott
>>
> Agreed with Scott. Having two places for the same information will be confusing/redundant and such a change should not go to ofbiz
> svn in that case.
>
> Bilgin
>

[Christian Geisert]

I think it makes sense to have a story/text for the header (for all
items), but why not using CustRequestNote for this?

Christian

Scott Gray schrieb:

> Hi Hans,
>
> I would recommend using the custRequestItem for the story, the implementation can be simple enough by using a service to create the header and item in a single call and a view entity could could them back to you as a single record.  Conceptually what you really have is a customer request with a single item.
>
> I don't like the idea of modifying the data model when it is already quite capable of meeting your needs.
>
> Regards,
> Scott
>
> On 11/03/2010, at 7:19 PM, Hans Bakker wrote:
>
>> At the moment i am looking to create a customer service component.
>>
>> The usage of the custRequest entity in this case never will need
>> custRequestItem's
>>
>> The long description field called 'story' is however only available in
>> the custRequestItem and not on the header.
>>
>> In order to simplify the implementation i would like to have the story
>> field also on the header in order not to have to use a 'dummy'
>> custRequestItem to use the story field.
>>
>> Any objections?

[Christian Geisert]

Jacques Le Roux schrieb:
> Anyway a sole -1 is enough for reverting code without explanations

Wrong, a veto on code modification without an explanation is invalid!
See http://www.apache.org/foundation/voting.html

But this shouldn't really be used all the time, it makes a lot more
sense to discuss things in advance (as Hans did)

Christian

[Bruno Busco]

The customer service component would be something like JIRA is?
Why not extend the project manager to have all the feature that JIRA has?
I think there would be many users interested to a OFBiz based JIRA-like
system.

-Bruno


2010/3/12 Christian Geisert <[hidden email]>

> Jacques Le Roux schrieb:
>
>  Anyway a sole -1 is enough for reverting code without explanations
>>
>
> Wrong, a veto on code modification without an explanation is invalid!
> See http://www.apache.org/foundation/voting.html
>
> But this shouldn't really be used all the time, it makes a lot more sense
> to discuss things in advance (as Hans did)
>
> Christian
>
>

[Jacques Le Roux]

From: "Christian Geisert" <[hidden email]>
> Jacques Le Roux schrieb:
>> Anyway a sole -1 is enough for reverting code without explanations
>
> Wrong, a veto on code modification without an explanation is invalid!
> See http://www.apache.org/foundation/voting.html

Yes indeed, thanks for the correction Christian.
Not sure why I added "without explanations" it does not make sense since for  a revert to be voted it has obviously to be discussed
before to establish the vote.
Actually I don't think we ever voted for a revert. Because it's really much bureaucratic, as as soon as we know that a commiter is
strongly against he will surely vote -1 (no she possible in our case)

> But this shouldn't really be used all the time, it makes a lot more sense to discuss things in advance (as Hans did)

Yes, we should all try to do so. Most of the time it's done.

Jacques

> Christian
>

[Scott Gray-2]

Why would you even bring this up here?  No one is talking about commits and definitely no one is talking about reverts.

Regards
Scott

On 12/03/2010, at 2:53 AM, Jacques Le Roux wrote:

> Anyway a sole -1 is enough for reverting code without explanations
> Needs 3 +1  (and more + than -) for a release.
> These are Apache rules (inherited from HTTPD project) as it's well explained in the release management document Bruno gave a link)
>
> Jacques
>
> From: "Bilgin Ibryam" <[hidden email]>
>> Scott Gray wrote:
>>> Hi Hans,
>>>
>>> I would recommend using the custRequestItem for the story, the implementation can be simple enough by using a service to create the header and item in a single call and a view entity could could them back to you as a single record.  Conceptually what you really have is a customer request with a single item.
>>>
>>> I don't like the idea of modifying the data model when it is already quite capable of meeting your needs.
>>>
>>> Regards,
>>> Scott
>>>
>> Agreed with Scott. Having two places for the same information will be confusing/redundant and such a change should not go to ofbiz svn in that case.
>>
>> Bilgin
>
>

[hans_bakker]

Hi Bruno

yes that was my first intention to integrate it completely with the
project manager, look at the 'requests' button there.

However i had to change my mind.... There are two areas:

1. ticket(request) management and the communicationEvents  around it
2. project/task/timeregistration/invoice management

I intend to still have them tight together however not always results a
request/ticket into a task in the project manager. Further the people
involved are also different.

any (further) suggestions or comments welcome!

Regards,
Hans

--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Myself on twitter: http://twitter.com/hansbak
Antwebsystems.com: Quality services for competitive rates.

On Fri, 2010-03-12 at 12:28 +0100, Bruno Busco wrote:

> The customer service component would be something like JIRA is?
> Why not extend the project manager to have all the feature that JIRA has?
> I think there would be many users interested to a OFBiz based JIRA-like
> system.
>
> -Bruno
>
>
> 2010/3/12 Christian Geisert <[hidden email]>
>
> > Jacques Le Roux schrieb:
> >
> >  Anyway a sole -1 is enough for reverting code without explanations
> >>
> >
> > Wrong, a veto on code modification without an explanation is invalid!
> > See http://www.apache.org/foundation/voting.html
> >
> > But this shouldn't really be used all the time, it makes a lot more sense
> > to discuss things in advance (as Hans did)
> >
> > Christian
> >
> >

[hans_bakker]

Hi Christian,
nice to have you back!
Sure we can use that too, but the note is meant for some extra info?
The main story should be as close to the request as possible.

Initially the request was meant to have information at some kind of
product list therefore the items so it could be easy converted ino a
quote.

A customer service request most of the time is not like that. However as
usual we can work around it as you can see in the commits  I did
today...but still i am not sure it is the best way of doing it.

Regards,
Hans
--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Myself on twitter: http://twitter.com/hansbak
Antwebsystems.com: Quality services for competitive rates.

On Fri, 2010-03-12 at 11:14 +0100, Christian Geisert wrote:

> I think it makes sense to have a story/text for the header (for all
> items), but why not using CustRequestNote for this?
>
> Christian
>
> Scott Gray schrieb:
> > Hi Hans,
> >
> > I would recommend using the custRequestItem for the story, the implementation can be simple enough by using a service to create the header and item in a single call and a view entity could could them back to you as a single record.  Conceptually what you really have is a customer request with a single item.
> >
> > I don't like the idea of modifying the data model when it is already quite capable of meeting your needs.
> >
> > Regards,
> > Scott
> >
> > On 11/03/2010, at 7:19 PM, Hans Bakker wrote:
> >
> >> At the moment i am looking to create a customer service component.
> >>
> >> The usage of the custRequest entity in this case never will need
> >> custRequestItem's
> >>
> >> The long description field called 'story' is however only available in
> >> the custRequestItem and not on the header.
> >>
> >> In order to simplify the implementation i would like to have the story
> >> field also on the header in order not to have to use a 'dummy'
> >> custRequestItem to use the story field.
> >>
> >> Any objections?
>

[Jacques Le Roux]

Simply because I read that in the document Bruno "sent" us and I was not aware of all details.
So I though maybe some other commitets were not and a summary (on this subject) could not hurt.

Jacques

From: "Scott Gray" <[hidden email]>
Why would you even bring this up here?  No one is talking about commits and definitely no one is talking about reverts.

Regards
Scott

On 12/03/2010, at 2:53 AM, Jacques Le Roux wrote:

> Anyway a sole -1 is enough for reverting code without explanations
> Needs 3 +1  (and more + than -) for a release.
> These are Apache rules (inherited from HTTPD project) as it's well explained in the release management document Bruno gave a link)
>
> Jacques
>
> From: "Bilgin Ibryam" <[hidden email]>
>> Scott Gray wrote:
>>> Hi Hans,
>>>
>>> I would recommend using the custRequestItem for the story, the implementation can be simple enough by using a service to create
>>> the header and item in a single call and a view entity could could them back to you as a single record.  Conceptually what you
>>> really have is a customer request with a single item.
>>>
>>> I don't like the idea of modifying the data model when it is already quite capable of meeting your needs.
>>>
>>> Regards,
>>> Scott
>>>
>> Agreed with Scott. Having two places for the same information will be confusing/redundant and such a change should not go to
>> ofbiz svn in that case.
>>
>> Bilgin
>
>

[Scott Gray-2]

It just seems rude to me, Hans comes to the list with a discussion, which is a good thing, and people start talking about reverts?

Regards
Scott

On 12/03/2010, at 7:33 AM, Jacques Le Roux wrote:

> Simply because I read that in the document Bruno "sent" us and I was not aware of all details.
> So I though maybe some other commitets were not and a summary (on this subject) could not hurt.
>
> Jacques
>
> From: "Scott Gray" <[hidden email]>
> Why would you even bring this up here?  No one is talking about commits and definitely no one is talking about reverts.
>
> Regards
> Scott
>
> On 12/03/2010, at 2:53 AM, Jacques Le Roux wrote:
>
>> Anyway a sole -1 is enough for reverting code without explanations
>> Needs 3 +1  (and more + than -) for a release.
>> These are Apache rules (inherited from HTTPD project) as it's well explained in the release management document Bruno gave a link)
>>
>> Jacques
>>
>> From: "Bilgin Ibryam" <[hidden email]>
>>> Scott Gray wrote:
>>>> Hi Hans,
>>>>
>>>> I would recommend using the custRequestItem for the story, the implementation can be simple enough by using a service to create the header and item in a single call and a view entity could could them back to you as a single record.  Conceptually what you really have is a customer request with a single item.
>>>>
>>>> I don't like the idea of modifying the data model when it is already quite capable of meeting your needs.
>>>>
>>>> Regards,
>>>> Scott
>>>>
>>> Agreed with Scott. Having two places for the same information will be confusing/redundant and such a change should not go to ofbiz svn in that case.
>>>
>>> Bilgin
>>
>>
>
>
>

[Jacques Le Roux]

Ha.... It was not directed to Hans at all. Just that I thought it could be interesting for everyone.

To be clear, I have anything against Hans. He is here for a longer time than me, knows certainly more things than me on OFBiz and
his contributions, past and future, are very important.
I would have loved that we could get a consensus on the Tweeter account. Because what if we want now to create an apache_ofbiz
tweeter account? I suppose we can't since the name already exists. It's as simple as that.

I'M NOT BAD!

Jacques

From: "Scott Gray" <[hidden email]>
It just seems rude to me, Hans comes to the list with a discussion, which is a good thing, and people start talking about reverts?

Regards
Scott

On 12/03/2010, at 7:33 AM, Jacques Le Roux wrote:

> Simply because I read that in the document Bruno "sent" us and I was not aware of all details.
> So I though maybe some other commitets were not and a summary (on this subject) could not hurt.
>
> Jacques
>
> From: "Scott Gray" <[hidden email]>
> Why would you even bring this up here?  No one is talking about commits and definitely no one is talking about reverts.
>
> Regards
> Scott
>
> On 12/03/2010, at 2:53 AM, Jacques Le Roux wrote:
>
>> Anyway a sole -1 is enough for reverting code without explanations
>> Needs 3 +1  (and more + than -) for a release.
>> These are Apache rules (inherited from HTTPD project) as it's well explained in the release management document Bruno gave a
>> link)
>>
>> Jacques
>>
>> From: "Bilgin Ibryam" <[hidden email]>
>>> Scott Gray wrote:
>>>> Hi Hans,
>>>>
>>>> I would recommend using the custRequestItem for the story, the implementation can be simple enough by using a service to create
>>>> the header and item in a single call and a view entity could could them back to you as a single record.  Conceptually what you
>>>> really have is a customer request with a single item.
>>>>
>>>> I don't like the idea of modifying the data model when it is already quite capable of meeting your needs.
>>>>
>>>> Regards,
>>>> Scott
>>>>
>>> Agreed with Scott. Having two places for the same information will be confusing/redundant and such a change should not go to
>>> ofbiz svn in that case.
>>>
>>> Bilgin
>>
>>
>
>
>

[Erwan de FERRIERES]

Le 12/03/2010 15:28, Hans Bakker a écrit :
> Hi Bruno
>
> yes that was my first intention to integrate it completely with the

>
Hi Hans,

we are planning on doing such thing, and merging our forces may create a
nice piece of OFBiz contribution !

On the entity part, what have you planned ? using CustRequest or adding
new entities ?

We'd like, for a first step, having a small (in the functionnalities
way) ticket management system, and not yet a JIRA clone. A bit short in
time, at the moment.

So, should we create a JIRA issue, for planning, comnenting and deciding
which way to go ?

Cheers,

--
Erwan de FERRIERES
www.nereide.biz

[hans_bakker]

Hi Erwan,
I have already started it and it is arranged around the custRequest
entity and it is using he existing entities as much as possible. I will
have a first version in the next few days. I intend to make it a gpl
license and will make it available from our svn on request....

Regards,
Hans

On Fri, 2010-03-12 at 17:46 +0100, Erwan de FERRIERES wrote:

> Le 12/03/2010 15:28, Hans Bakker a écrit :
> > Hi Bruno
> >
> > yes that was my first intention to integrate it completely with the
>
> >
> Hi Hans,
>
> we are planning on doing such thing, and merging our forces may create a
> nice piece of OFBiz contribution !
>
> On the entity part, what have you planned ? using CustRequest or adding
> new entities ?
>
> We'd like, for a first step, having a small (in the functionnalities
> way) ticket management system, and not yet a JIRA clone. A bit short in
> time, at the moment.
>
> So, should we create a JIRA issue, for planning, comnenting and deciding
> which way to go ?
>
> Cheers,
>

--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Myself on twitter: http://twitter.com/hansbak
Antwebsystems.com: Quality services for competitive rates.

[Erwan de FERRIERES]

Le 13/03/2010 10:00, Hans Bakker a écrit :
> Hi Erwan,
> I have already started it and it is arranged around the custRequest
> entity and it is using he existing entities as much as possible. I will
> have a first version in the next few days. I intend to make it a gpl
> license and will make it available from our svn on request....
>
> Regards,
> Hans
>

Hi Hans,

Have you considered the addon schema we created for such thing ? Or is
it just a hot-deploy component ?

We'd like to look at what you've already done, and try not to reinvent
the wheel...

Cheers,

--
Erwan de FERRIERES
www.nereide.biz

[hans_bakker]

Hi Erwan,

Concerning the customer service component, i made it a hot-deploy
component. I intend to have all screens and forms not to use any of the
ofbiz versions and i intend to use it with a patch directory to easy
upgrade with newer ofbiz versions.

There is however a relation to the projectmanager to automatically
create a task from a request in a project and assign it to a certain
person. The person In the project manager will register the time whicj
can be automatically invoiced to the customer.

Regards,
Hans


On Mon, 2010-03-15 at 08:56 +0100, Erwan de FERRIERES wrote:

> Le 13/03/2010 10:00, Hans Bakker a écrit :
> > Hi Erwan,
> > I have already started it and it is arranged around the custRequest
> > entity and it is using he existing entities as much as possible. I will
> > have a first version in the next few days. I intend to make it a gpl
> > license and will make it available from our svn on request....
> >
> > Regards,
> > Hans
> >
>
> Hi Hans,
>
> Have you considered the addon schema we created for such thing ? Or is
> it just a hot-deploy component ?
>
> We'd like to look at what you've already done, and try not to reinvent
> the wheel...
>
> Cheers,
>

--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Myself on twitter: http://twitter.com/hansbak
Antwebsystems.com: Quality services for competitive rates.