So the party for this would be associated with each FixedAsset, and
then that Party would have a special email address just for this
purpose?
The main concerns I'd have would be:
1. cumbersome to setup and maintain
2. special RoleType and ContactMechPurposeType that aren't really used
for anything else
Some options might be:
1. use the FixedAsset owner (and similar concepts) to identify who to
send it to, either directly or through a PartyRelationship to someone
in the organization in charge of managing fixed asset maintenance (and
similar concepts in other areas); the idea would be to use the natural
organization and relationships that companies would want to setup
anyway, and use that for as much as possible, including these
notifications; this reduces setup and maintenance complexity and makes
the system in general easier to use and understand, and if flexibility
points are needed for funny situations in the future we can look at
that then
2. create a central set of Party or just ContactMech/email records
with different purposes, and look up the one to use for the relevant
area; this could be tied to the set of notifications available when
those are configured so simplify and centralize administration
-David
On Jul 24, 2008, at 6:24 PM, Adrian Crum wrote:
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