| View previous topic :: View next topic |
| Author |
Message |
Emil Isberg
Guest
|
 Posted: Sun May 01, 2005 Post subject: A few needed changes |
 |
|
In plans_import.pl it does not correctly set all_day_event when adding to database.
In plans_lib.pl sub load_events you really need to move up the $max_event_id calculating to above the checkinf of what calender the caller asked for. The reason for this is that it is used when one create new ids and it has to return the same (total maximum) even if one selects a smaller subset of events/calendars.
Also there is a bug in that when you try to remove a calendar (or change name on a calender) it does not correctly check what calendar one currently use so it tries to remove (or change name) on the calendar with id=0. I have not been able to track it down yet.
Plans: 6.7.1
Os: FreeBSD 4.9
Perl: 5.8.5
Apache: 1.3.x |
|
| Back to top |
|
 |
Guest
|
| Posted: Mon May 02, 2005 Post subject: Re: A few needed changes |
|
|
| Emil Isberg wrote: | | Also there is a bug in that when you try to remove a calendar (or change name on a calender) it does not correctly check what calendar one currently use so it tries to remove (or change name) on the calendar with id=0. I have not been able to track it down yet. |
I am having this problem too and have not been able to figure it out.
version of Plans - 6.7.2
browser type and version - PC: Firefox 1.0 and IE 6.0; Mac: Safari, Firefox, and IE
operating system of the user - PC: Windows XP; Mac: OS X - Panther
operating system of the server running Plans - Linux |
|
| Back to top |
|
|
Guest
|
| Posted: Tue May 03, 2005 Post subject: |
|
|
| Quote: | | In plans_import.pl it does not correctly set all_day_event when adding to database. |
True. plans_import.pl has been a real source of headaches (mostly from multiple versions of MS outlook). Therefore, support for it has been dropped. I'd rather spend time working on Plans' support for the iCal format.
| Quote: | | In plans_lib.pl sub load_events you really need to move up the $max_event_id calculating to above the checkinf of what calender the caller asked for. The reason for this is that it is used when one create new ids and it has to return the same (total maximum) even if one selects a smaller subset of events/calendars. |
Good eyes.  But this is actually ok. The routines which create new ids call load_events("all"). The "all" causes the checking to be ignored. The checking is just there to speed things up a bit during regular operation.
| Quote: |
Also there is a bug in that when you try to remove a calendar (or change name on a calender) it does not correctly check what calendar one currently use so it tries to remove (or change name) on the calendar with id=0. |
This looks like a real bug. I have not been able to duplicate it either, but I suspect it has something to do with how Plans keeps its current calendar id in a cookie. I will keep working on this Please let me know if you discover the cause.
Thanks for reviewing the code, I appreciate it!
- Lloyd |
|
| Back to top |
|
|
NoseyNick
Joined: 29 Apr 2005
Posts: 18
Location: Surrey, UK
|
| Posted: Wed May 04, 2005 Post subject: |
|
|
Possibly here?
| Quote: | local $current_cal_id = $q->param('cal_id') + 0; # +0 ensures numericity
$current_cal_id = $cookie_parms{'cal_id'} if ($current_cal_id eq "");
|
$current_cal_id will never eq "", it may eq "0", but that's a perfectly valid thing for it to be  |
|
| Back to top |
|
|
NoseyNick
Joined: 29 Apr 2005
Posts: 18
Location: Surrey, UK
|
| Posted: Wed May 04, 2005 Post subject: |
|
|
Yup, if I change
| Code: | | local $current_cal_id = $q->param('cal_id') + 0; # +0 ensures numericity |
to | Code: | | local $current_cal_id = $q->param('cal_id'); ### + 0; # +0 ensures numericity |
... you can now edit non-zero calendars again.
It's got to be safer to rework the rest of the logic, but I don't understand it all. |
|
| Back to top |
|
|
|
Search
Register
Profile 
Log in
