Implementing alternate calendar alarm types (e.g. SMS) in eGroupWare

[Aleksander_Adamowsk2]

Hi!

I’m preparing to implement a new functionality of alternate calendar alarm
types for eGW Calendar.
Currently it would cover SMS alarms, which would provide a nice substitution
for SyncML support for mobile devices, which currently doesn’t work with
many devices and configurations. It would also be useful for users of
simpler phones, which aren’t smartphones or don’t support SyncML.

I’m trying to figure out what would be the best architecture for this and
which subsystems would need changes.

Here is the intended functionality from user perspective:

1. When configuring alarms for an event, the user can choose either
   the “email” alarm type (that behaves like the current one) or “sms” (in the
   future it should be possible to extend eGW to add new types, e.g.
   winpopup).
2. When the alarm is launched by asyncservices, it should find the
   mobile number for all the accounts in the addressbook (either SQL or LDAP -
   preferably without any knowledge about actual configured addressbook
   settings with respect to SQL/LDAP storage of accounts data) and launch a
   configured system utility to send SMS messages to them.
3. Configuration could have a form of a customisable PHP function in
   e.g. header.inc.php that accepts the mobile number and notification
   text as an argument and takes care of filtering data and launching proper
   system tools to deliver the SMS
4. A user should be able to set a default alarm for new events in the
   calendar preferences, so that he/she doesn’t have to set up alarms for all
   new created events, so e.g. he/she always is notified by SMS, unless
   he/she manually deletes the alarm when creating a new event

From my current analysis it seems that I’d have to alter at least the
following classes:

calendar/inc/hook_preferences.inc.php
calendar/inc/class.socal.inc.php
phpgwapi/inc/class.asyncservice.inc.php
phpgwapi/cron/asyncservices.php

What do You think about general idea?

Do you have any advice how to start the implementation?

–
Best Regards,
Aleksander Adamowski
http://olo.org.pl

[jaytraxx]

Hi Aleksander,

the functionality you think of should be implemented as plugin for the new notifications-app and not in calendar itself !

I already wrote two additional plugins for notifications (e-mail and winpopup) and made notifications able to handle subjects and attachments. Also, I made notifications-app ready to handle the type of notification the user would like to have (e.g. egwpopup first, if that fails send an email, and so on …) I already sent that to conny and he agreed that I can commit that to trunk (Ralf, I will contact you before I do that to speak about it).

Since now, I could not find any time to do that, but the code is here and we run it on our production server. It works good.

So, if this code is in trunk, all you have to do is to write another plugin -> SMS for notifications-app.
The good thing with notifications-app is the centralized setting for all notifications (for the user) and the centralized handling of notifications in the code (we can drop a bit code then, all you need to do is to feed the notification object with some information).

Good idea?

Bye
Christian

Hi!

I’m preparing to implement a new functionality of alternate calendar alarm
types for eGW Calendar.
Currently it would cover SMS alarms, which would provide a nice substitution
for SyncML support for mobile devices, which currently doesn’t work with
many devices and configurations. It would also be useful for users of
simpler phones, which aren’t smartphones or don’t support SyncML.

I’m trying to figure out what would be the best architecture for this and
which subsystems would need changes.

Here is the intended functionality from user perspective:

1. When configuring alarms for an event, the user can choose either
   the “email” alarm type (that behaves like the current one) or “sms” (in the
   future it should be possible to extend eGW to add new types, e.g.
   winpopup).
2. When the alarm is launched by asyncservices, it should find the
   mobile number for all the accounts in the addressbook (either SQL or LDAP -
   preferably without any knowledge about actual configured addressbook
   settings with respect to SQL/LDAP storage of accounts data) and launch a
   configured system utility to send SMS messages to them.
3. Configuration could have a form of a customisable PHP function in
   e.g. header.inc.php that accepts the mobile number and notification
   text as an argument and takes care of filtering data and launching proper
   system tools to deliver the SMS
