Dev - Extending WorkEffort Entity Models

[Brett]

I'm looking for a review of the following WorkEffort (WE) entities to
extend the existing WE schema.  The purpose of these new entities is
as follows:

1. Integrating subtypes into the existing WE.
The ofbiz WE schema is good at generalizing WEs by creating subtypes
like program, project, phase, activity, and task. But often these
subtypes include more (or different) fields than are currently defined
in the WE entity.  For example, if I was writing a bug tracking system
I might include fields like:

- summary
- description
- status
- priority
- version
- notes, etc.

A ticket system for a call center might include fields like:

- incident number
- customer contact
- customer comments
- resolution
- assigned to
etc.

Both systems are WEs and the difference between them is the
information that is tracked and the workflow that would be programmed
for the application.

I would like to add records that could be added to the WE schema
without changing the general behavior of the WE entities or services.
Using the example of the bug tracking system, I would like to create a
general "defect" record with various fields/entities and integrate it
into the WE schema.  My initial idea was to just create the new entity
and use relationships to tie it into the WE.  Then I only have to
customize the services that support that new entity.  The existing WE
services would work as normal.

Has anyone tried to do this with this with the WE schema?  Any
problems with the above proposal?


2. WorkEffortHistory
Another often requested feature in ERP packages is tracking the
history of the workeffort.  In a bug tracking system a manager may
want to know who opened a particular bug and then who closed it.  A
WorkEffortHistory entity could be used to store this information. This
entity isn't too complicated except if you include my first
recommended extension above and try to generalize a WorkEffortHistory
to support any type of WE record.  Here is my initial proposed fields
for this entity:

- ModifiedTime (DTS)
- entity_name – meta data describing the entity where the field is located
- field_name – the actual field name
- new_value – String representation of the new field value
- field_type -  meta data describing the field type (number, string, blob)

The problem with the above solution is that it potentially breaks
normalization rules.
The benefit is that you have a generalized WorkEffortHistory that can
track changes for any field in a WE.

Suggestions on the above WE extensions is always welcome.


Thanks,


Brett
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

Brett,

1. The best entity to use for issue tracking is the "CustRequest" entity. It has fields along these lines and is what we have planned to use for issue tracking for software projects or customer services or whatever. It is separate from, but can certainly be related to, WorkEffort records. This is one thing that is often missing from many simple issue tracking systems, ie a separation between what is requested and what is planned, and for the plans an ability to have hierarchical plans (WorkEfforts) and such.

2. Do we really want to track every change of every field? In some cases perhaps, but I don't know about everywhere. It is common in OFBiz to have a *Status entity that keeps a status history, and this could also tracked who effected the status change.

-David


Brett Palmer wrote:

> I'm looking for a review of the following WorkEffort (WE) entities to
> extend the existing WE schema.  The purpose of these new entities is
> as follows:
>
> 1. Integrating subtypes into the existing WE.
> The ofbiz WE schema is good at generalizing WEs by creating subtypes
> like program, project, phase, activity, and task. But often these
> subtypes include more (or different) fields than are currently defined
> in the WE entity.  For example, if I was writing a bug tracking system
> I might include fields like:
>
> - summary
> - description
> - status
> - priority
> - version
> - notes, etc.
>
> A ticket system for a call center might include fields like:
>
> - incident number
> - customer contact
> - customer comments
> - resolution
> - assigned to
> etc.
>
> Both systems are WEs and the difference between them is the
> information that is tracked and the workflow that would be programmed
> for the application.
>
> I would like to add records that could be added to the WE schema
> without changing the general behavior of the WE entities or services.
> Using the example of the bug tracking system, I would like to create a
> general "defect" record with various fields/entities and integrate it
> into the WE schema.  My initial idea was to just create the new entity
> and use relationships to tie it into the WE.  Then I only have to
> customize the services that support that new entity.  The existing WE
> services would work as normal.
>
> Has anyone tried to do this with this with the WE schema?  Any
> problems with the above proposal?
>
>
> 2. WorkEffortHistory
> Another often requested feature in ERP packages is tracking the
> history of the workeffort.  In a bug tracking system a manager may
> want to know who opened a particular bug and then who closed it.  A
> WorkEffortHistory entity could be used to store this information. This
> entity isn't too complicated except if you include my first
> recommended extension above and try to generalize a WorkEffortHistory
> to support any type of WE record.  Here is my initial proposed fields
> for this entity:
>
> - ModifiedTime (DTS)
> - entity_name – meta data describing the entity where the field is located
> - field_name – the actual field name
> - new_value – String representation of the new field value
> - field_type -  meta data describing the field type (number, string, blob)
>
> The problem with the above solution is that it potentially breaks
> normalization rules.
> The benefit is that you have a generalized WorkEffortHistory that can
> track changes for any field in a WE.
>
> Suggestions on the above WE extensions is always welcome.
>
>
> Thanks,
>
>
> Brett
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Brett]

See comments inline:

On 3/23/06, David E. Jones <[hidden email]> wrote:
> Brett,
>
> 1. The best entity to use for issue tracking is the "CustRequest" entity. It has fields along these lines and is what we have planned to use for issue tracking for software projects or customer services or whatever. It is separate from, but can certainly be related to, WorkEffort records. This is one thing that is often missing from many simple issue tracking systems, ie a separation between what is requested and what is planned, and for the plans an ability to have hierarchical plans (WorkEfforts) and such.

Thanks for the information.  I remember seeing the CustRequest entity.
 I will look into it.

>
> 2. Do we really want to track every change of every field? In some cases perhaps, but I don't know about everywhere. It is common in OFBiz to have a *Status entity that keeps a status history, and this could also tracked who effected the status change.
>

Probably not normally, but I didn't want to limit it to only a
specific fixed field.

