Ha, we crossed online :)
Le 13/01/2023 à 09:52, sixty_...@mail.de a écrit :
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