4. A user should be able to set a default alarm for new events in the
   calendar preferences, so that he/she doesn’t have to set up alarms for all
   new created events, so e.g. he/she always is notified by SMS, unless
   he/she manually deletes the alarm when creating a new event

From my current analysis it seems that I’d have to alter at least the
following classes:

calendar/inc/hook_preferences.inc.php
calendar/inc/class.socal.inc.php
phpgwapi/inc/class.asyncservice.inc.php
phpgwapi/cron/asyncservices.php

What do You think about general idea?

Do you have any advice how to start the implementation?

–
Best Regards,
Aleksander Adamowski
http://olo.org.pl

---

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[Ralf_Becker_6]

I can only agree, SMS notification should be a plugin of the notifcation
app and not be coded in the calendar.

Ralf

jaytraxx schrieb:

Hi Aleksander,

the functionality you think of should be implemented as plugin for the new
notifications-app and not in calendar itself !

I already wrote two additional plugins for notifications (e-mail and
winpopup) and made notifications able to handle subjects and attachments.
Also, I made notifications-app ready to handle the type of notification the
user would like to have (e.g. egwpopup first, if that fails send an email,
and so on …) I already sent that to conny and he agreed that I can commit
that to trunk (Ralf, I will contact you before I do that to speak about it).

Since now, I could not find any time to do that, but the code is here and we
run it on our production server. It works good.

So, if this code is in trunk, all you have to do is to write another plugin
-> SMS for notifications-app.
The good thing with notifications-app is the centralized setting for all
notifications (for the user) and the centralized handling of notifications
in the code (we can drop a bit code then, all you need to do is to feed the
notification object with some information).

Good idea?

Bye
Christian

Aleksander Adamowski-3 wrote:

Hi!

I’m preparing to implement a new functionality of alternate calendar alarm
types for eGW Calendar.
Currently it would cover SMS alarms, which would provide a nice
substitution
for SyncML support for mobile devices, which currently doesn’t work with
many devices and configurations. It would also be useful for users of
simpler phones, which aren’t smartphones or don’t support SyncML.

I’m trying to figure out what would be the best architecture for this and
which subsystems would need changes.

Here is the intended functionality from user perspective:

1. When configuring alarms for an event, the user can choose either
   the “email” alarm type (that behaves like the current one) or “sms” (in
   the
   future it should be possible to extend eGW to add new types, e.g.
   winpopup).
2. When the alarm is launched by asyncservices, it should find the
   mobile number for all the accounts in the addressbook (either SQL or
   LDAP -
   preferably without any knowledge about actual configured addressbook
   settings with respect to SQL/LDAP storage of accounts data) and launch
   a
   configured system utility to send SMS messages to them.
3. Configuration could have a form of a customisable PHP function in
   e.g. header.inc.php that accepts the mobile number and notification
   text as an argument and takes care of filtering data and launching
   proper
   system tools to deliver the SMS
4. A user should be able to set a default alarm for new events in the
   calendar preferences, so that he/she doesn’t have to set up alarms for
   all
   new created events, so e.g. he/she always is notified by SMS, unless
   he/she manually deletes the alarm when creating a new event

From my current analysis it seems that I’d have to alter at least the
following classes:

calendar/inc/hook_preferences.inc.php
calendar/inc/class.socal.inc.php
phpgwapi/inc/class.asyncservice.inc.php
phpgwapi/cron/asyncservices.php

What do You think about general idea?

Do you have any advice how to start the implementation?

–
Best Regards,
Aleksander Adamowski
http://olo.org.pl

---

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

–
Ralf Becker
eGroupWare Training & Support ==> http://www.egroupware-support.de
Outdoor Unlimited Training GmbH [www.outdoor-training.de]
Handelsregister HRB Kaiserslautern 3587
Geschäftsführer Birgit und Ralf Becker
Leibnizstr. 17, 67663 Kaiserslautern, Germany
Telefon +49 (0)631 31657-0

---

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[Aleksander_Adamowsk2]

