Marketing campaigns and contact lists

[Ean Schuessler]

Currently, contact lists are associated with marketing campaigns via a contactListId field on ContactList. It seems to me that contact lists would be used repeatedly over a long period of time by numerous campaigns. Would there be an objection to deprecating the marketingCampaignId field in ContactList and creating a new MarketingCampaignContactList entity? I would imagine that this entity would follow the fromDate/thruDate pattern.

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com 

[BJ Freeman]

how about a contactlistappl that other entities can use in the future
change the contactlistid to the contactlistappl.
then would also a allow a upfrade path with a service.


Ean Schuessler sent the following on 12/12/2010 4:50 PM:
> Currently, contact lists are associated with marketing campaigns via a contactListId field on ContactList. It seems to me that contact lists would be used repeatedly over a long period of time by numerous campaigns. Would there be an objection to deprecating the marketingCampaignId field in ContactList and creating a new MarketingCampaignContactList entity? I would imagine that this entity would follow the fromDate/thruDate pattern.
>

[Ean Schuessler]

Calling it an "application" seems fine. Is there a good example of an upgradeable multi-table application?
----- "BJ Freeman" wrote:
> how about a contactlistappl that other entities can use in the future
> change the contactlistid to the contactlistappl.
> then would also a allow a upfrade path with a service.
> Ean Schuessler sent the following on 12/12/2010 4:50 PM:
> > Currently, contact lists are associated with marketing campaigns via a contactListId field on ContactList. It seems to me that contact lists would be used repeatedly over a long period of time by numerous campaigns. Would there be an objection to deprecating the marketingCampaignId field in ContactList and creating a new MarketingCampaignContactList entity? I would imagine that this entity would follow the fromDate/thruDate pattern.
> >

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com 

[BJ Freeman]

the appl as I understand it is a many to many interface.
to my knowledge no one has discussed migration, in detail, as an
(semi)automated process but I think it would be a good thread.

=========================
BJ Freeman
Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com  <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man


Ean Schuessler sent the following on 12/13/2010 4:57 AM:

>
> Calling it an "application" seems fine. Is there a good example of an upgradeable multi-table application?
> ----- "BJ Freeman" wrote:
>> how about a contactlistappl that other entities can use in the future
>> change the contactlistid to the contactlistappl.
>> then would also a allow a upfrade path with a service.
>> Ean Schuessler sent the following on 12/12/2010 4:50 PM:
>>> Currently, contact lists are associated with marketing campaigns via a contactListId field on ContactList. It seems to me that contact lists would be used repeatedly over a long period of time by numerous campaigns. Would there be an objection to deprecating the marketingCampaignId field in ContactList and creating a new MarketingCampaignContactList entity? I would imagine that this entity would follow the fromDate/thruDate pattern.
>>>
>

[Ean Schuessler]

MarketingCampaignContactList makes more sense to me.

It seems in line with tables such as PartyContactMech or
ProductStoreCatalog.

On 12/13/10 10:33, BJ Freeman wrote:
> the appl as I understand it is a many to many interface.
> to my knowledge no one has discussed migration, in detail, as an
> (semi)automated process but I think it would be a good thread.

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

[BJ Freeman]

Contact list can be used for many operations.
with a many to many relationship then it is achieved with out extra
entities.
Unless you are adding other fields then there maybe a reason.
the model from the data model book is to use enumeration and types to
define extra info.

just sharing, not against you doing it that way.

=========================
BJ Freeman
Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com  <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man


Ean Schuessler sent the following on 12/13/2010 4:10 PM:

> MarketingCampaignContactList makes more sense to me.
>
> It seems in line with tables such as PartyContactMech or
> ProductStoreCatalog.
>
> On 12/13/10 10:33, BJ Freeman wrote:
>> the appl as I understand it is a many to many interface.
>> to my knowledge no one has discussed migration, in detail, as an
>> (semi)automated process but I think it would be a good thread.
>

[Bruno Busco]

IMO the complete contactlist package should be moved away from the marketing
component and put in party.
The reason of this is that a contactlist could be used to notify a group of
users of something appening in ANY application.

This could be also considered for the framework-only installation.
What do you think about?

Regards,
Bruno


2010/12/14 BJ Freeman <[hidden email]>

