Okay, I have finished the subscriptions and notifications in the Asset
Maintenance component. I settled on the following strategy for getting
the Reply To address:
The fixed asset maintenance notification process follows the trail from
the fixed asset, to the party related to it in the role of "Maintenance
eMail Administrator", then get that party's email address that has a
"Fixed Asset Maintenance Notifications Reply To Address" purpose type.
So, this process follows a trail specific to the process - no ambiguity
that might result in an incorrect Reply To email address. At the same
time there is good flexibility in how users can set it up. In addition,
if a user doesn't want a Reply To address sent, then they don't make the
necessary associations.
I didn't like the idea of replies going to some kind of general inbox.
In our case, a maintenance service company might reply to a maintenance
notification - stating when they will be out to perform the service.
Someone in maintenance needs to see that reply.
If there are no further comments, then I'll let our users work with this
for a while, and then get it committed.
-Adrian
Adrian Crum wrote:
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