I can only agree, SMS notification should be a plugin of the notifcation
app and not be coded in the calendar.

That’s wonderful, it would spare me a lot of work!

But when will I be able to put my hands around the new
notification-app code? Our customer is expecting a schedule for that
implementation…

jaytraxx schrieb:

Hi Aleksander,

the functionality you think of should be implemented as plugin for the new
notifications-app and not in calendar itself !

I already wrote two additional plugins for notifications (e-mail and
winpopup) and made notifications able to handle subjects and attachments.
Also, I made notifications-app ready to handle the type of notification the
user would like to have (e.g. egwpopup first, if that fails send an email,
and so on …) I already sent that to conny and he agreed that I can commit
that to trunk (Ralf, I will contact you before I do that to speak about it).

Since now, I could not find any time to do that, but the code is here and we
run it on our production server. It works good.

So, if this code is in trunk, all you have to do is to write another plugin
-> SMS for notifications-app.
The good thing with notifications-app is the centralized setting for all
notifications (for the user) and the centralized handling of notifications
in the code (we can drop a bit code then, all you need to do is to feed the
notification object with some information).

Good idea?

Bye
Christian

Aleksander Adamowski-3 wrote:

Hi!

I’m preparing to implement a new functionality of alternate calendar alarm
types for eGW Calendar.
Currently it would cover SMS alarms, which would provide a nice
substitution
for SyncML support for mobile devices, which currently doesn’t work with
many devices and configurations. It would also be useful for users of
simpler phones, which aren’t smartphones or don’t support SyncML.

I’m trying to figure out what would be the best architecture for this and
which subsystems would need changes.

Here is the intended functionality from user perspective:

1. When configuring alarms for an event, the user can choose either
   the “email” alarm type (that behaves like the current one) or “sms” (in
   the
   future it should be possible to extend eGW to add new types, e.g.
   winpopup).
2. When the alarm is launched by asyncservices, it should find the
   mobile number for all the accounts in the addressbook (either SQL or
   LDAP -
   preferably without any knowledge about actual configured addressbook
   settings with respect to SQL/LDAP storage of accounts data) and launch
   a
   configured system utility to send SMS messages to them.
3. Configuration could have a form of a customisable PHP function in
   e.g. header.inc.php that accepts the mobile number and notification
   text as an argument and takes care of filtering data and launching
   proper
   system tools to deliver the SMS
4. A user should be able to set a default alarm for new events in the
   calendar preferences, so that he/she doesn’t have to set up alarms for
   all
   new created events, so e.g. he/she always is notified by SMS, unless
   he/she manually deletes the alarm when creating a new event

From my current analysis it seems that I’d have to alter at least the
following classes:

calendar/inc/hook_preferences.inc.php
calendar/inc/class.socal.inc.php
phpgwapi/inc/class.asyncservice.inc.php
phpgwapi/cron/asyncservices.php

What do You think about general idea?

Do you have any advice how to start the implementation?

–
Best Regards,
Aleksander Adamowski
http://olo.org.pl

---

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

–
Ralf Becker
eGroupWare Training & Support ==> http://www.egroupware-support.de
Outdoor Unlimited Training GmbH [www.outdoor-training.de]
Handelsregister HRB Kaiserslautern 3587
Geschäftsführer Birgit und Ralf Becker
Leibnizstr. 17, 67663 Kaiserslautern, Germany
Telefon +49 (0)631 31657-0

---

–
Best Regards,
Aleksander Adamowski
http://olo.org.pl

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[jaytraxx]

Hi,

for the reason that time is a very expensive good at the moment, I will plan to put it within the next 2 weeks into trunk … ok?

Bye
Christian

On 11/8/07, Ralf Becker RalfBecker@outdoor-training.de wrote:

I can only agree, SMS notification should be a plugin of the notifcation
app and not be coded in the calendar.

That’s wonderful, it would spare me a lot of work!

But when will I be able to put my hands around the new
notification-app code? Our customer is expecting a schedule for that
implementation…

