Add long work instructions field to Routing Tasks

[jonwimp]

If the following has already been implemented, please let me know.

I need to attach long work instructions (like "knead dough, dunk face in it briefly, claps hand
and turn 3 times") to Routing Tasks. I'm about to add a new field to Routing Tasks (entity
WorkEffort with workEffortTypeId of ROU_TASK). The addition will be to my own code branch in the
worst case, or in OFBiz SVN if my enhancement suggestion is accepted.

Can somebody check my understanding of such additions?

I understand that adding a new nullable field say workInstructions of type "very-long" to entity
WorkEffort will not affect other applications, since use of this field will be purely optional.
Upon restarting OFBiz instances, databases (currently in use, production or test) will have the
field added (via "alter table") and set to null, which will not affect existing applications. Even
if I merge in future updates from OFBiz SVN, I'll still not face incompatibility issues, as long
as those updates do not use my field workInstructions. Or do not use in a way that's incompatible
with the way I use it.

It of course then follows that I should try to roll this enhancement, including logics using field
workInstructions, into OFBiz SVN so that we're all on the same page, and other users don't happen
to create a new field with same name and use that field as say a "date-time" instead of a "very-long".

Can somebody check my understanding above, before I create a JIRA issue to be voted on? Thanks!

Phew. Do I really have to be that detailed? I'd have preferred to say "adding new field to
WorkEffort for long work instructions. OK?". Anyway, I hope the above is clear enough, and
probably helps some newcomers catch on to some OFBiz concepts too. Or at least assures some
veterans that I "can cross the road on my own, but need help with the next steps after that"?

Jonathon

[cjhowe]

I won't speak to this specific enhancement as I
haven't explored work effort very much.  

I think you'll find the least amount of frustration by
using the <extend-entity> element in your
entitymodel.xml for your enhancements instead of
changing the entity definition in the OFBiz
entitymodel.xml files.  Couple that with the approach
in
http://ofbizwiki.go-integral.com/Wiki.jsp?page=FAQ21
and you should be able to keep your code separated
entirely from the OFBiz codebase.  Then if you want to
contribute what you've done when it's all working for
inclusion in the community project, you can either
make the changes necessary and create a patch or
simply offer your entire side project and let someone
else reincorporate it into the codebase. This will
keep you from relying on other people to review and
commit your improvements before you can move your
custom project forward.

--- Jonathon -- Improov <[hidden email]> wrote:

