Re: Subscription entity

Posted by David E Jones-2 on Jul 03, 2006; 6:09pm
URL: http://ofbiz.116.s1.nabble.com/Subscription-entity-tp169194p169199.html


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?
>>>