> Contact list can be used for many operations.
> with a many to many relationship then it is achieved with out extra
> entities.
> Unless you are adding other fields then there maybe a reason.
> the model from the data model book is to use enumeration and types to
> define extra info.
>
> just sharing, not against you doing it that way.
>
>
> =========================
> BJ Freeman
> Strategic Power Office with Supplier Automation  <
> http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> Specialtymarket.com  <http://www.specialtymarket.com/>
> Systems Integrator-- Glad to Assist
>
> Chat  Y! messenger: bjfr33man
>
>
> Ean Schuessler sent the following on 12/13/2010 4:10 PM:
>
>  MarketingCampaignContactList makes more sense to me.
>>
>> It seems in line with tables such as PartyContactMech or
>> ProductStoreCatalog.
>>
>> On 12/13/10 10:33, BJ Freeman wrote:
>>
>>> the appl as I understand it is a many to many interface.
>>> to my knowledge no one has discussed migration, in detail, as an
>>> (semi)automated process but I think it would be a good thread.
>>>
>>
>>
>

[hans_bakker]

That is fine if you let me commit the contactlist upgrades from chattree
this week...?

On Sat, 2010-12-18 at 10:31 +0100, Bruno Busco wrote:

> IMO the complete contactlist package should be moved away from the marketing
> component and put in party.
> The reason of this is that a contactlist could be used to notify a group of
> users of something appening in ANY application.
>
> This could be also considered for the framework-only installation.
> What do you think about?
>
> Regards,
> Bruno
>
>
> 2010/12/14 BJ Freeman <[hidden email]>
>
> > Contact list can be used for many operations.
> > with a many to many relationship then it is achieved with out extra
> > entities.
> > Unless you are adding other fields then there maybe a reason.
> > the model from the data model book is to use enumeration and types to
> > define extra info.
> >
> > just sharing, not against you doing it that way.
> >
> >
> > =========================
> > BJ Freeman
> > Strategic Power Office with Supplier Automation  <
> > http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> > Specialtymarket.com  <http://www.specialtymarket.com/>
> > Systems Integrator-- Glad to Assist
> >
> > Chat  Y! messenger: bjfr33man
> >
> >
> > Ean Schuessler sent the following on 12/13/2010 4:10 PM:
> >
> >  MarketingCampaignContactList makes more sense to me.
> >>
> >> It seems in line with tables such as PartyContactMech or
> >> ProductStoreCatalog.
> >>
> >> On 12/13/10 10:33, BJ Freeman wrote:
> >>
> >>> the appl as I understand it is a many to many interface.
> >>> to my knowledge no one has discussed migration, in detail, as an
> >>> (semi)automated process but I think it would be a good thread.
> >>>
> >>
> >>
> >

--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Myself on twitter: http://twitter.com/hansbak
Antwebsystems.com: Quality services for competitive rates.

[Bruno Busco]

Sure, we could move the whole staff, after the patch is committed.

Regards,
Bruno


2010/12/18 Hans Bakker <[hidden email]>

> That is fine if you let me commit the contactlist upgrades from chattree
> this week...?
>
> On Sat, 2010-12-18 at 10:31 +0100, Bruno Busco wrote:
> > IMO the complete contactlist package should be moved away from the
> marketing
> > component and put in party.
> > The reason of this is that a contactlist could be used to notify a group
> of
> > users of something appening in ANY application.
> >
> > This could be also considered for the framework-only installation.
> > What do you think about?
> >
> > Regards,
> > Bruno
> >
> >
> > 2010/12/14 BJ Freeman <[hidden email]>
> >
> > > Contact list can be used for many operations.
> > > with a many to many relationship then it is achieved with out extra
> > > entities.
> > > Unless you are adding other fields then there maybe a reason.
> > > the model from the data model book is to use enumeration and types to
> > > define extra info.
> > >
> > > just sharing, not against you doing it that way.
> > >
> > >
> > > =========================
> > > BJ Freeman
> > > Strategic Power Office with Supplier Automation  <
> > > http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> > > Specialtymarket.com  <http://www.specialtymarket.com/>
> > > Systems Integrator-- Glad to Assist
> > >
> > > Chat  Y! messenger: bjfr33man
> > >
> > >
> > > Ean Schuessler sent the following on 12/13/2010 4:10 PM:
> > >
> > >  MarketingCampaignContactList makes more sense to me.
> > >>
> > >> It seems in line with tables such as PartyContactMech or
> > >> ProductStoreCatalog.
> > >>
> > >> On 12/13/10 10:33, BJ Freeman wrote:
> > >>
> > >>> the appl as I understand it is a many to many interface.
> > >>> to my knowledge no one has discussed migration, in detail, as an
> > >>> (semi)automated process but I think it would be a good thread.
> > >>>
> > >>
> > >>
> > >
>
> --
> Ofbiz on twitter: http://twitter.com/apache_ofbiz
> Myself on twitter: http://twitter.com/hansbak
> Antwebsystems.com <http://twitter.com/hansbak%0AAntwebsystems.com>:
> Quality services for competitive rates.
>
>

