Subscribing to OFBiz Application Events

[Adrian Crum]

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

[byersa]

Adrian,

This sounds like it would be a valuable addition to OFBiz, so I would like
to see it there.

-Al

On Mon, Jul 21, 2008 at 11:47 AM, Adrian Crum <[hidden email]> 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
>

[BJ Freeman]

+1
see it as valuable tool

Adrian Crum sent the following on 7/21/2008 10:47 AM:

> 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
>
>
>

[David E Jones]

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

[Adrian Crum]

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
>
>

[hans_bakker]

Sure Adrian! would be a nice addition to the mypage component.....

On Mon, 2008-07-21 at 10:47 -0700, 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

[Adrian Crum]

There's nothing to add to the MyPage component. Subscriptions are
already a part of the Profile page.

-Adrian

Hans Bakker wrote:

> Sure Adrian! would be a nice addition to the mypage component.....
>
> On Mon, 2008-07-21 at 10:47 -0700, 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
>
>

[David E Jones]

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

[Jacques Le Roux]

Hi Adrian,

Yes +1, looks good

Jacques

From: "Adrian Crum" <[hidden email]>

> 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
>

[Ashish Vijaywargiya]

+1 Adrian.

On Tue, Jul 22, 2008 at 3:52 PM, Jacques Le Roux <
[hidden email]> wrote:

> Hi Adrian,
>
> Yes +1, looks good
>
> Jacques
>
> From: "Adrian Crum" <[hidden email]>
>
>  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
>>
>>

--
Ashish Vijaywargiya
Indore, India
http://en.wikipedia.org/wiki/Indore

[Adrian Crum]

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
>
>

[Bruno Busco]

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 <[hidden email]>:

> 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
>>>>>
>>>>
>>
>>

[David E Jones]

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

[Jacopo Cappellato-3]

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
>

[Adrian Crum]

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
>>
>

[Adrian Crum]

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
>>>
>>
>

[David E Jones]

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
>>>>
>>>

[Adrian Crum]

David E Jones wrote:

> 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

So, go from fixed asset to the related party in the role of owner, then
look for a party related to the owner in the role of Maintenance
Manager? When that party is located, which email address is used? Or do
we assume they have only one?

> 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

Do you mean set up a contact mech type specific to each notification
process, then list all contact mechs matching that type for the user to
choose from? In that case, I'll need an entity to make the connection
from FixedAsset to ContectMech.

Those are both good suggestions - thanks! I just want to make sure I'm
understanding you correctly before proceeding.

-Adrian

[David E Jones]

On Jul 25, 2008, at 4:18 PM, Adrian Crum wrote:

> David E Jones wrote:
>> 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
>
> So, go from fixed asset to the related party in the role of owner,  
> then look for a party related to the owner in the role of  
> Maintenance Manager? When that party is located, which email address  
> is used? Or do we assume they have only one?

Probably just the primary email address. I don't know if it's worth  
having a special purpose for this... is it common in your situation to  
need a separate email for this sort of thing?

One thing to consider is that the related party (Maintenance Manager)  
could be a PartyGroup, with a special email address used just for this  
purpose, but that would be chosen by the user depending how they want  
to setup that relationship.

>> 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
>
> Do you mean set up a contact mech type specific to each notification  
> process, then list all contact mechs matching that type for the user  
> to choose from? In that case, I'll need an entity to make the  
> connection from FixedAsset to ContectMech.

No, this would be more like what Jacopo suggested with the  
communication configuration per company. Along with configuring  
outgoing emails we would configure the fromPartyId or a  
fromContactMechId.

-David

[Adrian Crum]

David E Jones wrote:

> On Jul 25, 2008, at 4:18 PM, Adrian Crum wrote:
>> David E Jones wrote:
>>> 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
>>
>> So, go from fixed asset to the related party in the role of owner,
>> then look for a party related to the owner in the role of Maintenance
>> Manager? When that party is located, which email address is used? Or
>> do we assume they have only one?
>
> Probably just the primary email address. I don't know if it's worth
> having a special purpose for this... is it common in your situation to
> need a separate email for this sort of thing?
>
> One thing to consider is that the related party (Maintenance Manager)
> could be a PartyGroup, with a special email address used just for this
> purpose, but that would be chosen by the user depending how they want to
> setup that relationship.

Actually, my situation is pretty basic. What I'm trying to avoid is
creating an implementation that is too specific. In other words, I'm
trying to make it more generic so others can use it.

The primary email address would be fine. I decided to make one change in
the relationship though. It will look for a party related to the owner
in the role of Maintenance eMail Administrator. I don't want to assume
the maintenance manager will handle email replies. A maintenance manager
might want one of the maintenance workers to handle replies. This
approach adds only one thing - a new role. How does that sound?

-Adrian