jaytraxx schrieb:

Hi Aleksander,

the functionality you think of should be implemented as plugin for the new
notifications-app and not in calendar itself !

I already wrote two additional plugins for notifications (e-mail and
winpopup) and made notifications able to handle subjects and attachments.
Also, I made notifications-app ready to handle the type of notification the
user would like to have (e.g. egwpopup first, if that fails send an email,
and so on …) I already sent that to conny and he agreed that I can commit
that to trunk (Ralf, I will contact you before I do that to speak about it).

Since now, I could not find any time to do that, but the code is here and we
run it on our production server. It works good.

So, if this code is in trunk, all you have to do is to write another plugin
-> SMS for notifications-app.
The good thing with notifications-app is the centralized setting for all
notifications (for the user) and the centralized handling of notifications
in the code (we can drop a bit code then, all you need to do is to feed the
notification object with some information).

Good idea?

Bye
Christian

Aleksander Adamowski-3 wrote:

Hi!

I’m preparing to implement a new functionality of alternate calendar alarm
types for eGW Calendar.
Currently it would cover SMS alarms, which would provide a nice
substitution
for SyncML support for mobile devices, which currently doesn’t work with
many devices and configurations. It would also be useful for users of
simpler phones, which aren’t smartphones or don’t support SyncML.

I’m trying to figure out what would be the best architecture for this and
which subsystems would need changes.

Here is the intended functionality from user perspective:

1. When configuring alarms for an event, the user can choose either
   the “email” alarm type (that behaves like the current one) or “sms” (in
   the
   future it should be possible to extend eGW to add new types, e.g.
   winpopup).
2. When the alarm is launched by asyncservices, it should find the
   mobile number for all the accounts in the addressbook (either SQL or
   LDAP -
   preferably without any knowledge about actual configured addressbook
   settings with respect to SQL/LDAP storage of accounts data) and launch
   a
   configured system utility to send SMS messages to them.
3. Configuration could have a form of a customisable PHP function in
   e.g. header.inc.php that accepts the mobile number and notification
   text as an argument and takes care of filtering data and launching
   proper
   system tools to deliver the SMS
4. A user should be able to set a default alarm for new events in the
   calendar preferences, so that he/she doesn’t have to set up alarms for
   all
   new created events, so e.g. he/she always is notified by SMS, unless
   he/she manually deletes the alarm when creating a new event

From my current analysis it seems that I’d have to alter at least the
following classes:

calendar/inc/hook_preferences.inc.php
calendar/inc/class.socal.inc.php
phpgwapi/inc/class.asyncservice.inc.php
phpgwapi/cron/asyncservices.php

What do You think about general idea?

Do you have any advice how to start the implementation?

–
Best Regards,
Aleksander Adamowski
http://olo.org.pl

---

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

–
Ralf Becker
eGroupWare Training & Support ==> http://www.egroupware-support.de
Outdoor Unlimited Training GmbH [www.outdoor-training.de]
Handelsregister HRB Kaiserslautern 3587
Geschäftsführer Birgit und Ralf Becker
Leibnizstr. 17, 67663 Kaiserslautern, Germany
Telefon +49 (0)631 31657-0

---

–
Best Regards,
Aleksander Adamowski
http://olo.org.pl

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[Aleksander_Adamowsk2]

Hi,

for the reason that time is a very expensive good at the moment, I will plan
to put it within the next 2 weeks into trunk … ok?

OK, thanks for the info.

In the meantime, could you simply send me the source of your winpopup
and e-mail plugins, so that I could get a general idea of the API?

–
Best Regards,
Aleksander Adamowski
http://olo.org.pl

---

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[jaytraxx]

Hello again,

Download the following zip-file: notification-app.zip (15.5 KB)
Inside there are the .diffs to 1.4.001 and a readme.

Please note: the current .diffs are a bit weird cause I used an editor which couldn’t handle the tabs correctly. I need to fix that. I will probably also change some code, so just take it to get a picture of it, the final implementation could look a bit different. Have fun !

