I totally agree.
Unfortunately in the manufacturing component it is even worse than
this: the parentId is used for some of the associations (if I am not
wrong, between a production run and its tasks) while the
WorkEffortAssoc is used for others (routing to routing tasks
associations, etc...); this has been done in this way in the early
days of the manufacturing component and it should really fixed... I
hope to find some time to work on it in the few weeks/months.
Jacopo
On Jul 15, 2008, at 6:15 PM, David E Jones wrote:
Just like with Product and ProductCategory going through
ProductCategoryMember, when two WorkEfforts are associated they
should always go through WorkEffortAssoc.
I don't know why the decision was made in the Project Manager
specialpurpose application to use the workEffortParentId, but it
shouldn't have been used there. You'll notice in the workeffort
component and webapp for the child WorkEffort tree it uses the
WorkEffortAssoc, and that is how it should be.
Just as with products and categories the use of this direct fields
is for going in the other direction, in other words when going up
the tree when you want a single WorkEffort record. When going down
the tree you should always use WorkEffortAssoc (just like you would
always use ProductCategoryRollup). When going up the tree and you
want the multiple parents always use WorkEffortAssoc. When you want
to specify one of the various parent WorkEfforts already setup in
WorkEffortAssoc that is the primary parent or the like then use the
workEffortParentId.
-David
On Jul 15, 2008, at 4:35 AM, Ashish Vijaywargiya wrote:
Thanks Jacopo for your comments.
Let's see what other has to say about workEffortParentId field.
On Tue, Jul 15, 2008 at 3:51 PM, Jacopo Cappellato <
[EMAIL PROTECTED]> wrote:
I have to admit that I don't like very much the workEffortParentId
field
and the way it is used; it would be better if the WorkEffortAssoc
entity was
used every time you have to specify an association between work
effort: in
this way you'll have the ability to set the type ofassociation and
also
validity dates.
Sometimes having denormalized fields is useful (to speed up
queries and
simplify code) but unfortunately the workEffortParentId field is
not used
only for this and it is used a lot, especially by the manufacturing
component, ven when the WorkEffortAssoc would do much more sense.
My general suggestion would be that of using WorkEffortAssoc as
much as
possible (especially for new code/features).
Jacopo
On Jul 15, 2008, at 11:46 AM, Ashish Vijaywargiya wrote:
Can anybody having good insight on WorkEffort module put some
comments to
understand this scenario ?
I am also interested to know about it.
Thanks !!!
On Sat, Jun 14, 2008 at 8:46 PM, Rishi Solanki <[EMAIL PROTECTED]
>
wrote:
Hello All,
We have *WorkEffort* Entity in OFBiz in which we maintain a
recursive
relation ship using attribute *parentWorkEffortId.*
Here we again have the *WorkEffortAssoc *in which we again
relate two
workeffort by using the *workEffortFrom *and* workEffortTo.*
Now my question is like that, if we have a relationship to
relate the
workEffortId by it self ( i.e by an another workEffortId ), then
why we
need
the
*WorkEffortAssoc *for the same purpose.
*Or it is for handeling a different scenario in (OFBiz Work
Effort Data
Modeling).
**
*
*Thanks and Regards
[Rishi Solanki]*
--
Ashish Vijaywargiya
Indore, India
http://en.wikipedia.org/wiki/Indore
--
Ashish Vijaywargiya
Indore, India
http://en.wikipedia.org/wiki/Indore
