David and Jacopo,
Many thanks for your comments. I'm still undecided, but they helped anyway.
David, I appreciate your "thinking out loud" approach - I went through
the same chain of thought. We agree on what NOT to do.
One approach I had considered, (and mentioned previously) was having
each implementation (or notification process) follow a trail appropriate
for the implementation - that would eventually lead to a responsible
party, then look up that party's email address contact mech that has a
"Notification Reply Address" purpose type.
Some examples:
1. New fixed asset maintenance notifications would follow the trail from
the fixed asset, to the party related to it in the role of owner, then
get the notification reply address for that party.
2. New calendar event messages would follow the trail from the calendar,
to the party related to it as calendar creator, then get the
notification reply address for that party.
One problem with this approach is there is no single place where
notification reply address information is kept - each scenario is a
little different, which may cause confusion.
Another problem is the potential ambiguity of the "Notification Reply
Address" contact mech purpose type. What if there needs to be more than
one Notification Reply Address for a particular party? Maybe each
notification process could have its own contact mech purpose type to
look for. *shrug*
Anyways, I'll wait to hear more ideas.
-Adrian
Jacopo Cappellato wrote:
On Jul 23, 2008, at 8:12 AM, David E Jones wrote:
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...).
We may consider the idea of modifying the concept of ProductStore...
essentially adding a new OrganizationSettings (or similar) entity, with
most of the current fields of the ProductStore entity (and removing them
from the ProductStore) and adding to the ProductStore the
organizationSettingsId field to get them. We may also consider to move
some of the ProductStore* related entities (all the ones that may be
used without a product store e.g. email settings) to the
OrganizationSettings entity.
In this way, if a company XYZ doesn't want a ProductStore:
Party XYZ (internal organization)
|
|_____________> OrganizationSettings ABC
If a company XYZ has one or more product stores:
Party XYZ (internal organization)
|
|_____________> OrganizationSettings ABC
|
|_____________> ProductStore ABC1 (if organizationSettingsId is not
specified, defaults to the OrganizationSettings ABC)
|
|_____________> ProductStore ABC2 <---> OrganizationSettings ABC2
(specific settings for this product store)
|
|_____________> ProductStore ABC3 <---> OrganizationSettings ABC3
(specific settings for this product store)
...
There is probably something I don't like about this... but I am not sure
what it is, this will need to be refined, but I got the idea.
It would be a rather important change...
Jacopo
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