The limitation with many WorkEffort applications is their inability to
customize the different fields of the WorkEffort.  The end result is
complete re-writes of applications that essentially do the same thing
but vary on what they track - sourceforge is full of projects like
this.

What I often hear from customers that are looking for a particular
WorkEffort application is "I would use application X if it would
support field X, Y, and Z, but it ony has fields A, B, and C".  This
is why I was recommending some extensions to allow for variations in
what was tracked in a given WorkEffort.  One of the features that I
believe has made enterprise ERP applications like Vantive, PeopleSoft,
Seibel, and Remedy (I think Oracle owns all of them now) so successful
is their ability to add fields and change workflow based on the needs
of the customer.  These ERP package have an out of the box application
that work but then the customer can modify it with their tools to meet
their needs.  Realizing of course that the application cost several
million dollars to deploy and the technicians trained to make the
customization can charge $250/hour, so in the end you get what you pay
for.

Having worked on many of these commerical solutions, I believe that
ofbiz can create the equivalent type of applications.  The main
difference I see between commercial ERP and ofbiz is just more tools
to help a non-programmer get a system running.  I think in time all
those tools will be available in ofbiz as well.


Brett

> -David
>
>
> Brett Palmer wrote:
> > I'm looking for a review of the following WorkEffort (WE) entities to
> > extend the existing WE schema.  The purpose of these new entities is
> > as follows:
> >
> > 1. Integrating subtypes into the existing WE.
> > The ofbiz WE schema is good at generalizing WEs by creating subtypes
> > like program, project, phase, activity, and task. But often these
> > subtypes include more (or different) fields than are currently defined
> > in the WE entity.  For example, if I was writing a bug tracking system
> > I might include fields like:
> >
> > - summary
> > - description
> > - status
> > - priority
> > - version
> > - notes, etc.
> >
> > A ticket system for a call center might include fields like:
> >
> > - incident number
> > - customer contact
> > - customer comments
> > - resolution
> > - assigned to
> > etc.
> >
> > Both systems are WEs and the difference between them is the
> > information that is tracked and the workflow that would be programmed
> > for the application.
> >
> > I would like to add records that could be added to the WE schema
> > without changing the general behavior of the WE entities or services.
> > Using the example of the bug tracking system, I would like to create a
> > general "defect" record with various fields/entities and integrate it
> > into the WE schema.  My initial idea was to just create the new entity
> > and use relationships to tie it into the WE.  Then I only have to
> > customize the services that support that new entity.  The existing WE
> > services would work as normal.
> >
> > Has anyone tried to do this with this with the WE schema?  Any
> > problems with the above proposal?
> >
> >
> > 2. WorkEffortHistory
> > Another often requested feature in ERP packages is tracking the
> > history of the workeffort.  In a bug tracking system a manager may
> > want to know who opened a particular bug and then who closed it.  A
> > WorkEffortHistory entity could be used to store this information. This
> > entity isn't too complicated except if you include my first
> > recommended extension above and try to generalize a WorkEffortHistory
> > to support any type of WE record.  Here is my initial proposed fields
> > for this entity:
> >
> > - ModifiedTime (DTS)
> > - entity_name – meta data describing the entity where the field is located
> > - field_name – the actual field name
> > - new_value – String representation of the new field value
> > - field_type -  meta data describing the field type (number, string, blob)
> >
> > The problem with the above solution is that it potentially breaks
> > normalization rules.
> > The benefit is that you have a generalized WorkEffortHistory that can
> > track changes for any field in a WE.
> >
> > Suggestions on the above WE extensions is always welcome.
> >
> >
> > Thanks,
> >
> >
> > Brett
> >
> > _______________________________________________
> > Dev mailing list
> > [hidden email]
> > http://lists.ofbiz.org/mailman/listinfo/dev
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

Brett Palmer wrote:

> Probably not normally, but I didn't want to limit it to only a
> specific fixed field.
>
> The limitation with many WorkEffort applications is their inability to
> customize the different fields of the WorkEffort.  The end result is
> complete re-writes of applications that essentially do the same thing
> but vary on what they track - sourceforge is full of projects like
> this.
>
> What I often hear from customers that are looking for a particular
> WorkEffort application is "I would use application X if it would
> support field X, Y, and Z, but it ony has fields A, B, and C".  This
> is why I was recommending some extensions to allow for variations in
> what was tracked in a given WorkEffort.  One of the features that I
> believe has made enterprise ERP applications like Vantive, PeopleSoft,
> Seibel, and Remedy (I think Oracle owns all of them now) so successful
> is their ability to add fields and change workflow based on the needs
> of the customer.  These ERP package have an out of the box application
> that work but then the customer can modify it with their tools to meet
> their needs.  Realizing of course that the application cost several
> million dollars to deploy and the technicians trained to make the
> customization can charge $250/hour, so in the end you get what you pay
> for.
>
> Having worked on many of these commerical solutions, I believe that
> ofbiz can create the equivalent type of applications.  The main
> difference I see between commercial ERP and ofbiz is just more tools
> to help a non-programmer get a system running.  I think in time all
> those tools will be available in ofbiz as well.

Right now the intention with the OFBiz framework is to be able to this easily, but still keep these fields in real database columns and such. With the XML entity def files it is pretty easily to add a field and manage it just like every other field. There isn't a visual tool for doing this, which I think is what you might be referring to, but hopefully that will come a long sooner or later. In the mean time OFBiz is still a heck of a lot cheaper and more efficient to customize.

In the mean time I think anyone who is worth $250/hr can probably navigate the raw XML files faster than with a visual tool. Of course, it depends on the tool. I think even for those used to the XML files and working with them directly having a navigation tool would be helpful.

-David

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev