zogi - Project Hosting on Google Code

Older Sep 15, 2009 issue 33 (cyclic/recurrent appointments and daylight savings via zogi) Status changed by awill...@whitemice.org - Applied to r2278 of v5.5 (upstream) Status: Fixed Applied to r2278 of v5.5 (upstream) Status: Fixed Sep 15, 2009 r1019 (New Contact & Address attributes ) committed by awill...@whitemice.org - New Contact & Address attributes New Contact & Address attributes Sep 15, 2009 r1018 (Include e-mail value in Team ) committed by awill...@whitemice.org - Include e-mail value in Team Include e-mail value in Team Sep 15, 2009 r1017 (Bulking of projects for retrieval ) committed by awill...@whitemice.org - Bulking of projects for retrieval Bulking of projects for retrieval Sep 14, 2009 Contact (The Contact entity) Wiki page edited by awill...@whitemice.org - Revision r1016 Edited wiki page through web user interface. Revision r1016 Edited wiki page through web user interface. Sep 14, 2009 address (The address entity) Wiki page edited by awill...@whitemice.org - Revision r1015 Edited wiki page through web user interface. Revision r1015 Edited wiki page through web user interface. Sep 11, 2009 issue 33 (cyclic/recurrent appointments and daylight savings via zogi) commented on by awill...@whitemice.org - Applied to zOGI r1014 Applied to zOGI r1014 Sep 11, 2009 r1014 (Applies Tobias' patch for Issue#33 ) committed by awill...@whitemice.org - Applies Tobias' patch for Issue#33 Applies Tobias' patch for Issue#33 Sep 11, 2009 Task (The Task entity) Wiki page edited by awill...@whitemice.org - Revision r1013 Edited wiki page through web user interface. Revision r1013 Edited wiki page through web user interface. Sep 11, 2009 Task (The Task entity) Wiki page edited by awill...@whitemice.org - Revision r1012 Edited wiki page through web user interface. Revision r1012 Edited wiki page through web user interface. Sep 11, 2009 r1011 (Bug#2027 - Help-desk support ) committed by awill...@whitemice.org - Bug#2027 - Help-desk support Bug#2027 - Help-desk support Sep 09, 2009 r1010 (Missed these files in last commit. ) committed by awill...@whitemice.org - Missed these files in last commit. Missed these files in last commit. Sep 09, 2009 r1009 (New mail sending and event notification functionality. ) committed by awill...@whitemice.org - New mail sending and event notification functionality. New mail sending and event notification functionality. Sep 09, 2009 r1008 (Updated HTTP response codes ) committed by awill...@whitemice.org - Updated HTTP response codes Updated HTTP response codes Sep 09, 2009 r1007 (Add WRITE, READONLY, and DELETE flags to Appointment entitie...) committed by awill...@whitemice.org - Add WRITE, READONLY, and DELETE flags to Appointment entities. Add WRITE, READONLY, and DELETE flags to Appointment entities. Aug 28, 2009 issue 39 (Use HTTP 304 for generic putObject failure) reported by awill...@whitemice.org - If a putObject fails respond with a fault code of 304, like the HTTP status 304 - Not modified. If the error is a version issue the response should be 409 (Conflict, Issue#37). If a putObject fails respond with a fault code of 304, like the HTTP status 304 - Not modified. If the error is a version issue the response should be 409 (Conflict, Issue#37). Aug 28, 2009 issue 38 (Use HTTP 403 for unauthorized putObject/deleteObject request...) reported by awill...@whitemice.org - error response for a unauthorized putObject or delete object should be error code 403, like the HTTP status code error response for a unauthorized putObject or delete object should be error code 403, like the HTTP status code Aug 28, 2009 issue 37 (Use HTTP 409 error on conflicting putObject) reported by awill...@whitemice.org - Right now zOGI returns a 500 if a user tries to update an object that is out of date; meaning the clients version is less than the version on the server. This should be changed to be a 409 error. Right now zOGI returns a 500 if a user tries to update an object that is out of date; meaning the clients version is less than the version on the server. This should be changed to be a 409 error. Jul 07, 2009 issue 36 (feature request for searchForObjects: search appointments by...) changed by awill...@whitemice.org - Agree. Status: Accepted Labels: Type-Enhancement −Type-Defect Agree. Status: Accepted Labels: Type-Enhancement −Type-Defect Jul 07, 2009 issue 36 (feature request for searchForObjects: search appointments by...) reported by Tobias.Kaefer - It would be nice, if one could retrieve all recurrent appointments by searching for the parentObjectId It would be nice, if one could retrieve all recurrent appointments by searching for the parentObjectId Jun 15, 2009 issue 33 (cyclic/recurrent appointments and daylight savings via zogi) commented on by Tobias.Kaefer - I think this should solve the issue. I think this should solve the issue. Jun 09, 2009 issue 33 (cyclic/recurrent appointments and daylight savings via zogi) commented on by awill...@whitemice.org - It is an effect of the implementation, if I create an appointment via zOGI the new appointment command gets - [appointment::new] New Appointment; start: time2008-10-24 14:00:00 -0000 [appointment::new] New Appointment; start zone: GMT +00:00:00 [appointment::new] New Appointment; end time: 2008-10-24 15:00:00 -0000 [appointment::new] New Appointment; end zone: GMT +00:00:00 [appointment::new-cyclic] New Cyclic Appointment; start time: 2008-10-25 14:00:00 -0000 [appointment::new-cyclic] New Cyclic Appointment; start zone: GMT +00:00:00 [appointment::new-cyclic] New Cyclic Appointment; end time: 2008-10-25 15:00:00 -0000 [appointment::new-cyclic] New Cyclic Appointment; end zone: GMT +00:00:00 zOGI (and the old XML-RPC daemon) times are all in GMT (this happens in zOGIAction's _makeCalendarDate function; which converts the value to GMT and strips the time zone. <quote> /* if we successfuly aquired a date then make an adjustment to GMT if a timezone was provided; GMT values are not changed. / if ([dateValue isNotNull]) { zoneDiff = [timeZone secondsFromGMTForDate:dateValue]; if (zoneDiff != 0) { dateValue = [dateValue dateByAddingYears:0 months:0 days:0 hours:0 minutes:0 seconds:(zoneDiff -1)]; [dateValue setTimeZone:[NSTimeZone timeZoneWithAbbreviation:@"GMT"]]; return dateValue; </quote> On the other hand if I do it via the webui the appointment::new command receives - [appointment::new] New Appointment; start: time2008-10-24 11:00:00 +0200 [appointment::new] New Appointment; strart zone: MET DST +02:00:00 [appointment::new] New Appointment; end time: 2008-10-24 12:00:00 +0200 [appointment::new] New Appointment; end zone: MET DST +02:00:00 The command's parameters have a time zone; which then [of course] is provided to the subsequent appointment::cyclic-appointment command. I'll make a fix to not convert to GMT for schedular operations if a timeZone was provided; it looks like it should still work. It is an effect of the implementation, if I create an appointment via zOGI the new appointment command gets - [appointment::new] New Appointment; start: time2008-10-24 14:00:00 -0000 [appointment::new] New Appointment; start zone: GMT +00:00:00 [appointment::new] New Appointment; end time: 2008-10-24 15:00:00 -0000 [appointment::new] New Appointment; end zone: GMT +00:00:00 [appointment::new-cyclic] New Cyclic Appointment; start time: 2008-10-25 14:00:00 -0000 [appointment::new-cyclic] New Cyclic Appointment; start zone: GMT +00:00:00 [appointment::new-cyclic] New Cyclic Appointment; end time: 2008-10-25 15:00:00 -0000 [appointment::new-cyclic] New Cyclic Appointment; end zone: GMT +00:00:00 zOGI (and the old XML-RPC daemon) times are all in GMT (this happens in zOGIAction's _makeCalendarDate function; which converts the value to GMT and strips the time zone. <quote> /* if we successfuly aquired a date then make an adjustment to GMT if a timezone was provided; GMT values are not changed. / if ([dateValue isNotNull]) { zoneDiff = [timeZone secondsFromGMTForDate:dateValue]; if (zoneDiff != 0) { dateValue = [dateValue dateByAddingYears:0 months:0 days:0 hours:0 minutes:0 seconds:(zoneDiff -1)]; [dateValue setTimeZone:[NSTimeZone timeZoneWithAbbreviation:@"GMT"]]; return dateValue; </quote> On the other hand if I do it via the webui the appointment::new command receives - [appointment::new] New Appointment; start: time2008-10-24 11:00:00 +0200 [appointment::new] New Appointment; strart zone: MET DST +02:00:00 [appointment::new] New Appointment; end time: 2008-10-24 12:00:00 +0200 [appointment::new] New Appointment; end zone: MET DST +02:00:00 The command's parameters have a time zone; which then [of course] is provided to the subsequent appointment::cyclic-appointment command. I'll make a fix to not convert to GMT for schedular operations if a timeZone was provided; it looks like it should still work. Jun 08, 2009 r1006 (Test case for issue#33 ) committed by awill...@whitemice.org - Test case for issue#33 Test case for issue#33 Jun 07, 2009 issue 33 (cyclic/recurrent appointments and daylight savings via zogi) commented on by Tobias.Kaefer - BTW: With the legacy XML-RPC-API you have the same problem! BTW: With the legacy XML-RPC-API you have the same problem! May 21, 2009 Appointment (The Appointment entity dictionary) Wiki page edited by awill...@whitemice.org May 13, 2009 r1004 (Removed superfluos log messages when profiling ) committed by awill...@whitemice.org - Removed superfluos log messages when profiling Removed superfluos log messages when profiling May 13, 2009 r1003 (Supress the stupid "sending empty calendar panel" messages u...) committed by awill...@whitemice.org - Supress the stupid "sending empty calendar panel" messages unless debugging is enabled. Supress the stupid "sending empty calendar panel" messages unless debugging is enabled. May 13, 2009 r1002 (Update test scripts ) committed by awill...@whitemice.org - Update test scripts Update test scripts May 12, 2009 r1001 (Fixed building (provided you have ogo-gnustep make in /opt/O...) committed by awill...@whitemice.org - Fixed building (provided you have ogo-gnustep make in /opt/OGo as provided by the OBS RPMs) Fixed building (provided you have ogo-gnustep make in /opt/OGo as provided by the OBS RPMs) May 12, 2009 r1000 (Deleting version file ) committed by awill...@whitemice.org - Deleting version file Deleting version file May 12, 2009 r999 (Initial mail support ) committed by awill...@whitemice.org - Initial mail support Initial mail support May 12, 2009 r998 (Updating to the version in the latest ZideStore (r2213) ) committed by awill...@whitemice.org - Updating to the version in the latest ZideStore (r2213) Updating to the version in the latest ZideStore (r2213) Mar 30, 2009 Task (The Task entity) Wiki page edited by awill...@whitemice.org Mar 30, 2009 Task (The Task entity) Wiki page edited by awill...@whitemice.org Mar 30, 2009 Task (The Task entity) Wiki page edited by awill...@whitemice.org Mar 30, 2009 Task (The Task entity) Wiki page edited by awill...@whitemice.org Mar 25, 2009 Task (The Task entity) Wiki page edited by awill...@whitemice.org Mar 16, 2009 notification (The notification entity) Wiki page edited by awill...@whitemice.org Jan 08, 2009 issue 35 (Project does not have read/write flags) commented on by adamtaunowilliams - access flags are applied to company objects like: SkyAccessManager accessManager; flags = [NSMutableArray arrayWithCapacity:16]; accessManager = [[self getCTX] accessManager]; if([accessManager operation:@"w" allowedOnObjectIDs:[self _getEOsForPKeys:[_company objectForKey:@"companyId"]] forAccessGlobalID:[self _getGlobalId]]) [flags addObject:@"WRITE"]; else [flags addObject:@"READONLY"] which gives us WRITE or READONLY flags. access flags are applied to company objects like: SkyAccessManager accessManager; flags = [NSMutableArray arrayWithCapacity:16]; accessManager = [[self getCTX] accessManager]; if([accessManager operation:@"w" allowedOnObjectIDs:[self _getEOsForPKeys:[_company objectForKey:@"companyId"]] forAccessGlobalID:[self _getGlobalId]]) [flags addObject:@"WRITE"]; else [flags addObject:@"READONLY"] which gives us WRITE or READONLY flags. Jan 08, 2009 issue 34 (Updating an account wipes team membershot) Status changed by adamtaunowilliams - Believe this to be resolved. Status: Fixed Believe this to be resolved. Status: Fixed Jan 08, 2009 issue 28 (Notification entity is not displaying the timezone of the no...) changed by adamtaunowilliams - Seems like if the user sets their timeZone to GMT, and then sets their timeZone to another value it sticks. Very strange (this is a zOGI putDefaults issue I suspect). zOGI is failing to same the user's requested timeZone sometimes or the Defaults value key isn't always consistent. Status: Accepted Labels: Priority-High −Priority-Medium Seems like if the user sets their timeZone to GMT, and then sets their timeZone to another value it sticks. Very strange (this is a zOGI putDefaults issue I suspect). zOGI is failing to same the user's requested timeZone sometimes or the Defaults value key isn't always consistent. Status: Accepted Labels: Priority-High −Priority-Medium Jan 08, 2009 issue 35 (Project does not have read/write flags) reported by adamtaunowilliams - The Project entity does not supply access flags: read, write, delete. It should The Project entity does not supply access flags: read, write, delete. It should Jan 08, 2009 issue 33 (cyclic/recurrent appointments and daylight savings via zogi) changed by adamtaunowilliams - Can reproduce the problem; start time actually moves one how 9-10 (instead of 10-11) on appointment created via zOGI when it crosses the time change boundry. An appointment created via the WebUI keeps the same time. Same issue occurs if a cycleType of "daily" is specified other than an RRULE. app['cycleEndDate'] = '2008-10-28 00:00' app['cycleType'] = 'daily' Status: Accepted Labels: Priority-High −Priority-Medium Can reproduce the problem; start time actually moves one how 9-10 (instead of 10-11) on appointment created via zOGI when it crosses the time change boundry. An appointment created via the WebUI keeps the same time. Same issue occurs if a cycleType of "daily" is specified other than an RRULE. app['cycleEndDate'] = '2008-10-28 00:00' app['cycleType'] = 'daily' Status: Accepted Labels: Priority-High −Priority-Medium Dec 29, 2008 issue 24 (Assertion failed in file EOGenericRecord.m, line 158) commented on by awill...@whitemice.org - Cannot duplicate on current installation. Cannot duplicate on current installation. Dec 19, 2008 issue 33 (cyclic/recurrent appointments and daylight savings via zogi) commented on by Tobias.Kaefer - Is there any solution for this, yet? Is there any solution for this, yet? Nov 12, 2008 r991 (Make a new branch for testing improvements to the factory co...) committed by adamtaunowilliams - Make a new branch for testing improvements to the factory code. Make a new branch for testing improvements to the factory code. Nov 03, 2008 issue 28 (Notification entity is not displaying the timezone of the no...) commented on by awill...@whitemice.org - The user's defaults file exists in the OGo document root; it is set via the user preferences of the WebUI or the zOGI putObject with a defaults entity (as documented in the Wiki) The user's defaults file exists in the OGo document root; it is set via the user preferences of the WebUI or the zOGI putObject with a defaults entity (as documented in the Wiki) Nov 03, 2008 issue 34 (Updating an account wipes team membershot) commented on by awill...@whitemice.org - Potential fix in r990 and OGo r2162 Potential fix in r990 and OGo r2162 Nov 03, 2008 r990 (Potential fix for Issue#34 ) committed by adamtaunowilliams - Potential fix for Issue#34 Potential fix for Issue#34 Nov 03, 2008 issue 34 (Updating an account wipes team membershot) commented on by awill...@whitemice.org - With zOGIDebugEnabled set to yes... Nov 03 23:53:08 ogo-zidestore-1.5 [9159]: >zOGIRPCAction> saving company assignments for 10100 Nov 03 23:53:08 ogo-zidestore-1.5 [9159]: >zOGIRPCAction> syncing company assignments for 10100: scanning Nov 03 23:53:08 ogo-zidestore-1.5 [9159]: PG0x0x86d73c4 SQL: SELECT t1.company_assignment_id, t1.company_id, t1.db_status, t1.function, t1.is_chief, t1.is_headquarter, t1.sub_company_id FROM company_assignment t1 WHERE sub_company_id=10100 Nov 03 23:53:09 ogo-zidestore-1.5 [9159]: >zOGIRPCAction> syncing company assignments for 10100: changing Nov 03 23:53:09 ogo-zidestore-1.5 [9159]: PG0x0x86d73c4 SQL: DELETE FROM company_assignment WHERE company_assignment_id=11443306 Nov 03 23:53:09 ogo-zidestore-1.5 [9159]: PG0x0x86d73c4 SQL: DELETE FROM company_assignment WHERE company_assignment_id=11443305 Nov 03 23:53:09 ogo-zidestore-1.5 [9159]: PG0x0x86d73c4 SQL: DELETE FROM company_assignment WHERE company_assignment_id=11443304 Nov 03 23:53:09 ogo-zidestore-1.5 [9159]: PG0x0x86d73c4 SQL: DELETE FROM company_assignment WHERE company_assignment_id=11443303 Nov 03 23:53:09 ogo-zidestore-1.5 [9159]: PG0x0x86d73c4 SQL: DELETE FROM company_assignment WHERE company_assignment_id=11443302 Nov 03 23:53:09 ogo-zidestore-1.5 [9159]: PG0x0x86d73c4 SQL: DELETE FROM company_assignment WHERE company_assignment_id=11443301 Nov 03 23:53:09 ogo-zidestore-1.5 [9159]: PG0x0x86d73c4 SQL: DELETE FROM company_assignment WHERE company_assignment_id=11443300 Nov 03 23:53:09 ogo-zidestore-1.5 [9159]: >zOGIRPCAction> saving company 10100 complete Nov 03 23:53:09 ogo-zidestore-1.5 [9159]: PG0x0x86d73c4 SQL: COMMIT TRANSACTION So we are scanning and not dropping all. But we need to avoid entities that are teams. With zOGIDebugEnabled set to yes... Nov 03 23:53:08 ogo-zidestore-1.5 [9159]: >zOGIRPCAction> saving company assignments for 10100 Nov 03 23:53:08 ogo-zidestore-1.5 [9159]: >zOGIRPCAction> syncing company assignments for 10100: scanning Nov 03 23:53:08 ogo-zidestore-1.5 [9159]: PG0x0x86d73c4 SQL: SELECT t1.company_assignment_id, t1.company_id, t1.db_status, t1.function, t1.is_chief, t1.is_headquarter, t1.sub_company_id FROM company_assignment t1 WHERE sub_company_id=10100 Nov 03 23:53:09 ogo-zidestore-1.5 [9159]: >zOGIRPCAction> syncing company assignments for 10100: changing Nov 03 23:53:09 ogo-zidestore-1.5 [9159]: PG0x0x86d73c4 SQL: DELETE FROM company_assignment WHERE company_assignment_id=11443306 Nov 03 23:53:09 ogo-zidestore-1.5 [9159]: PG0x0x86d73c4 SQL: DELETE FROM company_assignment WHERE company_assignment_id=11443305 Nov 03 23:53:09 ogo-zidestore-1.5 [9159]: PG0x0x86d73c4 SQL: DELETE FROM company_assignment WHERE company_assignment_id=11443304 Nov 03 23:53:09 ogo-zidestore-1.5 [9159]: PG0x0x86d73c4 SQL: DELETE FROM company_assignment WHERE company_assignment_id=11443303 Nov 03 23:53:09 ogo-zidestore-1.5 [9159]: PG0x0x86d73c4 SQL: DELETE FROM company_assignment WHERE company_assignment_id=11443302 Nov 03 23:53:09 ogo-zidestore-1.5 [9159]: PG0x0x86d73c4 SQL: DELETE FROM company_assignment WHERE company_assignment_id=11443301 Nov 03 23:53:09 ogo-zidestore-1.5 [9159]: PG0x0x86d73c4 SQL: DELETE FROM company_assignment WHERE company_assignment_id=11443300 Nov 03 23:53:09 ogo-zidestore-1.5 [9159]: >zOGIRPCAction> saving company 10100 complete Nov 03 23:53:09 ogo-zidestore-1.5 [9159]: PG0x0x86d73c4 SQL: COMMIT TRANSACTION So we are scanning and not dropping all. But we need to avoid entities that are teams.

issue 33 (cyclic/recurrent appointments and daylight savings via zogi) commented on by awill...@whitemice.org - It is an effect of the implementation, if I create an appointment via zOGI the new appointment command gets - [appointment::new] New Appointment; start: time2008-10-24 14:00:00 -0000 [appointment::new] New Appointment; start zone: GMT +00:00:00 [appointment::new] New Appointment; end time: 2008-10-24 15:00:00 -0000 [appointment::new] New Appointment; end zone: GMT +00:00:00 [appointment::new-cyclic] New Cyclic Appointment; start time: 2008-10-25 14:00:00 -0000 [appointment::new-cyclic] New Cyclic Appointment; start zone: GMT +00:00:00 [appointment::new-cyclic] New Cyclic Appointment; end time: 2008-10-25 15:00:00 -0000 [appointment::new-cyclic] New Cyclic Appointment; end zone: GMT +00:00:00 zOGI (and the old XML-RPC daemon) times are all in GMT (this happens in zOGIAction's _makeCalendarDate function; which converts the value to GMT and strips the time zone. <quote> /* if we successfuly aquired a date then make an adjustment to GMT if a timezone was provided; GMT values are not changed. */ if ([dateValue isNotNull]) { zoneDiff = [timeZone secondsFromGMTForDate:dateValue]; if (zoneDiff != 0) { dateValue = [dateValue dateByAddingYears:0 months:0 days:0 hours:0 minutes:0 seconds:(zoneDiff * -1)]; [dateValue setTimeZone:[NSTimeZone timeZoneWithAbbreviation:@"GMT"]]; return dateValue; </quote> On the other hand if I do it via the webui the appointment::new command receives - [appointment::new] New Appointment; start: time2008-10-24 11:00:00 +0200 [appointment::new] New Appointment; strart zone: MET DST +02:00:00 [appointment::new] New Appointment; end time: 2008-10-24 12:00:00 +0200 [appointment::new] New Appointment; end zone: MET DST +02:00:00 The command's parameters have a time zone; which then [of course] is provided to the subsequent appointment::cyclic-appointment command. I'll make a fix to not convert to GMT for schedular operations if a timeZone was provided; it looks like it should still work.

It is an effect of the implementation, if I create an appointment via zOGI the new appointment command gets - [appointment::new] New Appointment; start: time2008-10-24 14:00:00 -0000 [appointment::new] New Appointment; start zone: GMT +00:00:00 [appointment::new] New Appointment; end time: 2008-10-24 15:00:00 -0000 [appointment::new] New Appointment; end zone: GMT +00:00:00 [appointment::new-cyclic] New Cyclic Appointment; start time: 2008-10-25 14:00:00 -0000 [appointment::new-cyclic] New Cyclic Appointment; start zone: GMT +00:00:00 [appointment::new-cyclic] New Cyclic Appointment; end time: 2008-10-25 15:00:00 -0000 [appointment::new-cyclic] New Cyclic Appointment; end zone: GMT +00:00:00 zOGI (and the old XML-RPC daemon) times are all in GMT (this happens in zOGIAction's _makeCalendarDate function; which converts the value to GMT and strips the time zone. <quote> /* if we successfuly aquired a date then make an adjustment to GMT if a timezone was provided; GMT values are not changed. */ if ([dateValue isNotNull]) { zoneDiff = [timeZone secondsFromGMTForDate:dateValue]; if (zoneDiff != 0) { dateValue = [dateValue dateByAddingYears:0 months:0 days:0 hours:0 minutes:0 seconds:(zoneDiff * -1)]; [dateValue setTimeZone:[NSTimeZone timeZoneWithAbbreviation:@"GMT"]]; return dateValue; </quote> On the other hand if I do it via the webui the appointment::new command receives - [appointment::new] New Appointment; start: time2008-10-24 11:00:00 +0200 [appointment::new] New Appointment; strart zone: MET DST +02:00:00 [appointment::new] New Appointment; end time: 2008-10-24 12:00:00 +0200 [appointment::new] New Appointment; end zone: MET DST +02:00:00 The command's parameters have a time zone; which then [of course] is provided to the subsequent appointment::cyclic-appointment command. I'll make a fix to not convert to GMT for schedular operations if a timeZone was provided; it looks like it should still work.

Older