You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Andrew Sykes <an...@sykesdevelopment.com> on 2006/06/30 15:46:30 UTC
Subscription entity
Hi Folks,
I was thinking that it might be a good idea to add an autoRenew
attribute to the Subscription entity so that subscriptions could be
identified as being automatically renewable.
We could then create a service that queried the Subscriptions daily and
if one will expire in the next 24 hours and has autoRenew=Y, we could
try to re-bill the user.
Also, a service that cancelled the subscription, "cancelSubscription"
with a timestamp argument to update the Subscription.thruDate
This service would set autoRenew="N" and thruDate="timestamp"
if the timestamp is not present thruDate would be unchanged.
Any thoughts?
--
Kind Regards
Andrew Sykes <an...@sykesdevelopment.com>
Sykes Development Ltd
http://www.sykesdevelopment.com
Re: Subscription entity
Posted by BJ Freeman <bj...@free-man.net>.
is there a jira for this?
Al Byers sent the following on 6/30/2006 11:13 AM:
> Hi Andrew,
>
> I just started working with subscriptions, too. Hopefully, David will
> comment if he is not too busy, but in case he doesn't I will tell you
> what I know. I was thinking like you, only I thought maybe Subscription
> should have a recurrenceInfoId field, as RecurrenceInfo entity already
> exists and is set up to handle this. The place that there is an
> instance of recurrenceInfoId is in ShoppingList which is what David told
> me could be used to set up recurring Subscriptions.
>
> I have not yet looked around for supporting services and such, but I
> would be interested in collaborating with you and anyone else working in
> this field to get a good solution. I am guessing that there are existing
> services to support ShoppingList use; I will be looking today. The
> ProductSubscriptionResource entity replaces ProductContent. It is more
> flexible.
>
> I started this email before David responded. I will send it anyway so
> that you and I and any one else can collaborate, if desired. I am
> wondering if there are some admin screen that need to be done?
>
> -Al
>
> Andrew Sykes wrote:
>> Hi Folks,
>>
>> I was thinking that it might be a good idea to add an autoRenew
>> attribute to the Subscription entity so that subscriptions could be
>> identified as being automatically renewable.
>>
>> We could then create a service that queried the Subscriptions daily and
>> if one will expire in the next 24 hours and has autoRenew=Y, we could
>> try to re-bill the user.
>>
>> Also, a service that cancelled the subscription, "cancelSubscription"
>> with a timestamp argument to update the Subscription.thruDate This
>> service would set autoRenew="N" and thruDate="timestamp"
>> if the timestamp is not present thruDate would be unchanged.
>>
>> Any thoughts?
>>
>
>
Re: Subscription entity
Posted by Andrew Sykes <an...@sykesdevelopment.com>.
Al,
That's an interesting idea (RecurrenceInfo), it seems if we went that
route that there is a bit of overlap between the from/thru dates on
Subscription and the RecurrenceInfo stuff.
Can you see a reason to have both? I probably have to study this a bit
more before I comment further as I haven't thought along these before.
Hans is also working on this stuff so he'll probably have some useful
comments.
Of course, I'd be happy to collaborate on this.
- Andrew
On Fri, 2006-06-30 at 12:13 -0600, Al Byers wrote:
> Hi Andrew,
>
> I just started working with subscriptions, too. Hopefully, David will
> comment if he is not too busy, but in case he doesn't I will tell you
> what I know. I was thinking like you, only I thought maybe Subscription
> should have a recurrenceInfoId field, as RecurrenceInfo entity already
> exists and is set up to handle this. The place that there is an
> instance of recurrenceInfoId is in ShoppingList which is what David told
> me could be used to set up recurring Subscriptions.
>
> I have not yet looked around for supporting services and such, but I
> would be interested in collaborating with you and anyone else working in
> this field to get a good solution. I am guessing that there are existing
> services to support ShoppingList use; I will be looking today. The
> ProductSubscriptionResource entity replaces ProductContent. It is more
> flexible.
>
> I started this email before David responded. I will send it anyway so
> that you and I and any one else can collaborate, if desired. I am
> wondering if there are some admin screen that need to be done?
>
> -Al
>
> Andrew Sykes wrote:
> > Hi Folks,
> >
> > I was thinking that it might be a good idea to add an autoRenew
> > attribute to the Subscription entity so that subscriptions could be
> > identified as being automatically renewable.
> >
> > We could then create a service that queried the Subscriptions daily and
> > if one will expire in the next 24 hours and has autoRenew=Y, we could
> > try to re-bill the user.
> >
> > Also, a service that cancelled the subscription, "cancelSubscription"
> > with a timestamp argument to update the Subscription.thruDate
> > This service would set autoRenew="N" and thruDate="timestamp"
> > if the timestamp is not present thruDate would be unchanged.
> >
> > Any thoughts?
> >
>
--
Kind Regards
Andrew Sykes <an...@sykesdevelopment.com>
Sykes Development Ltd
http://www.sykesdevelopment.com
Re: Subscription entity
Posted by "David E. Jones" <jo...@undersunconsulting.com>.
I would highly recommend against both options and instead use the ShoppingList for this.
Adding this stuff to the Subscription would simply result in duplication of the data model and logic that is on the ShoppingList. In this case much more than just the recurrence info is needed to be able to place orders to automatically renew a subscription...
-David
Andrew Sykes wrote:
> Al, Hans,
>
> How do you think Subscription should be linked to RecurrenceInfo?
>
> There seems to be two options...
> new Entity
> SubscriptionRecurrenceInfo
>
> new Attribute
> Subscription.recurrenceInfoId
>
> There seems to be precedent for the second option, what do you think?
>
> - Andrew
>
> On Fri, 2006-06-30 at 12:13 -0600, Al Byers wrote:
>> Hi Andrew,
>>
>> I just started working with subscriptions, too. Hopefully, David will
>> comment if he is not too busy, but in case he doesn't I will tell you
>> what I know. I was thinking like you, only I thought maybe Subscription
>> should have a recurrenceInfoId field, as RecurrenceInfo entity already
>> exists and is set up to handle this. The place that there is an
>> instance of recurrenceInfoId is in ShoppingList which is what David told
>> me could be used to set up recurring Subscriptions.
>>
>> I have not yet looked around for supporting services and such, but I
>> would be interested in collaborating with you and anyone else working in
>> this field to get a good solution. I am guessing that there are existing
>> services to support ShoppingList use; I will be looking today. The
>> ProductSubscriptionResource entity replaces ProductContent. It is more
>> flexible.
>>
>> I started this email before David responded. I will send it anyway so
>> that you and I and any one else can collaborate, if desired. I am
>> wondering if there are some admin screen that need to be done?
>>
>> -Al
>>
>> Andrew Sykes wrote:
>>> Hi Folks,
>>>
>>> I was thinking that it might be a good idea to add an autoRenew
>>> attribute to the Subscription entity so that subscriptions could be
>>> identified as being automatically renewable.
>>>
>>> We could then create a service that queried the Subscriptions daily and
>>> if one will expire in the next 24 hours and has autoRenew=Y, we could
>>> try to re-bill the user.
>>>
>>> Also, a service that cancelled the subscription, "cancelSubscription"
>>> with a timestamp argument to update the Subscription.thruDate
>>> This service would set autoRenew="N" and thruDate="timestamp"
>>> if the timestamp is not present thruDate would be unchanged.
>>>
>>> Any thoughts?
>>>
Re: Subscription entity
Posted by Andrew Sykes <an...@sykesdevelopment.com>.
Al, Hans,
How do you think Subscription should be linked to RecurrenceInfo?
There seems to be two options...
new Entity
SubscriptionRecurrenceInfo
new Attribute
Subscription.recurrenceInfoId
There seems to be precedent for the second option, what do you think?
- Andrew
On Fri, 2006-06-30 at 12:13 -0600, Al Byers wrote:
> Hi Andrew,
>
> I just started working with subscriptions, too. Hopefully, David will
> comment if he is not too busy, but in case he doesn't I will tell you
> what I know. I was thinking like you, only I thought maybe Subscription
> should have a recurrenceInfoId field, as RecurrenceInfo entity already
> exists and is set up to handle this. The place that there is an
> instance of recurrenceInfoId is in ShoppingList which is what David told
> me could be used to set up recurring Subscriptions.
>
> I have not yet looked around for supporting services and such, but I
> would be interested in collaborating with you and anyone else working in
> this field to get a good solution. I am guessing that there are existing
> services to support ShoppingList use; I will be looking today. The
> ProductSubscriptionResource entity replaces ProductContent. It is more
> flexible.
>
> I started this email before David responded. I will send it anyway so
> that you and I and any one else can collaborate, if desired. I am
> wondering if there are some admin screen that need to be done?
>
> -Al
>
> Andrew Sykes wrote:
> > Hi Folks,
> >
> > I was thinking that it might be a good idea to add an autoRenew
> > attribute to the Subscription entity so that subscriptions could be
> > identified as being automatically renewable.
> >
> > We could then create a service that queried the Subscriptions daily and
> > if one will expire in the next 24 hours and has autoRenew=Y, we could
> > try to re-bill the user.
> >
> > Also, a service that cancelled the subscription, "cancelSubscription"
> > with a timestamp argument to update the Subscription.thruDate
> > This service would set autoRenew="N" and thruDate="timestamp"
> > if the timestamp is not present thruDate would be unchanged.
> >
> > Any thoughts?
> >
>
--
Kind Regards
Andrew Sykes <an...@sykesdevelopment.com>
Sykes Development Ltd
http://www.sykesdevelopment.com
Re: Subscription entity
Posted by Al Byers <by...@automationgroups.com>.
Hi Andrew,
I just started working with subscriptions, too. Hopefully, David will
comment if he is not too busy, but in case he doesn't I will tell you
what I know. I was thinking like you, only I thought maybe Subscription
should have a recurrenceInfoId field, as RecurrenceInfo entity already
exists and is set up to handle this. The place that there is an
instance of recurrenceInfoId is in ShoppingList which is what David told
me could be used to set up recurring Subscriptions.
I have not yet looked around for supporting services and such, but I
would be interested in collaborating with you and anyone else working in
this field to get a good solution. I am guessing that there are existing
services to support ShoppingList use; I will be looking today. The
ProductSubscriptionResource entity replaces ProductContent. It is more
flexible.
I started this email before David responded. I will send it anyway so
that you and I and any one else can collaborate, if desired. I am
wondering if there are some admin screen that need to be done?
-Al
Andrew Sykes wrote:
> Hi Folks,
>
> I was thinking that it might be a good idea to add an autoRenew
> attribute to the Subscription entity so that subscriptions could be
> identified as being automatically renewable.
>
> We could then create a service that queried the Subscriptions daily and
> if one will expire in the next 24 hours and has autoRenew=Y, we could
> try to re-bill the user.
>
> Also, a service that cancelled the subscription, "cancelSubscription"
> with a timestamp argument to update the Subscription.thruDate
> This service would set autoRenew="N" and thruDate="timestamp"
> if the timestamp is not present thruDate would be unchanged.
>
> Any thoughts?
>
Re: Subscription entity
Posted by "David E. Jones" <jo...@ofbiz.org>.
If you had the renewal settings on the Subscription entity it would need all payment, etc settings.
The plan right now is to use the ShoppingList, etc. for this and any other automatic reordering.
-David
Andrew Sykes wrote:
> Hi Folks,
>
> I was thinking that it might be a good idea to add an autoRenew
> attribute to the Subscription entity so that subscriptions could be
> identified as being automatically renewable.
>
> We could then create a service that queried the Subscriptions daily and
> if one will expire in the next 24 hours and has autoRenew=Y, we could
> try to re-bill the user.
>
> Also, a service that cancelled the subscription, "cancelSubscription"
> with a timestamp argument to update the Subscription.thruDate
> This service would set autoRenew="N" and thruDate="timestamp"
> if the timestamp is not present thruDate would be unchanged.
>
> Any thoughts?