> If the following has already been implemented,
> please let me know.
>
> I need to attach long work instructions (like "knead
> dough, dunk face in it briefly, claps hand
> and turn 3 times") to Routing Tasks. I'm about to
> add a new field to Routing Tasks (entity
> WorkEffort with workEffortTypeId of ROU_TASK). The
> addition will be to my own code branch in the
> worst case, or in OFBiz SVN if my enhancement
> suggestion is accepted.
>
> Can somebody check my understanding of such
> additions?
>
> I understand that adding a new nullable field say
> workInstructions of type "very-long" to entity
> WorkEffort will not affect other applications, since
> use of this field will be purely optional.
> Upon restarting OFBiz instances, databases
> (currently in use, production or test) will have the
>
> field added (via "alter table") and set to null,
> which will not affect existing applications. Even
> if I merge in future updates from OFBiz SVN, I'll
> still not face incompatibility issues, as long
> as those updates do not use my field
> workInstructions. Or do not use in a way that's
> incompatible
> with the way I use it.
>
> It of course then follows that I should try to roll
> this enhancement, including logics using field
> workInstructions, into OFBiz SVN so that we're all
> on the same page, and other users don't happen
> to create a new field with same name and use that
> field as say a "date-time" instead of a "very-long".
>
> Can somebody check my understanding above, before I
> create a JIRA issue to be voted on? Thanks!
>
> Phew. Do I really have to be that detailed? I'd have
> preferred to say "adding new field to
> WorkEffort for long work instructions. OK?". Anyway,
> I hope the above is clear enough, and
> probably helps some newcomers catch on to some OFBiz
> concepts too. Or at least assures some
> veterans that I "can cross the road on my own, but
> need help with the next steps after that"?
>
> Jonathon
>

[jonwimp]

Chris,

I can't find the <extend-entity> concept at http://ofbiz.apache.org/docs/entity.html . But I did
find a few examples in Content (1), Party (7) and Product (1) modules.

Are there some docs on the usage of the <extend-entity> XML entity?

We can move this discussion into another thread if you want.

But first, let me sneak in a few quick questions! Thanks!

How does <extend-entity> work? From looks of it, it seems to simply add a new field (or fields, or
foreign keys, etc) to an existing table. The only effect this seems to achieve is to separate the
stock entity definitions from any custom entity definitions. So, though we "extend-entity"-ize the
UserLoginHistory entity (in Party module), we still get 1 (but different) table: UserLoginHistory.
Not UserLoginHistory_custom or UserLoginHistory_attr in addition to UserLoginHistory.

But still, this looks absolutely fabulous for separating my custom entity definitions from OFBiz's
entity definitions.

Thanks again, Chris!

Jonathon

Chris Howe wrote:

> I won't speak to this specific enhancement as I
> haven't explored work effort very much.  
>
> I think you'll find the least amount of frustration by
> using the <extend-entity> element in your
> entitymodel.xml for your enhancements instead of
> changing the entity definition in the OFBiz
> entitymodel.xml files.  Couple that with the approach
> in
> http://ofbizwiki.go-integral.com/Wiki.jsp?page=FAQ21
> and you should be able to keep your code separated
> entirely from the OFBiz codebase.  Then if you want to
> contribute what you've done when it's all working for
> inclusion in the community project, you can either
> make the changes necessary and create a patch or
> simply offer your entire side project and let someone
> else reincorporate it into the codebase. This will
> keep you from relying on other people to review and
> commit your improvements before you can move your
> custom project forward.

[Scott Gray]

Hi Jonathan

Why don't you use the WorkEffortNote entity?

Regards
Scott

Jonathon -- Improov wrote:

> Chris,
>
> I can't find the <extend-entity> concept at
> http://ofbiz.apache.org/docs/entity.html . But I did find a few
> examples in Content (1), Party (7) and Product (1) modules.
>
> Are there some docs on the usage of the <extend-entity> XML entity?
>
> We can move this discussion into another thread if you want.
>
> But first, let me sneak in a few quick questions! Thanks!
>
> How does <extend-entity> work? From looks of it, it seems to simply
> add a new field (or fields, or foreign keys, etc) to an existing
> table. The only effect this seems to achieve is to separate the stock
> entity definitions from any custom entity definitions. So, though we
> "extend-entity"-ize the UserLoginHistory entity (in Party module), we
> still get 1 (but different) table: UserLoginHistory. Not
> UserLoginHistory_custom or UserLoginHistory_attr in addition to
> UserLoginHistory.
>
> But still, this looks absolutely fabulous for separating my custom
> entity definitions from OFBiz's entity definitions.
>
> Thanks again, Chris!
>
> Jonathon
>
> Chris Howe wrote:
>> I won't speak to this specific enhancement as I
>> haven't explored work effort very much.
>> I think you'll find the least amount of frustration by
>> using the <extend-entity> element in your
>> entitymodel.xml for your enhancements instead of
>> changing the entity definition in the OFBiz
>> entitymodel.xml files.  Couple that with the approach
>> in
>> http://ofbizwiki.go-integral.com/Wiki.jsp?page=FAQ21
>> and you should be able to keep your code separated
>> entirely from the OFBiz codebase.  Then if you want to
>> contribute what you've done when it's all working for
>> inclusion in the community project, you can either
>> make the changes necessary and create a patch or
>> simply offer your entire side project and let someone
>> else reincorporate it into the codebase. This will
>> keep you from relying on other people to review and
>> commit your improvements before you can move your
>> custom project forward.
>

[cjhowe]

--- Jonathon -- Improov <[hidden email]> wrote:

> Chris,
>
> I can't find the <extend-entity> concept at
> http://ofbiz.apache.org/docs/entity.html . But I did
>

<extend-entity> is a rather recent edition and that
document appears to have been last updated in 2004.
While there should probably be a few short words said
about it in the wiki(docs.ofbiz.org) at the very
least...all documentation is a work in progress.

> find a few examples in Content (1), Party (7) and
> Product (1) modules.
>
> Are there some docs on the usage of the
> <extend-entity> XML entity?
>
> We can move this discussion into another thread if
> you want.
>
> But first, let me sneak in a few quick questions!
> Thanks!
>
> How does <extend-entity> work? From looks of it, it
> seems to simply add a new field (or fields, or
> foreign keys, etc) to an existing table.

That's exactly how it works :-) .  Don't you just love
it when code is implemented the way it looks?  Almost
give credence to the concept that code should be well
written enough so that it doesn't need
commenting..._almost, but not really.

> The only
> effect this seems to achieve is to separate the
> stock entity definitions from any custom entity
> definitions. So, though we "extend-entity"-ize the
> UserLoginHistory entity (in Party module), we still
> get 1 (but different) table: UserLoginHistory.
> Not UserLoginHistory_custom or UserLoginHistory_attr
> in addition to UserLoginHistory.
>

If you want to create a seperate table for your
additions, you can always create a table with a
one-to-one relationship with your target table.
Unless you're wanting to segregate denormalized data,
I'm not sure I see much benefit in doing that over
using extend-entity.

> But still, this looks absolutely fabulous for
> separating my custom entity definitions from OFBiz's
>
> entity definitions.
>
> Thanks again, Chris!
>
> Jonathon
>

[jonwimp]

Scott,

Ok, I'll use that. Seems like nothing in OFBiz is currently using that (not creating, querying but
not displaying). Confirm?

