StatusValidChange

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

StatusValidChange

Scott Gray-2
Hi All

Currently there is a ton of code in various places that checks to make  
sure a status change is valid using the StatusValidChange entity, and  
there are also places where there is no check even though records  
exist (createShipment for example).  I'm wondering we couldn't add  
support for this to the entity engine itself so that it doesn't have  
to be done manually, we could add some sort of flag to the entity  
field def and then GenericEntity could perform the check when setting  
the field.  Thoughts?

The only thing I'm not too sure on is the purpose of the condition  
field on StatusValidChange and how it is intended to be used, there  
are no examples of its use in the existing data.

Failing that I'd at least like to add a utility method and a simple  
method operation to simplify the task.

Thanks
Scott

HotWax Media
http://www.hotwaxmedia.com




smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: StatusValidChange

David E Jones-3

A couple of notes:

1. if we add something to the entity engine to check this we would  
need to move the Status* entities from the common component to the  
entity component

2. I played with doing a separate method that genericized checking the  
StatusValidChange, but it made the code bigger and (IMO) more  
difficult to follow and customize, especially since the  
StatusValidChange checking is pretty simple in the first place.  
However, the code would be more generic and perhaps slightly more  
simply (ie maybe not fewer lines, but some of the lines would be less  
complex), so there might be some merit in it...

3. related to #1, but a variation on that approach: we could perhaps  
have a service that checks this generically that is called through an  
EECA or SECA rule, and then all we have to do is setup that ECA rule  
for each entity we want checked

-David


On May 6, 2009, at 9:29 PM, Scott Gray wrote:

> Hi All
>
> Currently there is a ton of code in various places that checks to  
> make sure a status change is valid using the StatusValidChange  
> entity, and there are also places where there is no check even  
> though records exist (createShipment for example).  I'm wondering we  
> couldn't add support for this to the entity engine itself so that it  
> doesn't have to be done manually, we could add some sort of flag to  
> the entity field def and then GenericEntity could perform the check  
> when setting the field.  Thoughts?
>
> The only thing I'm not too sure on is the purpose of the condition  
> field on StatusValidChange and how it is intended to be used, there  
> are no examples of its use in the existing data.
>
> Failing that I'd at least like to add a utility method and a simple  
> method operation to simplify the task.
>
> Thanks
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: StatusValidChange

Scott Gray-2
Hi David

Thanks for the feedback, here are the main issues as I see it with the  
way things are now:
1.  The developer has to know/remember to check for a valid status  
change, I'm willing to bet that there are numerous places where it  
isn't checked at the moment but should be.
2.  While generally the check is only around 8-12 lines of code, the  
developer has to either remember how to write the query and what error  
message should be displayed or find some existing code to copy/paste  
(is the status set, has the status changed, do the lookup, report an  
error).

I don't think options #2 and #3 below cover problem #1 above but they  
may help with #2.

Also another issue with StatusValidChange is that there is currently  
no way to make sure when creating a new record that the initial status  
is valid, I stumbled across this while fixing the test cases where a  
Shipment was being created in the SHIPMENT_PACKED status and it was  
subsequent ECA code that was failing.  To solve that I would like to  
remove the not empty constraint on StatusValidChange.statusId so that  
we can use the entity to indicate valid status entry points and start  
checking for them during record creation.

My only goal with these suggestions is to try and lighten the load on  
the developer and this seems like a good opportunity for the framework  
to step in because the checks are very generic anyway.

Regards
Scott

On 7/05/2009, at 4:56 PM, David E Jones wrote:

