Forum OpenACS Q&A: Calendar Wishlist

Collapse
Posted by Malte Sussdorff on
I was asked what we would need to get calendar pretty in project manager (as the display of project manager deadlines is very very slow).

Here are some random ideas what I think is needed, without looking at what others have done so far (call it a wish list). If you have already done part of the wish list, chime in, and also give some idea what you would calendar like to become.

What is needed:

  • Support for multiple calendars with permissions for every user (already there I guess, unless this works in .LRN at the moment using calendar instances...).
  • Subscription to calendars, so the dates are showing up on your calendar overview. Obviously you would be subscribed to all calendars where you are the lead in the project.
  • Color coding for calendars (I have a version that apparently color codes by category), based on
    • the calendar (you subscribed to)
    • Type of entry (object type of the context_id, be it party_id (for personal calendars), project_id (for projects), tasks, .LRN community ....
    • Category
  • Flag to change the color code. (color code by type, calendar, category)
  • Filter displayed calendar entries based on:
    • Type
    • Calendar
    • Category
    • Minimum Priority (that should be a slider where entries drop out of view if their priority does not make it to the threshold)
  • parent_id of a calendar entry goes to the calendar (see multiple calendar above).
  • Context_id goes to the object (e.g. Task) thereby defining the type of the calendar.
  • Priority for calendars, to define how prominently a calendar is showing up on your overview. Obviously this would be part of the calendar subscription (so per user), not part of the calendar (a calendar can have a different priority for users. E.g. The calendar of your kids is important, but not as important as your work calendar, yet you want to be subscribed to both).
  • Priority for a calendar entry. Though this might sound strange, if you have the task overview you want to get the more important deadlines bigger than the other ones. Obviously you would get a calculated priority based on calendar priority multiplied with the entry priority (if any).
  • Support for a nice Ajax enabled calendar UI which supports multiple colors for calendar entries it displays as well as differing SIZES for calendar entries (big bubble for important tasks, small bubble for others) and the nice slider (to show / hide prioritized entries).
  • Packages that currently store dates can instead store them directly in calendar. In project manager this would look like this:
    • Projects have a calendar each. In this calendar we would have multiple entries for earliest start, deadline, latest finish and so on. Context_id is the project
    • Tasks would have multiple entries as well, but the context_id is the task.
    • Categories would define the type (task_earliest_start, task_deadline, project_deadlines aso.)
    • When displaying a project calendar, you would have different colors for the categories.
I hope this gets some discussion and maybe even collaboration working, as calendar at the moment is one of the things where a cleanup would help a lot.
Collapse
2: Re: Calendar Wishlist (response to 1)
Posted by Dave Bauer on
Malte, I think calendar makes more sense as a display, so putting application specific stuff like "tasks" and "priority" in calendar itself doesn't make sense. It seems there should be a way for a application to display application specific data and color codings (css) in a caendar view.

Previously Don and I discussed mapping objects directly to a calendar, instead of having a seperate calendar item object. This would simplify the mapping of categories etc, that are application specific (sounds like Project Manager in your case) to the objects in the specific application instead of the calendar.

Collapse
3: Re: Calendar Wishlist (response to 1)
Posted by Robert Taylor on
there is an original calendar spec list out there somewhere that I will dig up again.

if anyone could comment i will look at integrating that with comments here and keep a master list available in the wiki if it's not already.

i should note that some people have concerns about the calendar datamodel on various points some of which are: flexibility and speed. it would be great to catalog those concerns as well so we can look at future dev accordingly.

Collapse
4: Re: Calendar Wishlist (response to 1)
Posted by Jon Griffin on
When calendar was created at AD in 2000, it was not meant to be anything but a UI.
Events and some other packages were what held the actual info, so Dave is correct. We should not have any database interaction.
Collapse
5: Re: Calendar Wishlist (response to 2)
Posted by Malte Sussdorff on
So, you are saying that you want to have calendar module just displaying dates and that the dates are stored in each single application? So we are not talking about calender module entries anymore but dates in third applications ?

Not talking technical implementation here, a calendar (not calendar module) for me is a placeholder for events, dates, entries. This can be the birthday of my mother, the deadline of the project and the duration of a conference (with start and end time).

I need one interface for the UI and one place to store the data in a consistent manner.

I need support for multiple calendars (private, public, business, child 1, project related) and I need the UI to be able to display them all at once.

Also note that I use calendar in the meaning of "Outlook calendar", not necessarily the calendar module. So if events et. al. are storing the data, how do we generate the meta calendar (e.g calendar of child1, project calendar that might have dates of an event as well). Would you link the calendar to the object? So the childs calendar would be all calendar entries linked to the child, project calendar would be all the entries linked to the project and so on ?

Collapse
6: Re: Calendar Wishlist (response to 1)
Posted by Jon Griffin on
That is not what I am saying.

One caveat, I haven't used calendar or acs-events since I left AD in 2000. The calendar module was a mess, but acs-events and the other packages were working as expected until the java bug hit.

acs-events has all the logic to store events (at least it should have).
Private and public calendars were all part of the spec. I am mainly saying that any event related data should probably go into acs-events, or if that doesn't work (can't see why it wouldn't), extend acs-events.

That said, I could see a few ancillary tables with non-date data if needed. The whole point was to have events stored in a common data store. That is just good data modeling anyway.