Couldn't we have a Party defined as subscription sender? For example it could be the "Company" party in the demo. We could also define a new contactMechPurposeTypeId for this like "Subscription email sender"
-Bruno 2008/7/22 Adrian Crum <[EMAIL PROTECTED]>: > We certainly could. In our implementation here, they are all free of > course. > > I'm running into one snag trying to get this ready for the project. On the > notification emails, where should the notification service get the "From" > information (from email address, from company name, etc)? In eCommerce, > there is a ProductStore record that provides that information. But what > about installations that don't have a store? Should we have a product store > record set up for the internal organization for things like this? I want > this to be configurable, but I don't know how to go about it. > > In Asset Maintenance, I was considering looking up the owner of the fixed > asset, and using the owner's information. > > > -Adrian > > David E Jones wrote: > >> >> That sounds interesting. I suppose we could even combine the two and have >> paid subscriptions to events... >> >> -David >> >> >> On Jul 21, 2008, at 1:18 PM, Adrian Crum wrote: >> >> Well, in my conversion I used the subscription entities and services. >>> >>> Each application that implements this process has its own set of >>> subscription resources that the user can choose from (using the >>> parentResourceId). The user can then specify the from and through dates for >>> the subscription, and a notification email address. >>> >>> Various SECAS exist to check to see if the user is subscribed to the >>> event notification, and if so, a notification email is sent to the address >>> found in the subscription. The SECAS are attached to the corresponding CRUD >>> services, of course. >>> >>> I understand the subscription entities were originally developed to >>> represent a product that is sold, but they made a really good fit in this >>> scenario. >>> >>> -Adrian >>> >>> David E Jones wrote: >>> >>>> It sounds like a nice tool. >>>> I'm a little confused though, what do you mean by the "built-in OFBiz >>>> subscription services"? There are some things with names like >>>> "subscription", and there are some email notification services and such, >>>> but >>>> maybe you're referring to something else even? >>>> -David >>>> On Jul 21, 2008, at 11:47 AM, Adrian Crum wrote: >>>> >>>>> Some time ago I implemented a subscription system on our local OFBiz >>>>> copy, where users can subscribe to notifications about OFBiz application >>>>> events. Users can subscribe to events like new calendar items, new forum >>>>> messages, etc and the system sends the user an email when the event >>>>> occurs. >>>>> At the time, either the built-in OFBiz subscription services didn't exist >>>>> or >>>>> I didn't notice them, so I wrote my own. >>>>> >>>>> I recently converted our in-house subscription code to use the OFBiz >>>>> subscription services and it works quite well. I also modified our Asset >>>>> Maintenance component to allow maintenance workers (or outside services) >>>>> to >>>>> subscribe to email notifications when they are assigned to new >>>>> maintenances. >>>>> >>>>> Now our OFBiz users have a cool subscription summary page in the MyPage >>>>> component where they can see all of the events they are subscribed to. >>>>> >>>>> Would there be any interest in porting this back into the project? >>>>> >>>>> -Adrian >>>>> >>>> >> >>
