Remove PartyContactMech.(months|years)WithContactMech?

[Adam Heath-2]

I noticed the 2 fields in the subject, but didn't actually recoginize
them(I've been using ofbiz for a *long* time).  I did a big of
digging, and noticed that those fields were added to the model in
2006-05-04(1), and were first utilized when anonymous checkout was
added 2006-11-28(2).  There has been no real use of the 2 fields since
then.

Why do they have to exist?  Why can't DATE_TRUNC or some other sql
function be used?  Or normal Timestamp manipulation on fromDate/thruDate?

1: http://svn.ofbiz.org/svn/ofbiz/trunk@7513
2: https://svn.apache.org/repos/asf/incubator/ofbiz/trunk@479879

[Adrian Crum-3]

 From what I recall, the idea is for a customer service person to ask
how long the customer has been at that address, and the customer would
respond with a time duration of months or years. There are no exact
dates in the scenario.

I would recommend using a TimeDuration to calculate a fromDate based on
the current date. So, the CSR enters months or years at current address,
and a service calculates PartyContactMech.fromDate based on that
information.

-Adrian

On 5/30/2012 12:34 AM, Adam Heath wrote:

> I noticed the 2 fields in the subject, but didn't actually recoginize
> them(I've been using ofbiz for a *long* time).  I did a big of
> digging, and noticed that those fields were added to the model in
> 2006-05-04(1), and were first utilized when anonymous checkout was
> added 2006-11-28(2).  There has been no real use of the 2 fields since
> then.
>
> Why do they have to exist?  Why can't DATE_TRUNC or some other sql
> function be used?  Or normal Timestamp manipulation on fromDate/thruDate?
>
> 1: http://svn.ofbiz.org/svn/ofbiz/trunk@7513
> 2: https://svn.apache.org/repos/asf/incubator/ofbiz/trunk@479879

[Scott Gray-2]

The only problem there would be that the information would need to be known when the record was created since fromDate forms part of the primary key.  It's entirely possible that the user could create the contact mech themselves via the ecommerce app and then later an external service runs to gather that type of information from an authoritative source for fraud detection purposes.  Hypothetical but entirely conceivable I would imagine.

Regards
Scott

On 30/05/2012, at 7:23 PM, Adrian Crum wrote:

> From what I recall, the idea is for a customer service person to ask how long the customer has been at that address, and the customer would respond with a time duration of months or years. There are no exact dates in the scenario.
>
> I would recommend using a TimeDuration to calculate a fromDate based on the current date. So, the CSR enters months or years at current address, and a service calculates PartyContactMech.fromDate based on that information.
>
> -Adrian
>
> On 5/30/2012 12:34 AM, Adam Heath wrote:
>> I noticed the 2 fields in the subject, but didn't actually recoginize
>> them(I've been using ofbiz for a *long* time).  I did a big of
>> digging, and noticed that those fields were added to the model in
>> 2006-05-04(1), and were first utilized when anonymous checkout was
>> added 2006-11-28(2).  There has been no real use of the 2 fields since
>> then.
>>
>> Why do they have to exist?  Why can't DATE_TRUNC or some other sql
>> function be used?  Or normal Timestamp manipulation on fromDate/thruDate?
>>
>> 1: http://svn.ofbiz.org/svn/ofbiz/trunk@7513
>> 2: https://svn.apache.org/repos/asf/incubator/ofbiz/trunk@479879

[Jacopo Cappellato-4]

On Jun 1, 2012, at 6:44 AM, Scott Gray wrote:

> The only problem there would be that the information would need to be known when the record was created since fromDate forms part of the primary key.  It's entirely possible that the user could create the contact mech themselves via the ecommerce app and then later an external service runs to gather that type of information from an authoritative source for fraud detection purposes.  Hypothetical but entirely conceivable I would imagine.
>

There is also a difference between validity dates in the system (fromDate/thruDate) and the information about the number of years/months the contact was valid in the real world.
I have to admit I was not aware of these 2 fields and at first I was inclined to remove them, but after reading the use cases from Adam and Scott I think it makes sense to leave them, or replace them with sinceYear (or similar/better name) where the use can store the year (e.g. 2003) the contact mech was used the first time and a sinceMonth field (Jan, Feb...) to be used optionally if sinceYear is set.

Regards,

Jacopo

> Regards
> Scott
>
> On 30/05/2012, at 7:23 PM, Adrian Crum wrote:
>
>> From what I recall, the idea is for a customer service person to ask how long the customer has been at that address, and the customer would respond with a time duration of months or years. There are no exact dates in the scenario.
>>
>> I would recommend using a TimeDuration to calculate a fromDate based on the current date. So, the CSR enters months or years at current address, and a service calculates PartyContactMech.fromDate based on that information.
>>
>> -Adrian
>>
>> On 5/30/2012 12:34 AM, Adam Heath wrote:
>>> I noticed the 2 fields in the subject, but didn't actually recoginize
>>> them(I've been using ofbiz for a *long* time).  I did a big of
>>> digging, and noticed that those fields were added to the model in
>>> 2006-05-04(1), and were first utilized when anonymous checkout was
>>> added 2006-11-28(2).  There has been no real use of the 2 fields since
>>> then.
>>>
>>> Why do they have to exist?  Why can't DATE_TRUNC or some other sql
>>> function be used?  Or normal Timestamp manipulation on fromDate/thruDate?
>>>
>>> 1: http://svn.ofbiz.org/svn/ofbiz/trunk@7513
>>> 2: https://svn.apache.org/repos/asf/incubator/ofbiz/trunk@479879
>

[Adam Heath-2]

On 06/01/2012 12:42 AM, Jacopo Cappellato wrote:
> On Jun 1, 2012, at 6:44 AM, Scott Gray wrote:
>
>> The only problem there would be that the information would need to be known when the record was created since fromDate forms part of the primary key.  It's entirely possible that the user could create the contact mech themselves via the ecommerce app and then later an external service runs to gather that type of information from an authoritative source for fraud detection purposes.  Hypothetical but entirely conceivable I would imagine.
>>
>
> There is also a difference between validity dates in the system (fromDate/thruDate) and the information about the number of years/months the contact was valid in the real world.
> I have to admit I was not aware of these 2 fields and at first I was inclined to remove them, but after reading the use cases from Adam and Scott I think it makes sense to leave them, or replace them with sinceYear (or similar/better name) where the use can store the year (e.g. 2003) the contact mech was used the first time and a sinceMonth field (Jan, Feb...) to be used optionally if sinceYear is set.

In Scott's scenarios, the record is created with a fromDate if 'now'.
Later, when the question is asked of the customer, a new record can be
created with the correct fromDate, and the first one deleted.

These fields have existed for a *long* time.  Ean and I were both
unaware.  You(Jacopo) were unaware.  PartyContactMech is a rather simple
entity, one that almost all of us have to interface with.  It's
surprising that we weren't aware of the 'feature'.

[Adrian Crum-3]

On 6/1/2012 6:42 AM, Jacopo Cappellato wrote:
> On Jun 1, 2012, at 6:44 AM, Scott Gray wrote:
>
>> The only problem there would be that the information would need to be known when the record was created since fromDate forms part of the primary key.  It's entirely possible that the user could create the contact mech themselves via the ecommerce app and then later an external service runs to gather that type of information from an authoritative source for fraud detection purposes.  Hypothetical but entirely conceivable I would imagine.
>>
> There is also a difference between validity dates in the system (fromDate/thruDate) and the information about the number of years/months the contact was valid in the real world.
> I have to admit I was not aware of these 2 fields and at first I was inclined to remove them, but after reading the use cases from Adam and Scott I think it makes sense to leave them, or replace them with sinceYear (or similar/better name) where the use can store the year (e.g. 2003) the contact mech was used the first time and a sinceMonth field (Jan, Feb...) to be used optionally if sinceYear is set.

sinceYear or fromYear would make more sense than the current fields. The
existing fields are meaningless without a time reference.

-Adrian

[Adam Heath-2]

On 06/01/2012 12:29 PM, Adrian Crum wrote:

>
> On 6/1/2012 6:42 AM, Jacopo Cappellato wrote:
>> On Jun 1, 2012, at 6:44 AM, Scott Gray wrote:
>>
>>> The only problem there would be that the information would need to be
>>> known when the record was created since fromDate forms part of the
>>> primary key. It's entirely possible that the user could create the
>>> contact mech themselves via the ecommerce app and then later an
>>> external service runs to gather that type of information from an
>>> authoritative source for fraud detection purposes. Hypothetical but
>>> entirely conceivable I would imagine.
>>>
>> There is also a difference between validity dates in the system
>> (fromDate/thruDate) and the information about the number of
>> years/months the contact was valid in the real world.
>> I have to admit I was not aware of these 2 fields and at first I was
>> inclined to remove them, but after reading the use cases from Adam and
>> Scott I think it makes sense to leave them, or replace them with
>> sinceYear (or similar/better name) where the use can store the year
>> (e.g. 2003) the contact mech was used the first time and a sinceMonth
>> field (Jan, Feb...) to be used optionally if sinceYear is set.
>
> sinceYear or fromYear would make more sense than the current fields. The
> existing fields are meaningless without a time reference.

Very good point.  Which means as currently implemented they at all
useful.  So, it might make sense to redo it, as how could we be
backwards compatible?

But this time, let's try to find proper use cases.  One has been given
in this thread already(I think it's not needed, however, and fromDate
can be made to handle it).

In fact, the fields are wrong anyways.  Just invent a new
ContactMechPurposeType.