Forum OpenACS Q&A: Personal calendar creation

Collapse
Posted by Caroline Meeks on
I am in the process of merging SloanSpace with OACS4.6 release and ran accross a problem with calendar/www/index. The current code in OACS4.6 will create a new personal calendar in any package where the user does not currently have a personal calendar. This is not the correct behavior for dotLRN, we only want group calendars for dotlrn_communities.


if {![db_string private_calendar_count_qry {}]} {
    # Create a personal calendar for the user
    calendar::new -owner_id $user_id -private_p "t" -
calendar_name "Personal" -package_id $package_id
}

The query is:

select count(*) from calendars
where package_id= :package_id
and  owner_id= :user_id
and  private_p = 't'
I can fix it easily enough for dotLRN by removing package_id from the query in index.xql, however, this doesn't seem to be the right solution for OACS4.6 as a whole and subsites.

select count(*) from calendars
where  owner_id= :user_id
and  private_p = 't'

I discussed this with Tom Jackson in email and he suggest we post to the bboards and try to get a better understanding of how this was meant to work, then we can try to find a general solution.

This issue has been reported as SDM 1879

Collapse
Posted by Tom Jackson on

My response was that maybe this should be a configuration option, with the query Caroline suggested being the default. I can't see why someone would want separate private calendars for each package.

Does anyone have a suggestion on how to make this an option? Do I put in a simple if for each option?

Long term users should be allowed (as an option) to create any number of private/public calendars. But this code isn't there yet. Comments?

Collapse
Posted by Tom Jackson on

Caroline, Don:

I have added a parameter UserPrivateCalendarPerPackageP to the calendar package.

It works as expected, at least that is what I thought for a few minutes.

The wrinkle and the problem:

  • Wrinkle: parameters are per package, so instances could set the parameter to conflicting values. In useage this shouldn't be a problem, at least I don't think. What could happen depends on when a user creates their first calendar, that is within what package. They could end up with two, or just one calendar if one instance is set to 1 and the other 0.
  • Problem: the calendar procs in the library procedures and on other pages wish to supply a package_id to the query which selects the calendars. This screws up the package which has the parameter set to 0, and didn't get to first create their own calendar. The package instance that did create a calendar works fine. So the issue is a rewrite of more pages, some with optional sql.

    Ideas?

  • Collapse
    Posted by Tom Jackson on

    Hmm, I just noticed the calendars.package_id attribute can be null, so maybe queries could be changed to use this. I don't know if this would be easier or not, i.e. when would calendars be created with a null package_id?