Bye
Christian

On 11/8/07, jaytraxx christian@jaytraxx.de wrote:

Hi,

for the reason that time is a very expensive good at the moment, I will plan
to put it within the next 2 weeks into trunk … ok?

OK, thanks for the info.

In the meantime, could you simply send me the source of your winpopup
and e-mail plugins, so that I could get a general idea of the API?

–
Best Regards,
Aleksander Adamowski
http://olo.org.pl

---

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[Aleksander_Adamowsk2]

Hello again,

Download the following zip-file:
http://www.nabble.com/file/p13646009/notification-app.zip
notification-app.zip
Inside there are the .diffs to 1.4.001 and a readme.

Please note: the current .diffs are a bit weird cause I used an editor which
couldn’t handle the tabs correctly. I need to fix that. I will probably also
change some code, so just take it to get a picture of it, the final
implementation could look a bit different. Have fun !

OK, great thanks! I’ll have a look!

–
Best Regards,
Aleksander Adamowski
http://olo.org.pl

---

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[Stephane_Gauvin]

Hello Friend…

That could be helpfull ???

http://smstools3.kekekasvi.com/index.php?p=

I don’t know… If is WEB Base or need a modem…

Thanks,

Snoopyski

Hi!

I’m preparing to implement a new functionality of alternate calendar alarm
types for eGW Calendar.
Currently it would cover SMS alarms, which would provide a nice substitution
for SyncML support for mobile devices, which currently doesn’t work with
many devices and configurations. It would also be useful for users of
simpler phones, which aren’t smartphones or don’t support SyncML.

I’m trying to figure out what would be the best architecture for this and
which subsystems would need changes.

Here is the intended functionality from user perspective:

1. When configuring alarms for an event, the user can choose either
   the “email” alarm type (that behaves like the current one) or “sms” (in the
   future it should be possible to extend eGW to add new types, e.g.
   winpopup).
2. When the alarm is launched by asyncservices, it should find the
   mobile number for all the accounts in the addressbook (either SQL or LDAP -
   preferably without any knowledge about actual configured addressbook
   settings with respect to SQL/LDAP storage of accounts data) and launch a
   configured system utility to send SMS messages to them.
3. Configuration could have a form of a customisable PHP function in
   e.g. header.inc.php that accepts the mobile number and notification
   text as an argument and takes care of filtering data and launching proper
   system tools to deliver the SMS
4. A user should be able to set a default alarm for new events in the
   calendar preferences, so that he/she doesn’t have to set up alarms for all
   new created events, so e.g. he/she always is notified by SMS, unless
   he/she manually deletes the alarm when creating a new event

From my current analysis it seems that I’d have to alter at least the
following classes:

calendar/inc/hook_preferences.inc.php
calendar/inc/class.socal.inc.php
phpgwapi/inc/class.asyncservice.inc.php
phpgwapi/cron/asyncservices.php

What do You think about general idea?

Do you have any advice how to start the implementation?

–
Best Regards,
Aleksander Adamowski
http://olo.org.pl

---

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[jaytraxx]

Hi Ralf,

one question … what will be the minimum php version for current trunk
or 1.6 respectively? If it will be php5, I could delete some
"helper"-code which is used now for php4 installations in
notification-app. If 1.6 should still support php4, I will have to keep
the “helper”-code.

Bye
Christian

Ralf Becker schrieb:

I can only agree, SMS notification should be a plugin of the notifcation
app and not be coded in the calendar.

Ralf

jaytraxx schrieb:

Hi Aleksander,

the functionality you think of should be implemented as plugin for the new
notifications-app and not in calendar itself !

I already wrote two additional plugins for notifications (e-mail and
winpopup) and made notifications able to handle subjects and attachments.
Also, I made notifications-app ready to handle the type of notification the
user would like to have (e.g. egwpopup first, if that fails send an email,
and so on …) I already sent that to conny and he agreed that I can commit
that to trunk (Ralf, I will contact you before I do that to speak about it).