Jonathon

Scott Gray wrote:

> Hi Jonathan
>
> Why don't you use the WorkEffortNote entity?
>
> Regards
> Scott
>
> Jonathon -- Improov wrote:
>> Chris,
>>
>> I can't find the <extend-entity> concept at
>> http://ofbiz.apache.org/docs/entity.html . But I did find a few
>> examples in Content (1), Party (7) and Product (1) modules.
>>
>> Are there some docs on the usage of the <extend-entity> XML entity?
>>
>> We can move this discussion into another thread if you want.
>>
>> But first, let me sneak in a few quick questions! Thanks!
>>
>> How does <extend-entity> work? From looks of it, it seems to simply
>> add a new field (or fields, or foreign keys, etc) to an existing
>> table. The only effect this seems to achieve is to separate the stock
>> entity definitions from any custom entity definitions. So, though we
>> "extend-entity"-ize the UserLoginHistory entity (in Party module), we
>> still get 1 (but different) table: UserLoginHistory. Not
>> UserLoginHistory_custom or UserLoginHistory_attr in addition to
>> UserLoginHistory.
>>
>> But still, this looks absolutely fabulous for separating my custom
>> entity definitions from OFBiz's entity definitions.
>>
>> Thanks again, Chris!
>>
>> Jonathon
>>
>> Chris Howe wrote:
>>> I won't speak to this specific enhancement as I
>>> haven't explored work effort very much. I think you'll find the least
>>> amount of frustration by
>>> using the <extend-entity> element in your
>>> entitymodel.xml for your enhancements instead of
>>> changing the entity definition in the OFBiz
>>> entitymodel.xml files.  Couple that with the approach
>>> in
>>> http://ofbizwiki.go-integral.com/Wiki.jsp?page=FAQ21
>>> and you should be able to keep your code separated
>>> entirely from the OFBiz codebase.  Then if you want to
>>> contribute what you've done when it's all working for
>>> inclusion in the community project, you can either
>>> make the changes necessary and create a patch or
>>> simply offer your entire side project and let someone
>>> else reincorporate it into the codebase. This will
>>> keep you from relying on other people to review and
>>> commit your improvements before you can move your
>>> custom project forward.
>>
>
>

[Scott Gray]

Looks about right to me

Regards
Scott

Jonathon -- Improov wrote:

> Scott,
>
> Ok, I'll use that. Seems like nothing in OFBiz is currently using that
> (not creating, querying but not displaying). Confirm?
>
> Jonathon
>
> Scott Gray wrote:
>> Hi Jonathan
>>
>> Why don't you use the WorkEffortNote entity?
>>
>> Regards
>> Scott
>>
>> Jonathon -- Improov wrote:
>>> Chris,
>>>
>>> I can't find the <extend-entity> concept at
>>> http://ofbiz.apache.org/docs/entity.html . But I did find a few
>>> examples in Content (1), Party (7) and Product (1) modules.
>>>
>>> Are there some docs on the usage of the <extend-entity> XML entity?
>>>
>>> We can move this discussion into another thread if you want.
>>>
>>> But first, let me sneak in a few quick questions! Thanks!
>>>
>>> How does <extend-entity> work? From looks of it, it seems to simply
>>> add a new field (or fields, or foreign keys, etc) to an existing
>>> table. The only effect this seems to achieve is to separate the
>>> stock entity definitions from any custom entity definitions. So,
>>> though we "extend-entity"-ize the UserLoginHistory entity (in Party
>>> module), we still get 1 (but different) table: UserLoginHistory. Not
>>> UserLoginHistory_custom or UserLoginHistory_attr in addition to
>>> UserLoginHistory.
>>>
>>> But still, this looks absolutely fabulous for separating my custom
>>> entity definitions from OFBiz's entity definitions.
>>>
>>> Thanks again, Chris!
>>>
>>> Jonathon
>>>
>>> Chris Howe wrote:
>>>> I won't speak to this specific enhancement as I
>>>> haven't explored work effort very much. I think you'll find the
>>>> least amount of frustration by
>>>> using the <extend-entity> element in your
>>>> entitymodel.xml for your enhancements instead of
>>>> changing the entity definition in the OFBiz
>>>> entitymodel.xml files.  Couple that with the approach
>>>> in
>>>> http://ofbizwiki.go-integral.com/Wiki.jsp?page=FAQ21
>>>> and you should be able to keep your code separated
>>>> entirely from the OFBiz codebase.  Then if you want to
>>>> contribute what you've done when it's all working for
>>>> inclusion in the community project, you can either
>>>> make the changes necessary and create a patch or
>>>> simply offer your entire side project and let someone
>>>> else reincorporate it into the codebase. This will
>>>> keep you from relying on other people to review and
>>>> commit your improvements before you can move your
>>>> custom project forward.
>>>
>>
>>
>
>