Forum OpenACS Q&A: Re: Notification of Calendar Events
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 :)