Since now, I could not find any time to do that, but the code is here and we
run it on our production server. It works good.

So, if this code is in trunk, all you have to do is to write another plugin
-> SMS for notifications-app.
The good thing with notifications-app is the centralized setting for all
notifications (for the user) and the centralized handling of notifications
in the code (we can drop a bit code then, all you need to do is to feed the
notification object with some information).

Good idea?

Bye
Christian

Aleksander Adamowski-3 wrote:

Hi!

I’m preparing to implement a new functionality of alternate calendar alarm
types for eGW Calendar.
Currently it would cover SMS alarms, which would provide a nice
substitution
for SyncML support for mobile devices, which currently doesn’t work with
many devices and configurations. It would also be useful for users of
simpler phones, which aren’t smartphones or don’t support SyncML.

I’m trying to figure out what would be the best architecture for this and
which subsystems would need changes.

Here is the intended functionality from user perspective:

1. When configuring alarms for an event, the user can choose either
   the “email” alarm type (that behaves like the current one) or “sms” (in
   the
   future it should be possible to extend eGW to add new types, e.g.
   winpopup).
2. When the alarm is launched by asyncservices, it should find the
   mobile number for all the accounts in the addressbook (either SQL or
   LDAP -
   preferably without any knowledge about actual configured addressbook
   settings with respect to SQL/LDAP storage of accounts data) and launch
   a
   configured system utility to send SMS messages to them.
3. Configuration could have a form of a customisable PHP function in
   e.g. header.inc.php that accepts the mobile number and notification
   text as an argument and takes care of filtering data and launching
   proper
   system tools to deliver the SMS
4. A user should be able to set a default alarm for new events in the
   calendar preferences, so that he/she doesn’t have to set up alarms for
   all
   new created events, so e.g. he/she always is notified by SMS, unless
   he/she manually deletes the alarm when creating a new event

From my current analysis it seems that I’d have to alter at least the
following classes:

calendar/inc/hook_preferences.inc.php
calendar/inc/class.socal.inc.php
phpgwapi/inc/class.asyncservice.inc.php
phpgwapi/cron/asyncservices.php

What do You think about general idea?

Do you have any advice how to start the implementation?

–
Best Regards,
Aleksander Adamowski
http://olo.org.pl

---

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

---

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[Ralf_Becker_6]

Hi Christian,

we decided on the last developer meeting - you attended - 1.6 will
require php5.1+

Ralf

Christian Binder schrieb:

Hi Ralf,

one question … what will be the minimum php version for current trunk
or 1.6 respectively? If it will be php5, I could delete some
"helper"-code which is used now for php4 installations in
notification-app. If 1.6 should still support php4, I will have to keep
the “helper”-code.

Bye
Christian

Ralf Becker schrieb:

I can only agree, SMS notification should be a plugin of the notifcation
app and not be coded in the calendar.

Ralf

jaytraxx schrieb:

Hi Aleksander,

the functionality you think of should be implemented as plugin for the new
notifications-app and not in calendar itself !

I already wrote two additional plugins for notifications (e-mail and
winpopup) and made notifications able to handle subjects and attachments.
Also, I made notifications-app ready to handle the type of notification the
user would like to have (e.g. egwpopup first, if that fails send an email,
and so on …) I already sent that to conny and he agreed that I can commit
that to trunk (Ralf, I will contact you before I do that to speak about it).

Since now, I could not find any time to do that, but the code is here and we
run it on our production server. It works good.

So, if this code is in trunk, all you have to do is to write another plugin
-> SMS for notifications-app.
The good thing with notifications-app is the centralized setting for all
notifications (for the user) and the centralized handling of notifications
in the code (we can drop a bit code then, all you need to do is to feed the
notification object with some information).

Good idea?

Bye
Christian

Aleksander Adamowski-3 wrote:

Hi!

I’m preparing to implement a new functionality of alternate calendar alarm
types for eGW Calendar.
Currently it would cover SMS alarms, which would provide a nice
substitution
for SyncML support for mobile devices, which currently doesn’t work with
many devices and configurations. It would also be useful for users of
simpler phones, which aren’t smartphones or don’t support SyncML.

I’m trying to figure out what would be the best architecture for this and
which subsystems would need changes.

Here is the intended functionality from user perspective:

1. When configuring alarms for an event, the user can choose either
   the “email” alarm type (that behaves like the current one) or “sms” (in
   the
   future it should be possible to extend eGW to add new types, e.g.
   winpopup).
2. When the alarm is launched by asyncservices, it should find the
   mobile number for all the accounts in the addressbook (either SQL or
   LDAP -
   preferably without any knowledge about actual configured addressbook
   settings with respect to SQL/LDAP storage of accounts data) and launch
   a
   configured system utility to send SMS messages to them.
3. Configuration could have a form of a customisable PHP function in
   e.g. header.inc.php that accepts the mobile number and notification
   text as an argument and takes care of filtering data and launching
   proper
   system tools to deliver the SMS
4. A user should be able to set a default alarm for new events in the
   calendar preferences, so that he/she doesn’t have to set up alarms for
   all
   new created events, so e.g. he/she always is notified by SMS, unless
   he/she manually deletes the alarm when creating a new event

From my current analysis it seems that I’d have to alter at least the
following classes:

calendar/inc/hook_preferences.inc.php
calendar/inc/class.socal.inc.php
phpgwapi/inc/class.asyncservice.inc.php
phpgwapi/cron/asyncservices.php

What do You think about general idea?

Do you have any advice how to start the implementation?

–
Best Regards,
Aleksander Adamowski
http://olo.org.pl

---

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

---

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

–
Ralf Becker
eGroupWare Training & Support ==> http://www.egroupware-support.de
Outdoor Unlimited Training GmbH [www.outdoor-training.de]
Handelsregister HRB Kaiserslautern 3587
Geschäftsführer Birgit und Ralf Becker
Leibnizstr. 17, 67663 Kaiserslautern, Germany
Telefon +49 (0)631 31657-0

---

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[Aleksander_Adamowsk2]

Hello Friend…

That could be helpfull ???

http://smstools3.kekekasvi.com/index.php?p=

I don’t know… If is WEB Base or need a modem…

Yes, I’m planning to use smsd from smstools (v.2) for SMS sending.

Using smstools is the most common setup on Unix, so I’m planning
implementing the SMS module with them in mind.

I already have a test modem (Elproma RB-24 RS-232C, based on Motorola
G24 module) and am able to send SMS through shell utility. Here’s the
photo of the modem for those interested:

http://img220.imageshack.us/my.php?image=rb24modem01hy6.jpg

–
Best Regards,
Aleksander Adamowski
http://olo.org.pl

---

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[jaytraxx]

I cannot remember … but thx anyway !!!

Bye
Christian

Ralf Becker schrieb:

Hi Christian,

we decided on the last developer meeting - you attended - 1.6 will
require php5.1+

Ralf

Christian Binder schrieb:

Hi Ralf,

one question … what will be the minimum php version for current trunk
or 1.6 respectively? If it will be php5, I could delete some
"helper"-code which is used now for php4 installations in
notification-app. If 1.6 should still support php4, I will have to keep
the “helper”-code.

Bye
Christian

Ralf Becker schrieb:

I can only agree, SMS notification should be a plugin of the notifcation
app and not be coded in the calendar.

Ralf

jaytraxx schrieb:

Hi Aleksander,

the functionality you think of should be implemented as plugin for the new
notifications-app and not in calendar itself !

I already wrote two additional plugins for notifications (e-mail and
winpopup) and made notifications able to handle subjects and attachments.
Also, I made notifications-app ready to handle the type of notification the
user would like to have (e.g. egwpopup first, if that fails send an email,
and so on …) I already sent that to conny and he agreed that I can commit
that to trunk (Ralf, I will contact you before I do that to speak about it).

