Calendar
Package Specification Summary for Package: calendar
Summary: | Personal and shared event calendars. |
Description: | Manage group and shared calendars with download. |
Documentation: | Package Documentation |
Maturity: | Mature |
This package depends on: | attachments acs-datetime acs-events acs-lang notifications ref-timezones acs-tcl acs-templating |
Packages that depend on calendar: | calendar-includelet calendar-portlet evaluation project-manager |
Package parameters: |
|
Bug Tracker Summary for Package: calendar
Open Bugs: | 14 |
All Tracked Issues: | 96 |
Latest Bug Opened: | 2018-04-02 orphan acs_activities and recurrences |
Latest Bug Fixed: | 2018-03-20 Calendar fails automated test: Test case acs_tcl__tcl_file_syntax_errors. |
Top Bug Submitters: | Nima Mazloumi (10) Caroline Meeks (10) Dirk Gomez (6) Carl Robert Blesius (6) Vinod Kurup (5) |
Top Bug Fixers: | Dirk Gomez (43) Emmanuelle Raffenne (12) Lars Pind (9) Peter Marklund (5) Don Baccus (4) Deirdre Kane (4) Gustaf Neumann (4) |
Code Metrics Summary for Package: calendar
# Tcl Procs | 55 |
# Tcl Lines | 1604 |
# Tcl Blank Lines | 270 |
# Tcl Comment Lines | 170 |
# Automated Tests | 6 |
# Stored Procedures | PG: 10 ORA: 12 |
# SQL Lines | PG: 849 (blank 127 comments 139) ORA: 914 (blank 144 comments 160) |
# ADP pages | 18 |
# ADP lines | 655 |
# Include pages (calendar/lib/) | 0 |
# Documentation pages | 3 (Package Documentation) |
# Documentation lines | 664 |
Browse Source | API-browser |
Github Repository: | https://github.com/openacs/calendar/tree/oacs-5-10 |
Suggestions for improvement (from /forums/message-view?message_id=432244 ):
- different colors for different calendar sources
- easy and nice printout of week and monthly calendar
- Possibility to link one calendar item to many classes or community on creation or editing
- Attach files
- Change of repeating events after creation (if you have a different repeating sequence there is no way of changing the sequence)
- Site-wide calendar for holidays
- Department-wide calendars.
Sync contacts with contact managers, palm pda's etc.
Note I see a small potential issue. Within one calendar it makes sense to color code by calendar types. When using dotLRN or otherwise aggregating calendars it makes sense to color code by calendar_id (source). It probably never makes sense to do it both ways on the same site. We may need to think this through.
Text taken from Dirk document (2004)
Maintained by Dirk Gomez - last change on 22-Jan-2004.
I am tracking my work on calendar here. Please get in touch with me if you have comments.
Features Completed
- Separated code and presentation
- Notifications
- Removed unused or duplicated code and database queries.
- Proper use of OpenACS permissioning.
Features I am working on currently
- Code clean up
- Documentation of the data model
- CSS/XHTML
Features I will be working on
- The calendar view templates take a lot of parameters some of which require knowledge of the inner workings of the respective template: e. g. currently the calling templates passes in a url_template which determines whether an action on a particular item can be executed. I'll move this to being proper and understandable parameters like create_p or edit_p.
- New parameter Collaborative Calendar: a parameter that allows every user of a community to add, edit, and delete events if set to true.
- New parameter in DotLrn: parametrize whether to show calendar lists for a whole term.
- Allow users to store calendar preferences for example the user default view. The calendar_preferences table already exists, yet isn't used at all.
- Add a toggle: "Show all my events/Only this package's or community's events"
- Use a site-wide categories package to do away with the calendar types and the multiple calendars per package.
- Reminder - make it possible that a user sets a particular time on a calendar item to receive a reminder email
- Multi-day events
- iCal format compatible. Ideally, import/export to Outlook/iCalendar/etc.. via iCal format (by Jade)
- Ability to map any sort of date information in a database to the calendar, this means tickets, bugs, etc. perhaps via a service contract (by Jade)
- There should be any easy UI for specifying what is shown. Both the user and the admin should be able to select these things (the admin sets the range of what is possible, the user can select from those choices) (by Jade)
- Events should be able to span more than a day. Ideally, the UI for this should look good. (by Jade)
- An ability to be able to add data via the calendar as well. Anything that implements the service contract should allow you +to add information on that date as well. For example, add a ticket due that day, or add an event for that day, etc.. (by Jade)
- The calendar needs to be printable (at least for where I work - Jade)
- Desktop and Handheld support - cross-browser and cross-platform compatible (ryan-g2)
- Filters by calendar, keyword, object (e.g. Show all bug deadlines)
- Public event submission (unauthenticated) approved by an admin (ryan-g2)
- Invite people to events (ryan-g2)
- auto-book invitees if preference enabled, otherwise, require confirmation
- if there is a conflict among registered users' schedules, the systems suggests possible times to the inviter.
- people external to the system can be invited.
- Resource Scheduling - Booking (ryan-g2)
- Schedule one resource (room, car, laptop) per calendar
- Non-simultaneous booking (no overlapping times)
- Book an item: suggest alternate times across multiple calendars if asset is unavailable. Example: 5 Smart Cars for rent each have their own calendar; if all are booked from 10 - 11 AM, suggest 9-10 or 11-12 across all calendars.
- Optional bill for booked time (connect with ecommerce module)
Data Model Suggestions
Don:
Calendar items should map arbitrary objects (perhaps only content items) to a given calendar and given acs-events. We shouldn't have to derive special types from cal item type in order to attach it to a calendar (nor should we have to duplicate content to attach it to two calendars as we do now) If we restricted the mapping to content items (i.e. calendar info some sort of content type) we could use the CR's ability to map a template to a given content type or item to make it possible for the calendar package to display calendar item details using that facility, giving the package adding something to the calendar control over how it is displayed. Much more general.
ryan-g2:
Is it possible to optionally link any acs_object to an acs_event object (event)? Examples:
- People attached to a meeting event
- Bug item attached to a deadline
- Location attached to a meeting event [google maps integration]
- Project item attached to a deadline
- Simple time and description (for booking an asset) -- unattached to an object
- Multiple objects: Rent a car C from Time A to Time B and pick it up at Location L (Event linked to two objects C and L). See zipcar.com
From above: "Use a site-wide categories package to do away with the calendar types and the multiple calendars per package."
Features I started work on
I'm listing stuff here on which I am already working, but whose completion is nowhere near finished and there is not even an estimation when it may be finished.
- Integrate libical into AOLserver
- Lift as much as possible from Brandeis' Calendar, see this forum thread
Interesting Links
- iCAL todo items via RSS
- University of Washington's Calendar Requirements Document
- Bedework calendar features
Notes
June 12, 2006 - Solution Grove worked on an AJAX calendar month view that has colors by calendar_types, has mouse overs for item details for each date, and changes months without refreshing the pages. They hope to contribute it at some point. Contact Caroline or Hamilton from Solution Grove if you need an advanced copy.