>
> A couple of notes:
>
> 1. if we add something to the entity engine to check this we would  
> need to move the Status* entities from the common component to the  
> entity component
>
> 2. I played with doing a separate method that genericized checking  
> the StatusValidChange, but it made the code bigger and (IMO) more  
> difficult to follow and customize, especially since the  
> StatusValidChange checking is pretty simple in the first place.  
> However, the code would be more generic and perhaps slightly more  
> simply (ie maybe not fewer lines, but some of the lines would be  
> less complex), so there might be some merit in it...
>
> 3. related to #1, but a variation on that approach: we could perhaps  
> have a service that checks this generically that is called through  
> an EECA or SECA rule, and then all we have to do is setup that ECA  
> rule for each entity we want checked
>
> -David
>
>
> On May 6, 2009, at 9:29 PM, Scott Gray wrote:
>
>> Hi All
>>
>> Currently there is a ton of code in various places that checks to  
>> make sure a status change is valid using the StatusValidChange  
>> entity, and there are also places where there is no check even  
>> though records exist (createShipment for example).  I'm wondering  
>> we couldn't add support for this to the entity engine itself so  
>> that it doesn't have to be done manually, we could add some sort of  
>> flag to the entity field def and then GenericEntity could perform  
>> the check when setting the field.  Thoughts?
>>
>> The only thing I'm not too sure on is the purpose of the condition  
>> field on StatusValidChange and how it is intended to be used, there  
>> are no examples of its use in the existing data.
>>
>> Failing that I'd at least like to add a utility method and a simple  
>> method operation to simplify the task.
>>
>> Thanks
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>>
>>
>


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: StatusValidChange

hans_bakker
Hi Scott,

sorry to jump in.
In general i tried to concentrate the setting of the statusId in a
single service which is used for EVERY status change. examples are in
invoice and customerRequest and other places.

is that a possible solution?

Regards,
Hans

On Thu, 2009-05-07 at 18:24 +1200, Scott Gray wrote:

> Hi David
>
> Thanks for the feedback, here are the main issues as I see it with the  
> way things are now:
> 1.  The developer has to know/remember to check for a valid status  
> change, I'm willing to bet that there are numerous places where it  
> isn't checked at the moment but should be.
> 2.  While generally the check is only around 8-12 lines of code, the  
> developer has to either remember how to write the query and what error  
> message should be displayed or find some existing code to copy/paste  
> (is the status set, has the status changed, do the lookup, report an  
> error).
>
> I don't think options #2 and #3 below cover problem #1 above but they  
> may help with #2.
>
> Also another issue with StatusValidChange is that there is currently  
> no way to make sure when creating a new record that the initial status  
> is valid, I stumbled across this while fixing the test cases where a  
> Shipment was being created in the SHIPMENT_PACKED status and it was  
> subsequent ECA code that was failing.  To solve that I would like to  
> remove the not empty constraint on StatusValidChange.statusId so that  
> we can use the entity to indicate valid status entry points and start  
> checking for them during record creation.
>
> My only goal with these suggestions is to try and lighten the load on  
> the developer and this seems like a good opportunity for the framework  
> to step in because the checks are very generic anyway.
>
> Regards
> Scott
>
> On 7/05/2009, at 4:56 PM, David E Jones wrote:
>
> >
> > A couple of notes:
> >
> > 1. if we add something to the entity engine to check this we would  
> > need to move the Status* entities from the common component to the  
> > entity component
> >
> > 2. I played with doing a separate method that genericized checking  
> > the StatusValidChange, but it made the code bigger and (IMO) more  
> > difficult to follow and customize, especially since the  
> > StatusValidChange checking is pretty simple in the first place.  
> > However, the code would be more generic and perhaps slightly more  
> > simply (ie maybe not fewer lines, but some of the lines would be  
> > less complex), so there might be some merit in it...
> >
> > 3. related to #1, but a variation on that approach: we could perhaps  
> > have a service that checks this generically that is called through  
> > an EECA or SECA rule, and then all we have to do is setup that ECA  
> > rule for each entity we want checked
> >
> > -David
> >
> >
> > On May 6, 2009, at 9:29 PM, Scott Gray wrote:
> >
> >> Hi All
> >>
> >> Currently there is a ton of code in various places that checks to  
> >> make sure a status change is valid using the StatusValidChange  
> >> entity, and there are also places where there is no check even  
> >> though records exist (createShipment for example).  I'm wondering  
> >> we couldn't add support for this to the entity engine itself so  
> >> that it doesn't have to be done manually, we could add some sort of  
> >> flag to the entity field def and then GenericEntity could perform  
> >> the check when setting the field.  Thoughts?
> >>
> >> The only thing I'm not too sure on is the purpose of the condition  
> >> field on StatusValidChange and how it is intended to be used, there  
> >> are no examples of its use in the existing data.
> >>
> >> Failing that I'd at least like to add a utility method and a simple  
> >> method operation to simplify the task.
> >>
> >> Thanks
> >> Scott
> >>
> >> HotWax Media
> >> http://www.hotwaxmedia.com
> >>
> >>
> >>
> >
>
--
Antwebsystems.com: Quality OFBiz services for competitive rates

