Forum OpenACS Q&A: Notification of Calendar Events
I'm not sure if this has come up before (apologies if it has!). I've been looking at whether the notifications package can handle calendar events, and come to the conclusion that it cannot, as it seems unaware of time-based notifications (i.e. notification foo needs to be sent at time bar, as opposed to send it on the next sweep).
Is anyone working on this / are there any plans for this?
I know the Collaboraid Events package does something similar, but it's not the same as notification of calendar events.
I'm running on OpenACS 4.5 (acs-kernel 4.5.1, notifications 0.1d), so I may just be out of date with this; on the other hand if not, I can see how it could be done. Anyone interested?
Is something like this you are looking for? http://web.archive.org/web/19990129011014/www.arsdigita.com/remindme/
Yeah I added it to the things to be done. It's not on top of the things I want to do though...here's the list of things I want to do before:
- Finish html/tcl separation
- Use ad_form
- I18Nize the user interface
There won't be data model changes till 5.0!
That said I just committed a lot of calendar code to HEAD. I've most html generation for the calendar views (list, day, week, month) into adps, cleaned up some code, debugged some PostgreSQL queries etc etc Oracle's not properly supported yet, but it's no hard to do that - it's some cut'n'paste work.
I lifted most of the html from Raad's design - thanks for that. Haven't had a good idea for properly showing overlapping appointments in the day view - how can I calculate the proper colspan? More changes to the user interfaces and bug reports are greatly appreciated.
I can't make sense of these files and I couldn't find other files that refer to them and they look very unused, useless, and empty:
Can they be deleted?
There's a subdir called Graphics. Can it be deleted? If so, can someone tell me how to achieve this with CVS? (Already forgot)
A calendar item can have a type - in the code at least. I cannot really make sense of it tho? Where can I define such types? I would create code to assign a type to an item then....
I think the cal-* sub pages were used before OpenForce decided to move html code into library procedures. Not sure what they were trying to do with this idea, but it obviously was a bad one.
In a fresh install from HEAD, the calendar-portlets don't work because they rely on the procs in calendar-display-procs, which isn't there anymore.
Am I missing something?
Item types were put in for dotLRN. They are used to group items as Assignments, Classes, etc.
There is UI from the full calendar portlet to edit the types. It points to calendar/www/calendar-item-types
I used item types in my project management site also. Each project had a calendar and the calendar had item types start date, end date, task etc.
However, I wonder if using categories would be a better integrated long term solution.
Notifications from Calendar:
One wrinkle is you want the notification text to be generated when the notification is sent out, not when the item is created because the text or times might be edited. Currently the notification text is inserted when an notification is created. I think this is also a problem with the current notifications. I think that currently if someone writes a forum message, then edits it, a subsequent batched notification will email the original message, not the most recent edit. This will be a very noticeable problem for calendar. Nothing more useless then a calendar reminder service that doesn't let you know if a time or location has been changed!
When I had to send out updated calendars for a client project I used the cronjob package. Not sure if that is a good general solution but you might want to take a look at it.
Thanks for working on this! Calendar is an extremely important service.
- Emails sent whenever a calendar item is created (like forum alerts)
- Emails sent as a reminder. Those of course need to be timezone-aware.
I outlined some ideas in a bug report: http://openacs.org/bugtracker/openacs/com/notifications/bug?bug%5fnumber=586
Item types are per-calendar currently which means you need to copy in the types for each calendar. This is obviously flexible, but difficult to keep track of, especially if you want to combine a group calendar's items with a personal calendar.
Ben - the result of having notifications on calendar events would effectively produce a RemindMe system, so yes, this is the sort of thing.
Jade - talking to Dirk already :)
Caroline - v. good point about the text!! Something I had not reaslised. I think this can be fixed though. I haven't looked in depth at the cronjob package, but my thoughts are that notifications would (should) be a better choice for this particular functionality.
I thought the item types were simply for labelling events as "Meeting" or "Birthday" or whatever. It's a nice feature if implemented to a sufficient depth (whatever that is!).
Don & Dave - some other good points. My own thoughts were ...
to develop something relatively simple to begin with, then evaluate where to go next, taking into consideration the issues people have come up with.
Calendar apps are tricky beasts IMHO, not least to code, but also when considering required functionality, UI design and integration. Couple that with notifications, mix in what would be ideal (stuff like flexible notifications and calendaring contracts) and we have a good chunk of work.
As Dirk is working on improving the calendar (and doing a sterling job) - an important first step - I'm looking to have a go at coming up with a simple implementation of calendar event notification (simple in that it involves no data model changes and supports a limited set of options to begin with - say "notify me x mins before the event") just to kick off.
Unfortunately I am stuck for the time being with an older version of things (notifs v0.1d), but I am happy to share my solution with anyone who's interested (and willing to incorporate it into the latest version?). Any takers?
i had the same problem for my BT enhancements. Unfortunately the notification package only understands delivery intervals, like instant/hourly/weekly, so you cannot say, notify a person to a certain day.
I resolved the problem checking the db, whether the reminder day = sysdate, and if so, create an "instant" notification. The notification package delivers the notification instantly. The problem is that you have to create a notification request on this calendar event first and then create the notification. You transfer the functionality of checking the date from the notification package to the package calling notifications (in this case calendar).
That's how I resolved this issue, hope that helps.
I see - what you have is something that *creates* an instant notification if the event happens today.
I guess that means the issue still stands, as I believe the way to get this working is to amend the notifications package and make it aware of calendar event notifications and have it treat them differently.
I'm pretty sure this can be made to work with the minimum of changes (none to data model, some to calendar, most to notifications but should be pretty self-contained in notification::sweep::sweep_notifications).
The only bit I'm stuck on is where to store a per-user setting for the "reminder" period, that doesn't involve creating a new field somewhere in the db. I did think of a BIG kludge using parameters (ouch!).
If anyone has any ideas, I'd love to know.
Do notifications go out as per the system timezone, or as per a user preference timezone? Consider the following scenarios:
1/ two users, in different timezones, have personal calendars with reminders - the reminders should fire as per their own timezone
2/ the same users are both in a conference call based off a shared calendar - the reminder should fire as per the calendar time zone
3/ the same users have a "weekly friday meeting at 8am" reminder in a shared calendar, they both should be reminded at 8am in their own timezone.
2 & 3 are difficult to achieve at the same time with a simple easy to understand ui.
there are even more difficult permutations when you sync to a palm pilot, and subsequently fly to a different timezone.
There is no perfect solution, but the final feature set will need to include some level of timezone understanding.
On the other hand I guess a basic solution might help many of us.
What do you mean by not allowing you to correct your errors? Instead of pushing "Confirm" in the confirm screen, you can use back button to get back to the posting form, correct the errors and push ok again (+ eventually confirm if you're pleased with your input).
I agree that this could be noted on the confirm page, though, since it might not be that clear to everyone.
Elfwood has done this actually, before you post you have the option to spell check your posting.
Just realised I could not mark the "red" in font tags to make it more impressive.
Mark - That's another good point. The key to TZ issues is to get the calendar to handle timezones for users, then it should be easier to adjust the notification checking.
I believe (1) will be handled fine when I18N is implemented. I'm not sure what the difference between (2) and (3) is, but again it should be OK (as long as we keep it relatively simple). One thing to consider is the TZ for a shared calendar - I guess each community/subgroup should have a TZ (we need a reference point); or perhaps they should assume a global TZ, set for the instance.
Anyway, I'm sure it will shake out in the end :)
Anyone had any thoughts on my last post?
I do have an alternative to a parameter, but it involves using an existing (unused) field for a different purpose, and it would be good to do something transparent.
Here's my take on noticiation.
Firstly, just like in forums, there should be instantaneous, daily, bi-weekly notifications whenever a calendar item is created or (!) updated.
Secondly we need a reminder. The reminder needs to be sent *prior* to the event, that is why we need the timezone awareness. A straight-forward way to do this is should be:
- The server knows in which timezone it is. (acs-lang has a timezone parameter)
- The user knows in which timezone he is usually - there probably is a user-dependent parameter somewhere hidden in acs-lang. He may be travelling tho!!
The reminder page could tell the user: "We will send you this event by 10:00 am your default timezone. Please change time and timezone according to your needs."
The user knows better where he currently is, and when he wants to receive the respective email. He also quite likely knows whether a particular event is local to his timezone or local to the server's timezone or local to the creator's timezone.
I think both the interface and the code for this solution should easy to implement. We can work on the all-encompassing solution after that :)
I tried that, but instead of getting me back to my edit screen, the message was published straight away. . However whne posting this reply and double checking everything was fine. Must have been the heat in Europe )
The server doesn't need to now what timezone it is since it's a computer. Only (dumb humans use timezones.
Timestamps must always stored in the server in UTC.
When the system shows the user a date, it must format the date with the the language, the timezone and the format the user has selected it his/her profile.
Dirk, you are missing what I've said when you are saying this: "He also quite likely knows whether a particular event is local to his timezone or local to the server's timezone or local to the creator's timezone."
As I said the timezone is just a way to see the date. The server is always UTC, it shouldn't know about timezones.
This is the scenario:
"weekly Friday meeting at 08:00" (The user's timezone is Central Europe, this means +0100 in Winter and +0200 in Summer)
So, what does this mean? (Two cases)
· The daylight savings in effect are from the timezone of the originator user. So there are weekly Friday meeting at 07:00 UTC in _winter_ and at 06:00 UTC in _summer_. This would favor Europeans (and other people with daylight savings), since European Union official schedules are supposed to change in summer to save energy.
· There's no daylight savings. So there are weekly Friday meeting at 06:00 UTC in _winter_ and in _summer_, since the appointment was setup in summer. This would favor international users with other daylight savings or no
daylight savings at all.
This means the user should be able to address this problem selecting the timezone the schedule is to be set up.
What we need is mock-ups that show a tiemzone-aware user interface which is *not* confusing and reasonably easy to use. Someone got a proposal?
If an event calendar is going to be time zone aware, the time zone (location) of the event must also be known. Knowing just the time zone of the user isn't really enough. Hey, what if something happens in Arizona, the scheduler is in California and another user is in New York, or worse, Iran. Plus you need the ability for the user to change time zones as they travel. Maybe some of this could be automated with an ip map?
Seems that time stuff can be very hard, and a dumb solution might be better than a half solved, difficult to use one.
Dirk, I don't think it was you that moved html into the library procedures, or am I wrong? I believe OpenForce did a major half-rewrite leaving things in a different, but not any better, state. Things in the cal-* files, which would have been an easy place to make changes to html, were moved into library procedures, where every change requires a restart, or resourcing of the tcl procs.
It sounds to me like you are working on moving html out of the tcl procs and tcl files, which I think is very helpful for making Calendar more adaptable.
At any rate, anyone working on Calendar should be give as much moral support as possible. I fixed a few bugs after OF was finished, and was working on more fixes when I realized what a mess the package was in and gave up. Thanks for stepping up and working on it.
2. Dates are stored with timezone in OpenACS 4.x in PG. This is due to PostgreSQL history. Changing it would be a PITA (though PG does now support timestamp with no timezone)
3. Today's mail systems like Exchange/Outlook use icalendar format to pass along date information. The scheduling issues are handled by having the calendar server transmit not only the date of an event but the full timezone descriptor which includes transition dates for Daylight (Summer) time, etc.
The user's client uses that information to map the dates to the client's local time ...
I think we can do the same without too much trouble ... we have all the timezone transition information in ref-timezones.
One of my students built SMS and email alerts for the calendar last year. You might find useful code/documentation at:
BTW, for the SMS you will need an account at www.smsdirect.uk.com
If you were to work on either package, it would be *really* easy to hook either of them into calendar and make calendar send emails well in advance of an event.