Since now, I could not find any time to do that, but the code is here and we
run it on our production server. It works good.

So, if this code is in trunk, all you have to do is to write another plugin
-> SMS for notifications-app.
The good thing with notifications-app is the centralized setting for all
notifications (for the user) and the centralized handling of notifications
in the code (we can drop a bit code then, all you need to do is to feed the
notification object with some information).

Good idea?

Bye
Christian

Aleksander Adamowski-3 wrote:

Hi!

I’m preparing to implement a new functionality of alternate calendar alarm
types for eGW Calendar.
Currently it would cover SMS alarms, which would provide a nice
substitution
for SyncML support for mobile devices, which currently doesn’t work with
many devices and configurations. It would also be useful for users of
simpler phones, which aren’t smartphones or don’t support SyncML.

I’m trying to figure out what would be the best architecture for this and
which subsystems would need changes.

Here is the intended functionality from user perspective:

1. When configuring alarms for an event, the user can choose either
   the “email” alarm type (that behaves like the current one) or “sms” (in
   the
   future it should be possible to extend eGW to add new types, e.g.
   winpopup).
2. When the alarm is launched by asyncservices, it should find the
   mobile number for all the accounts in the addressbook (either SQL or
   LDAP -
   preferably without any knowledge about actual configured addressbook
   settings with respect to SQL/LDAP storage of accounts data) and launch
   a
   configured system utility to send SMS messages to them.
3. Configuration could have a form of a customisable PHP function in
   e.g. header.inc.php that accepts the mobile number and notification
   text as an argument and takes care of filtering data and launching
   proper
   system tools to deliver the SMS
4. A user should be able to set a default alarm for new events in the
   calendar preferences, so that he/she doesn’t have to set up alarms for
   all
   new created events, so e.g. he/she always is notified by SMS, unless
   he/she manually deletes the alarm when creating a new event

From my current analysis it seems that I’d have to alter at least the
following classes:

calendar/inc/hook_preferences.inc.php
calendar/inc/class.socal.inc.php
phpgwapi/inc/class.asyncservice.inc.php
phpgwapi/cron/asyncservices.php

What do You think about general idea?

Do you have any advice how to start the implementation?

–
Best Regards,
Aleksander Adamowski
http://olo.org.pl

---

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

---

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

---

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[jaytraxx]

Hi,

I improved the whole thing towards php5 and some other features the last weeks, and sent it to Ralf. If I get the authorization, I will commit it to trunk asap.

Bye
Christian

On 11/8/07, jaytraxx christian@jaytraxx.de wrote:

Hello again,

Download the following zip-file:
http://www.nabble.com/file/p13646009/notification-app.zip
notification-app.zip
Inside there are the .diffs to 1.4.001 and a readme.

Please note: the current .diffs are a bit weird cause I used an editor which
couldn’t handle the tabs correctly. I need to fix that. I will probably also
change some code, so just take it to get a picture of it, the final
implementation could look a bit different. Have fun !

OK, great thanks! I’ll have a look!

–
Best Regards,
Aleksander Adamowski
http://olo.org.pl

---

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[jaytraxx]

Hi again,

just committed my work to /trunk. Have fun (and write a cute SMS-backend for us …

Bye
Christian

On 11/8/07, jaytraxx christian@jaytraxx.de wrote:

Hello again,

Download the following zip-file:
http://www.nabble.com/file/p13646009/notification-app.zip
notification-app.zip
Inside there are the .diffs to 1.4.001 and a readme.

Please note: the current .diffs are a bit weird cause I used an editor which
couldn’t handle the tabs correctly. I need to fix that. I will probably also
change some code, so just take it to get a picture of it, the final
implementation could look a bit different. Have fun !

OK, great thanks! I’ll have a look!

–
Best Regards,
Aleksander Adamowski
http://olo.org.pl

---

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers