This is a good question...
For non-store (non-ecommerce) related things I wouldn't want to use
the ProductStore and related data structures, that would be a bit of a
hack (and actually the email settings on there are stretched a little
bit in this context...).
The easy place for this would be a properties file, but I don't like
that because we want to move business config into the database going
forward, and for all existing business level (as opposed to technical/
framework level) properties.
Okay, none of that is really helpful so far is it...
The from address is generally meant for a reply, as well as general
information. Would we support replies for any of these? If not we
might want to make the to and from address the same, or use a really
general system address as the from address.
Going beyond that we could introduce the concept of a "primary
internal organization" that is basically the org or company that owns
and runs the system. With that we could have an email contact info
associated with it like a primary purpose (or perhaps a new general
system purpose) and use that for the from email.
I'm interested in hearing other ideas... or in other words I'm not
satisfied with my own so far...
-David
On Jul 22, 2008, at 8:32 AM, Adrian Crum wrote:
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
