Hey Jacques, thanks for your prompt answer. If I understand you correctly you propose that I rather ask my question in the user ML instead of the dev ML? If so I'll do that accordingly. Up to now I already checked the Confluence docs regarding subscriptions and also the associated documents from external sources - especially the amicontech article made me suspect that there are lots open endings. Also volume 2 of The Data Model Resource Book proposes a subscription model that from my point of view isn't sufficient for flexible SaaS-subscriptions - I guess that's why OFBiz' also enrichens the model with additional attributes like a useCountLimit. I think we already have most of the required entities and attributes available, they "just" need to be cleaned up and fitted together with some appropriate business logic. Am 11-Jan-2023 14:01:36 +0100 schrieb jacques.le.r...@les7arts.com: Hi,
Your message has been moderated, else it would not have reached this Mailing List. Please subscribe to the user ML for such questions and then use your email client. See why here http://ofbiz.apache.org/mailing-lists.html. You will get a better support, people can answer you on the ML. The wider the audience the better the answers you might get. Also it's more work for moderators who have to accept your messages as long as you have not subscribed. Thanks This said, I'll answer you later if nobody beats me on it. I guess you already read? https://cwiki.apache.org/confluence/display/OFBIZ/Subscription Jacques Le 11/01/2023 13:36, sixty_...@mail.de a crit : > Dear community, > we'd like to dig into OFBiz' subscription handling. We already started to > check all of the available resources on the web and it feels like the > subscription handling is more or less in a proof of concept state with a few > open endings. > One simple example that bothers me: When a subscription is ordered the > changeOrderStatus-SECA triggers the processExtendSubscription-service. This > service automatically sets the thruDate of a subscription to the current > date. If I understand this correctly this is done because the service > implicitly assumes that the subscription should be extended which isn't > correct in most of the cases I can think of. I'd rather keep the thruDate > open until the subscription expires - either because of the useTime or the > useCount exceeds the defined limits of this subscription (e.g. valid 1 year > from start, valid for 10 usage hours, valid for 5 usage counts). A clear > from/thruDate-relation which we are familiar within OFBiz also seems to be > more consistent to me from a data model point of view. > Before digging into that and implementing the relevant services or checks I > just wanted to discuss if those "open endings" were left open on purpose to > increase the flexibility of possible use cases or if simply someone stopped > working on it. Thanks so far. > > ------------------------------------------------------------------------------------------------- > FreeMail powered by mail.de - MEHR SICHERHEIT, SERIOSITÄT UND KOMFORT ------------------------------------------------------------------------------------------------- FreeMail powered by mail.de - MEHR SICHERHEIT, SERIOSITÄT UND KOMFORT