Reply | Threaded
Open this post in threaded view
|

Re: StatusValidChange

Scott Gray-2
No need to apologize Hans, comments were exactly what I was after so  
thank you for taking the time.

Based on your input and David's, I'm not going to worry about  
automating the checks as the current approach doesn't really seem to  
bother anyone.

I am still a little concerned about us not checking the validity of  
statuses for newly created records, does it bother anyone else?

Thanks
Scott

On 7/05/2009, at 6:36 PM, Hans Bakker wrote:

> Hi Scott,
>
> sorry to jump in.
> In general i tried to concentrate the setting of the statusId in a
> single service which is used for EVERY status change. examples are in
> invoice and customerRequest and other places.
>
> is that a possible solution?
>
> Regards,
> Hans
>
> On Thu, 2009-05-07 at 18:24 +1200, Scott Gray wrote:
>> Hi David
>>
>> Thanks for the feedback, here are the main issues as I see it with  
>> the
>> way things are now:
>> 1.  The developer has to know/remember to check for a valid status
>> change, I'm willing to bet that there are numerous places where it
>> isn't checked at the moment but should be.
>> 2.  While generally the check is only around 8-12 lines of code, the
>> developer has to either remember how to write the query and what  
>> error
>> message should be displayed or find some existing code to copy/paste
>> (is the status set, has the status changed, do the lookup, report an
>> error).
>>
>> I don't think options #2 and #3 below cover problem #1 above but they
>> may help with #2.
>>
>> Also another issue with StatusValidChange is that there is currently
>> no way to make sure when creating a new record that the initial  
>> status
>> is valid, I stumbled across this while fixing the test cases where a
>> Shipment was being created in the SHIPMENT_PACKED status and it was
>> subsequent ECA code that was failing.  To solve that I would like to
>> remove the not empty constraint on StatusValidChange.statusId so that
>> we can use the entity to indicate valid status entry points and start
>> checking for them during record creation.
>>
>> My only goal with these suggestions is to try and lighten the load on
>> the developer and this seems like a good opportunity for the  
>> framework
>> to step in because the checks are very generic anyway.
>>
>> Regards
>> Scott
>>
>> On 7/05/2009, at 4:56 PM, David E Jones wrote:
>>
>>>
>>> A couple of notes:
>>>
>>> 1. if we add something to the entity engine to check this we would
>>> need to move the Status* entities from the common component to the
>>> entity component
>>>
>>> 2. I played with doing a separate method that genericized checking
>>> the StatusValidChange, but it made the code bigger and (IMO) more
>>> difficult to follow and customize, especially since the
>>> StatusValidChange checking is pretty simple in the first place.
>>> However, the code would be more generic and perhaps slightly more
>>> simply (ie maybe not fewer lines, but some of the lines would be
>>> less complex), so there might be some merit in it...
>>>
>>> 3. related to #1, but a variation on that approach: we could perhaps
>>> have a service that checks this generically that is called through
>>> an EECA or SECA rule, and then all we have to do is setup that ECA
>>> rule for each entity we want checked
>>>
>>> -David
>>>
>>>
>>> On May 6, 2009, at 9:29 PM, Scott Gray wrote:
>>>
>>>> Hi All
>>>>
>>>> Currently there is a ton of code in various places that checks to
>>>> make sure a status change is valid using the StatusValidChange
>>>> entity, and there are also places where there is no check even
>>>> though records exist (createShipment for example).  I'm wondering
>>>> we couldn't add support for this to the entity engine itself so
>>>> that it doesn't have to be done manually, we could add some sort of
>>>> flag to the entity field def and then GenericEntity could perform
>>>> the check when setting the field.  Thoughts?
>>>>
>>>> The only thing I'm not too sure on is the purpose of the condition
>>>> field on StatusValidChange and how it is intended to be used, there
>>>> are no examples of its use in the existing data.
>>>>
>>>> Failing that I'd at least like to add a utility method and a simple
>>>> method operation to simplify the task.
>>>>
>>>> Thanks
>>>> Scott
>>>>
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>>
>>>>
>>>>
>>>
>>
> --
> Antwebsystems.com: Quality OFBiz services for competitive rates
>


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: StatusValidChange

Jacques Le Roux
Administrator
From: "Scott Gray" <[hidden email]>
> No need to apologize Hans, comments were exactly what I was after so  
> thank you for taking the time.
>
> Based on your input and David's, I'm not going to worry about  
> automating the checks as the current approach doesn't really seem to  
> bother anyone.
>
> I am still a little concerned about us not checking the validity of  
> statuses for newly created records, does it bother anyone else?

Hi Scott,

Yes, this is annoying and your examples prove that not only some exist but almost surely some new examples will be commited :/
Having something keeping this clean automatically would be not only cool for developpers but also for code quality.

Jacques
 

> Thanks
> Scott
>
> On 7/05/2009, at 6:36 PM, Hans Bakker wrote:
>
>> Hi Scott,
>>
>> sorry to jump in.
>> In general i tried to concentrate the setting of the statusId in a
>> single service which is used for EVERY status change. examples are in
>> invoice and customerRequest and other places.
>>
>> is that a possible solution?
>>
>> Regards,
>> Hans
>>
>> On Thu, 2009-05-07 at 18:24 +1200, Scott Gray wrote:
>>> Hi David
>>>
>>> Thanks for the feedback, here are the main issues as I see it with  
>>> the
>>> way things are now:
>>> 1.  The developer has to know/remember to check for a valid status
>>> change, I'm willing to bet that there are numerous places where it
>>> isn't checked at the moment but should be.
>>> 2.  While generally the check is only around 8-12 lines of code, the
>>> developer has to either remember how to write the query and what  
>>> error
>>> message should be displayed or find some existing code to copy/paste
>>> (is the status set, has the status changed, do the lookup, report an
>>> error).
>>>
>>> I don't think options #2 and #3 below cover problem #1 above but they
>>> may help with #2.
>>>
>>> Also another issue with StatusValidChange is that there is currently
>>> no way to make sure when creating a new record that the initial  
>>> status
>>> is valid, I stumbled across this while fixing the test cases where a
>>> Shipment was being created in the SHIPMENT_PACKED status and it was
>>> subsequent ECA code that was failing.  To solve that I would like to
>>> remove the not empty constraint on StatusValidChange.statusId so that
>>> we can use the entity to indicate valid status entry points and start
>>> checking for them during record creation.
>>>
>>> My only goal with these suggestions is to try and lighten the load on
>>> the developer and this seems like a good opportunity for the  
>>> framework
>>> to step in because the checks are very generic anyway.
>>>
>>> Regards
>>> Scott
>>>
>>> On 7/05/2009, at 4:56 PM, David E Jones wrote:
>>>
>>>>
>>>> A couple of notes:
>>>>
>>>> 1. if we add something to the entity engine to check this we would
>>>> need to move the Status* entities from the common component to the
>>>> entity component
>>>>
>>>> 2. I played with doing a separate method that genericized checking
>>>> the StatusValidChange, but it made the code bigger and (IMO) more
>>>> difficult to follow and customize, especially since the
>>>> StatusValidChange checking is pretty simple in the first place.
>>>> However, the code would be more generic and perhaps slightly more
>>>> simply (ie maybe not fewer lines, but some of the lines would be
>>>> less complex), so there might be some merit in it...
>>>>
>>>> 3. related to #1, but a variation on that approach: we could perhaps
>>>> have a service that checks this generically that is called through
>>>> an EECA or SECA rule, and then all we have to do is setup that ECA
>>>> rule for each entity we want checked
>>>>
>>>> -David
>>>>
>>>>
>>>> On May 6, 2009, at 9:29 PM, Scott Gray wrote:
>>>>
>>>>> Hi All
>>>>>
>>>>> Currently there is a ton of code in various places that checks to
>>>>> make sure a status change is valid using the StatusValidChange
>>>>> entity, and there are also places where there is no check even
>>>>> though records exist (createShipment for example).  I'm wondering
>>>>> we couldn't add support for this to the entity engine itself so
>>>>> that it doesn't have to be done manually, we could add some sort of
>>>>> flag to the entity field def and then GenericEntity could perform
>>>>> the check when setting the field.  Thoughts?
>>>>>
>>>>> The only thing I'm not too sure on is the purpose of the condition
>>>>> field on StatusValidChange and how it is intended to be used, there
>>>>> are no examples of its use in the existing data.
>>>>>
>>>>> Failing that I'd at least like to add a utility method and a simple
>>>>> method operation to simplify the task.
>>>>>
>>>>> Thanks
>>>>> Scott
>>>>>
>>>>> HotWax Media
>>>>> http://www.hotwaxmedia.com
>>>>>
>>>>>
>>>>>
>>>>
>>>
>> --
>> Antwebsystems.com: Quality OFBiz services for competitive rates
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: StatusValidChange

guo weizhan
May I add request here?  I think it's also need to add the status changed
history automatically, we can see how the status changed from the history
recorder.



2009/5/7 Jacques Le Roux <[hidden email]>

> From: "Scott Gray" <[hidden email]>
>
>> No need to apologize Hans, comments were exactly what I was after so
>>  thank you for taking the time.
>>
>> Based on your input and David's, I'm not going to worry about  automating
>> the checks as the current approach doesn't really seem to  bother anyone.
>>
>> I am still a little concerned about us not checking the validity of
>>  statuses for newly created records, does it bother anyone else?
>>
>
> Hi Scott,
>
> Yes, this is annoying and your examples prove that not only some exist but
> almost surely some new examples will be commited :/
> Having something keeping this clean automatically would be not only cool
> for developpers but also for code quality.
>
> Jacques
>
>
> Thanks
>> Scott
>>
>> On 7/05/2009, at 6:36 PM, Hans Bakker wrote:
>>
>> Hi Scott,
>>>
>>> sorry to jump in.
>>> In general i tried to concentrate the setting of the statusId in a
>>> single service which is used for EVERY status change. examples are in
>>> invoice and customerRequest and other places.
>>>
>>> is that a possible solution?
>>>
>>> Regards,
>>> Hans
>>>
>>> On Thu, 2009-05-07 at 18:24 +1200, Scott Gray wrote:
>>>
>>>> Hi David
>>>>
>>>> Thanks for the feedback, here are the main issues as I see it with  the
>>>> way things are now:
>>>> 1.  The developer has to know/remember to check for a valid status
>>>> change, I'm willing to bet that there are numerous places where it
>>>> isn't checked at the moment but should be.
>>>> 2.  While generally the check is only around 8-12 lines of code, the
>>>> developer has to either remember how to write the query and what  error
>>>> message should be displayed or find some existing code to copy/paste
>>>> (is the status set, has the status changed, do the lookup, report an
>>>> error).
>>>>
>>>> I don't think options #2 and #3 below cover problem #1 above but they
>>>> may help with #2.
>>>>
>>>> Also another issue with StatusValidChange is that there is currently
>>>> no way to make sure when creating a new record that the initial  status
>>>> is valid, I stumbled across this while fixing the test cases where a
>>>> Shipment was being created in the SHIPMENT_PACKED status and it was
>>>> subsequent ECA code that was failing.  To solve that I would like to
>>>> remove the not empty constraint on StatusValidChange.statusId so that
>>>> we can use the entity to indicate valid status entry points and start
>>>> checking for them during record creation.
>>>>
>>>> My only goal with these suggestions is to try and lighten the load on
>>>> the developer and this seems like a good opportunity for the  framework
>>>> to step in because the checks are very generic anyway.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> On 7/05/2009, at 4:56 PM, David E Jones wrote:
>>>>
>>>>
>>>>> A couple of notes:
>>>>>
>>>>> 1. if we add something to the entity engine to check this we would
>>>>> need to move the Status* entities from the common component to the
>>>>> entity component
>>>>>
>>>>> 2. I played with doing a separate method that genericized checking
>>>>> the StatusValidChange, but it made the code bigger and (IMO) more
>>>>> difficult to follow and customize, especially since the
>>>>> StatusValidChange checking is pretty simple in the first place.
>>>>> However, the code would be more generic and perhaps slightly more
>>>>> simply (ie maybe not fewer lines, but some of the lines would be
>>>>> less complex), so there might be some merit in it...
>>>>>
>>>>> 3. related to #1, but a variation on that approach: we could perhaps
>>>>> have a service that checks this generically that is called through
>>>>> an EECA or SECA rule, and then all we have to do is setup that ECA
>>>>> rule for each entity we want checked
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On May 6, 2009, at 9:29 PM, Scott Gray wrote:
>>>>>
>>>>> Hi All
>>>>>>
>>>>>> Currently there is a ton of code in various places that checks to
>>>>>> make sure a status change is valid using the StatusValidChange
>>>>>> entity, and there are also places where there is no check even
>>>>>> though records exist (createShipment for example).  I'm wondering
>>>>>> we couldn't add support for this to the entity engine itself so
>>>>>> that it doesn't have to be done manually, we could add some sort of
>>>>>> flag to the entity field def and then GenericEntity could perform
>>>>>> the check when setting the field.  Thoughts?
>>>>>>
>>>>>> The only thing I'm not too sure on is the purpose of the condition
>>>>>> field on StatusValidChange and how it is intended to be used, there
>>>>>> are no examples of its use in the existing data.
>>>>>>
>>>>>> Failing that I'd at least like to add a utility method and a simple
>>>>>> method operation to simplify the task.
>>>>>>
>>>>>> Thanks
>>>>>> Scott
>>>>>>
>>>>>> HotWax Media
>>>>>> http://www.hotwaxmedia.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>> --
>>> Antwebsystems.com: Quality OFBiz services for competitive rates
>>>
>>>
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: StatusValidChange

BJ Freeman
In reply to this post by hans_bakker
From what I picked up in a lot of cases a some of developers are trying
not use ofbiz as it was intended, especially at the UI level.

Yes, the fact valid status change is not used does concern me, however I
have not come up with a way to validate the code flow should or does use
 valid status change, except by walking through the code. That is a lot
of code to review.
I ran into to this when I was doing customization and adding major
status changes for a client.

Maybe a Jira that will let us document where these are not done then we
can evaluate what should be done.
I will be glad to go back over my notes to input what I found.


Scott Gray sent the following on 5/7/2009 1:10 AM:

> No need to apologize Hans, comments were exactly what I was after so
> thank you for taking the time.
>
> Based on your input and David's, I'm not going to worry about automating
> the checks as the current approach doesn't really seem to bother anyone.
>
> I am still a little concerned about us not checking the validity of
> statuses for newly created records, does it bother anyone else?
>
> Thanks
> Scott
>
> On 7/05/2009, at 6:36 PM, Hans Bakker wrote:
>
>> Hi Scott,
>>
>> sorry to jump in.
>> In general i tried to concentrate the setting of the statusId in a
>> single service which is used for EVERY status change. examples are in
>> invoice and customerRequest and other places.
>>
>> is that a possible solution?
>>
>> Regards,
>> Hans
>>
>> On Thu, 2009-05-07 at 18:24 +1200, Scott Gray wrote:
>>> Hi David
>>>
>>> Thanks for the feedback, here are the main issues as I see it with the
>>> way things are now:
>>> 1.  The developer has to know/remember to check for a valid status
>>> change, I'm willing to bet that there are numerous places where it
>>> isn't checked at the moment but should be.
>>> 2.  While generally the check is only around 8-12 lines of code, the
>>> developer has to either remember how to write the query and what error
>>> message should be displayed or find some existing code to copy/paste
>>> (is the status set, has the status changed, do the lookup, report an
>>> error).
>>>
>>> I don't think options #2 and #3 below cover problem #1 above but they
>>> may help with #2.
>>>
>>> Also another issue with StatusValidChange is that there is currently
>>> no way to make sure when creating a new record that the initial status
>>> is valid, I stumbled across this while fixing the test cases where a
>>> Shipment was being created in the SHIPMENT_PACKED status and it was
>>> subsequent ECA code that was failing.  To solve that I would like to
>>> remove the not empty constraint on StatusValidChange.statusId so that
>>> we can use the entity to indicate valid status entry points and start
>>> checking for them during record creation.
>>>
>>> My only goal with these suggestions is to try and lighten the load on
>>> the developer and this seems like a good opportunity for the framework
>>> to step in because the checks are very generic anyway.
>>>
>>> Regards
>>> Scott
>>>
>>> On 7/05/2009, at 4:56 PM, David E Jones wrote:
>>>
>>>>
>>>> A couple of notes:
>>>>
>>>> 1. if we add something to the entity engine to check this we would
>>>> need to move the Status* entities from the common component to the
>>>> entity component
>>>>
>>>> 2. I played with doing a separate method that genericized checking
>>>> the StatusValidChange, but it made the code bigger and (IMO) more
>>>> difficult to follow and customize, especially since the
>>>> StatusValidChange checking is pretty simple in the first place.
>>>> However, the code would be more generic and perhaps slightly more
>>>> simply (ie maybe not fewer lines, but some of the lines would be
>>>> less complex), so there might be some merit in it...
>>>>
>>>> 3. related to #1, but a variation on that approach: we could perhaps
>>>> have a service that checks this generically that is called through
>>>> an EECA or SECA rule, and then all we have to do is setup that ECA
>>>> rule for each entity we want checked
>>>>
>>>> -David
>>>>
>>>>
>>>> On May 6, 2009, at 9:29 PM, Scott Gray wrote:
>>>>
>>>>> Hi All
>>>>>
>>>>> Currently there is a ton of code in various places that checks to
>>>>> make sure a status change is valid using the StatusValidChange
>>>>> entity, and there are also places where there is no check even
>>>>> though records exist (createShipment for example).  I'm wondering
>>>>> we couldn't add support for this to the entity engine itself so
>>>>> that it doesn't have to be done manually, we could add some sort of
>>>>> flag to the entity field def and then GenericEntity could perform
>>>>> the check when setting the field.  Thoughts?
>>>>>
>>>>> The only thing I'm not too sure on is the purpose of the condition
>>>>> field on StatusValidChange and how it is intended to be used, there
>>>>> are no examples of its use in the existing data.
>>>>>
>>>>> Failing that I'd at least like to add a utility method and a simple
>>>>> method operation to simplify the task.
>>>>>
>>>>> Thanks
>>>>> Scott
>>>>>
>>>>> HotWax Media
>>>>> http://www.hotwaxmedia.com
>>>>>
>>>>>
>>>>>
>>>>
>>>
>> --
>> Antwebsystems.com: Quality OFBiz services for competitive rates
>>
>

--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.