I believe, if people were against the idea they would have already raised hands You should create the Jira: https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
Welcome Jacques Falcon ICT Pty Ltd wrote: > Hi Jacques > > I had identified the Content entity for the new > serviceNameOnSubscriptionExpiry as that was the entity used for > serviceName, with the latter currently running once at the activation of > subscription and again for every runSubscriptionAutoReorders. I was taking > serviceName as being the trigger for external provisioning on activation of > a subscription, but thinking about it more, serviceName is strictly > speaking a generic service to run when the content is consumed, i.e. not > tied to subscription specifically. > > So actually serviceNameOnSubscriptionExpiry may be more appropriate in > SubscriptionResource > entity as you suggested. > > I also see your point about premature optimisation. I'm not too committed > one way or another, so happy to take your guidance on taking the road of a > new runServiceOnSubscriptionExpiry service. > > Who would open the Jira? Would that be myself or a committer? > > I suppose there would need to be a wider consensus from the broader > community or at least the main committers for this proposed change. > > regards > Ivan > > > On Tue, Sep 24, 2013 at 7:34 PM, Jacques Le Roux < > [email protected]> wrote: > >> It's an interesting propostion. Though I wonde why putting the field >> serviceNameOnSubscriptionExpiry in Content rather than in >> SubscriptionResource entity? (to keep the data model easier to understand) >> >> I'd prefer a new runServiceOnSubscriptionExpiry service, I'm against >> premature optimisation. >> In case of performance issue, you can always refactor the code after >> respecting higher level of abstractions (here as you said "complete >> separation of the default and new functionality") >> >> We should continue to discuss this on the dev ML (I copy there also) >> If we agree, the way should be to open a Jira and submit a patch >> >> Thanks >> >> Jacques >> >> Falcon ICT Pty Ltd wrote: >>> Hi all >>> >>> I have been thinking of this subject for a while. The main characteristics >>> of the Ofbiz subscriptions are: >>> a) as noted in the Amicontech link, the access control of the subscribed >>> internal content is missing, and can be provided by custom means. As well, >>> subscription to content on external systems needs a trigger, which can be >>> provided through serviceName. >>> b) the subscription model has an inbuilt assumption that access to the >>> resource is terminated outside of the default Ofbiz, such as by a custom >>> Ofbiz process or an external process. >>> >>> The generic use case I'm thinking of is external systems providing content >>> to which a client desires to subscribe which don't have an inbuilt expiry. >>> These systems require a trigger to enable provisioning, and another >>> trigger to enable deprovisioning. >>> >>> Ofbiz can be used to manage the provision of access to such external >>> content, triggering the provisioning process through a service in >>> serviceName. What's missing is an (optional) trigger for the >>> deprovisioning process. >>> >>> One way which we're thinking of resolving this is: >>> a) to add another column to the Content entity, called >>> serviceNameOnSubscriptionExpiry. This would contain the service to run to >>> trigger the deprovisioning process. If containing null, nothing would be >>> run, and the Ofbiz exhibits the current default behaviour. >>> b) add some code to an existing Ofbiz service, or create a new one, that is >>> scheduled to run regularly. This code would check whether a subscription >>> has expired. If so, and a service exists within serviceNameOnExpiry, and * >>> Subscription.automaticExtend=N,* this code runs that service. This code >>> can be added as a modification to runSubscriptionAutoReorder in >>> OrderServices.java, or as a new process runServiceOnSubscriptionExpiry >>> within SubscriptionServices.java. The former has the advantage that lookup >>> of subscription entities is done once, both for extension and expiry, with >>> the disadvantage of the code may be seen as beyond scope of the existing >>> service. The latter has the advantage of complete separation of the >>> default and new functionality with the cost of more database lookups. >>> >>> If there is any interest in the Ofbiz community, I'd be prepared to offer >>> this code for inclusion in the Ofbiz trunk. I'm also open to any >>> suggestions or discussion. >>> >>> regards