[BJ Freeman]

+1 for party
not sure framework needs the contactlist to operate but considering the
pattern of putting things in common that is a possibility.
if put in framework a text readme should include where it was put for
those that may look for it in party.


=========================
BJ Freeman
Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com  <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man


Bruno Busco sent the following on 12/18/2010 1:31 AM:

> IMO the complete contactlist package should be moved away from the marketing
> component and put in party.
> The reason of this is that a contactlist could be used to notify a group of
> users of something appening in ANY application.
>
> This could be also considered for the framework-only installation.
> What do you think about?
>
> Regards,
> Bruno
>
>
> 2010/12/14 BJ Freeman<[hidden email]>
>
>> Contact list can be used for many operations.
>> with a many to many relationship then it is achieved with out extra
>> entities.
>> Unless you are adding other fields then there maybe a reason.
>> the model from the data model book is to use enumeration and types to
>> define extra info.
>>
>> just sharing, not against you doing it that way.
>>
>>
>> =========================
>> BJ Freeman
>> Strategic Power Office with Supplier Automation<
>> http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>> Specialtymarket.com<http://www.specialtymarket.com/>
>> Systems Integrator-- Glad to Assist
>>
>> Chat  Y! messenger: bjfr33man
>>
>>
>> Ean Schuessler sent the following on 12/13/2010 4:10 PM:
>>
>>   MarketingCampaignContactList makes more sense to me.
>>>
>>> It seems in line with tables such as PartyContactMech or
>>> ProductStoreCatalog.
>>>
>>> On 12/13/10 10:33, BJ Freeman wrote:
>>>
>>>> the appl as I understand it is a many to many interface.
>>>> to my knowledge no one has discussed migration, in detail, as an
>>>> (semi)automated process but I think it would be a good thread.
>>>>
>>>
>>>
>>
>

[Bruno Busco]

Yes BJ,
putting it in the framework instead of party was next option.
This can be considered now that also Adrian is trying to split party and
move some of it in common (at least I understood this was his idea).

-Bruno

2010/12/18 BJ Freeman <[hidden email]>

> +1 for party
> not sure framework needs the contactlist to operate but considering the
> pattern of putting things in common that is a possibility.
> if put in framework a text readme should include where it was put for those
> that may look for it in party.
>
>
>
> =========================
> BJ Freeman
> Strategic Power Office with Supplier Automation  <
> http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> Specialtymarket.com  <http://www.specialtymarket.com/>
> Systems Integrator-- Glad to Assist
>
> Chat  Y! messenger: bjfr33man
>
>
> Bruno Busco sent the following on 12/18/2010 1:31 AM:
>
>  IMO the complete contactlist package should be moved away from the
>> marketing
>> component and put in party.
>> The reason of this is that a contactlist could be used to notify a group
>> of
>> users of something appening in ANY application.
>>
>> This could be also considered for the framework-only installation.
>> What do you think about?
>>
>> Regards,
>> Bruno
>>
>>
>> 2010/12/14 BJ Freeman<[hidden email]>
>>
>>  Contact list can be used for many operations.
>>> with a many to many relationship then it is achieved with out extra
>>> entities.
>>> Unless you are adding other fields then there maybe a reason.
>>> the model from the data model book is to use enumeration and types to
>>> define extra info.
>>>
>>> just sharing, not against you doing it that way.
>>>
>>>
>>> =========================
>>> BJ Freeman
>>> Strategic Power Office with Supplier Automation<
>>> http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>> Specialtymarket.com<http://www.specialtymarket.com/>
>>> Systems Integrator-- Glad to Assist
>>>
>>> Chat  Y! messenger: bjfr33man
>>>
>>>
>>> Ean Schuessler sent the following on 12/13/2010 4:10 PM:
>>>
>>>  MarketingCampaignContactList makes more sense to me.
>>>
>>>>
>>>> It seems in line with tables such as PartyContactMech or
>>>> ProductStoreCatalog.
>>>>
>>>> On 12/13/10 10:33, BJ Freeman wrote:
>>>>
>>>>  the appl as I understand it is a many to many interface.
>>>>> to my knowledge no one has discussed migration, in detail, as an
>>>>> (semi)automated process but I think it would be a good thread.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>