From xmlrpc@opengroupware.org Mon Oct 2 11:09:57 2006 From: xmlrpc@opengroupware.org (Adam Williams) Date: Mon, 02 Oct 2006 06:09:57 -0400 Subject: [OGo-XML-RPC] Resources and appointments In-Reply-To: <451BCD84.1040507@abas.de> References: <44E153AB.7060906@abas.de> <0D904197-BE7D-4902-B37B-2FE6D90C6023@opengroupware.org> <44E1817A.1040100@abas.de> <1155634874.5234.3.camel@aleph.whitemice.org> <44E2BBA1.2090903@abas.de> <1155736806.4057.21.camel@aleph.whitemice.org> <4518BCC6.3070801@abas.de> <1159449182.4200.112.camel@aleph.whitemice.org> <451BCD84.1040507@abas.de> Message-ID: <1159783797.26061.1.camel@ws01.whitemice.org> --=-eYc2iHefsxpV14dUYb2o Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2006-09-28 at 15:26 +0200, Tobias Kaefer wrote: > Adam Tauno Williams: > > Nope, it still works the way it did - by name. I've figured out how to > > do it, I just need to make the patch. If your still working on your > > project I'll see if I can get it out in the next 48 hours. > 48 hours? You promise that? ;) > I would be glad to have it in the next 2 weeks or so. So take yout time. > I was just wondering, if this issue is still on the development schedu Patch: http://bugzilla.opengroupware.org/bugzilla/attachment.cgi?id=465&action=view Example Script: http://bugzilla.opengroupware.org/bugzilla/attachment.cgi?id=466&action=view --=-eYc2iHefsxpV14dUYb2o Content-Disposition: attachment; filename=setResourcesById.patch Content-Type: text/x-patch; name=setResourcesById.patch; charset=utf-8 Content-Transfer-Encoding: 7bit Index: XmlRpcAPI/Actions.subproj/DirectAction+Appointment.m =================================================================== --- XmlRpcAPI/Actions.subproj/DirectAction+Appointment.m (revision 1803) +++ XmlRpcAPI/Actions.subproj/DirectAction+Appointment.m (working copy) @@ -646,6 +646,10 @@ -(id)appointment_setResourcesAction:(id)_app:(id)_resources { SkyAppointmentDocument *app; NSArray *resourceNames; + NSMutableArray *tmp; + EOGlobalID *resourceGID; + EOGenericRecord *resource; + int i; /* If _args is a number convert it to a string */ if ([_app isKindOfClass:[NSNumber class]]) @@ -665,8 +669,29 @@ resourceNames = [_resources componentsSeparatedByString:@","]; } else if ([_resources isKindOfClass:[NSArray class]]) { - resourceNames = _resources; - } + if([_resources isNotEmpty]) { + tmp = [[NSMutableArray alloc] initWithCapacity:[_resources count]]; + if([[_resources objectAtIndex:0] isKindOfClass:[NSNumber class]]) { + /// First object in array is a number + /// Convert these resource ids into resource names + for(i = 0; i < [_resources count]; i++) { + resourceGID = [[[self commandContext] + documentManager] + globalIDForURL:[_resources objectAtIndex:i]]; + if (resourceGID != nil) { + resource = [[self commandContext] + runCommand:@"appointmentresource::get-by-globalid", + @"gid", resourceGID, + nil]; + NSLog(@"%s: resource name: %@", + __PRETTY_FUNCTION__, [[resource valueForKey:@"name"] lastObject]); + [tmp addObject:[[resource valueForKey:@"name"] lastObject]]; + } /// End if resourceGID != nil + } /// End for + resourceNames = tmp; + } else resourceNames = _resources; + } else resourceNames = _resources; + } /// End [_resources isKindOfClass:[NSArray class]] else { return [self faultWithFaultCode:XMLRPC_FAULT_INVALID_PARAMETER reason:@"resource list invalid type"]; --=-eYc2iHefsxpV14dUYb2o Content-Disposition: attachment; filename=updateAppointmentResources.py Content-Type: text/x-python; name=updateAppointmentResources.py; charset=utf-8 Content-Transfer-Encoding: 7bit #!/usr/bin/env python import xmlrpclib server = xmlrpclib.Server('http://awilliam:fred@localhost/RPC2') print "--------------------------" result = server.appointment.getById("11570") print result print "--------------------------" print "--------------------------" server.appointment.setResources(11570, "North Conference Room"); result = server.appointment.getById("11570") print result['resourceNames'] print "--------------------------" server.appointment.setResources(11570, "South Conference Room,North Conference Room"); result = server.appointment.getById("11570") print result['resourceNames'] print "--------------------------" server.appointment.setResources(11570, [ "South Conference Room" ]); result = server.appointment.getById("11570") print result['resourceNames'] print "--------------------------" server.appointment.setResources(11570, [ ]); result = server.appointment.getById("11570") print result['resourceNames'] print "--------------------------" server.appointment.setResources(11570, [ 11700 ]); result = server.appointment.getById("11570") print result['resourceNames'] print "--------------------------" server.appointment.setResources(11570, [ 11700, 11720 ]); result = server.appointment.getById("11570") print result['resourceNames'] --=-eYc2iHefsxpV14dUYb2o-- From xmlrpc@opengroupware.org Tue Oct 3 03:06:53 2006 From: xmlrpc@opengroupware.org (Adam Tauno Williams) Date: Mon, 02 Oct 2006 22:06:53 -0400 Subject: [OGo-XML-RPC] Resources and appointments In-Reply-To: <1159783797.26061.1.camel@ws01.whitemice.org> References: <44E153AB.7060906@abas.de> <0D904197-BE7D-4902-B37B-2FE6D90C6023@opengroupware.org> <44E1817A.1040100@abas.de> <1155634874.5234.3.camel@aleph.whitemice.org> <44E2BBA1.2090903@abas.de> <1155736806.4057.21.camel@aleph.whitemice.org> <4518BCC6.3070801@abas.de> <1159449182.4200.112.camel@aleph.whitemice.org> <451BCD84.1040507@abas.de> <1159783797.26061.1.camel@ws01.whitemice.org> Message-ID: <1159841213.5759.3.camel@aleph.whitemice.org> On Mon, 2006-10-02 at 06:09 -0400, Adam Williams wrote: > On Thu, 2006-09-28 at 15:26 +0200, Tobias Kaefer wrote: > > Adam Tauno Williams: > > > Nope, it still works the way it did - by name. I've figured out how to > > > do it, I just need to make the patch. If your still working on your > > > project I'll see if I can get it out in the next 48 hours. > > 48 hours? You promise that? ;) > > I would be glad to have it in the next 2 weeks or so. So take yout time. > > I was just wondering, if this issue is still on the development schedu > Patch: > http://bugzilla.opengroupware.org/bugzilla/attachment.cgi?id=465&action=view > Example Script: > http://bugzilla.opengroupware.org/bugzilla/attachment.cgi?id=466&action=view If your interest, I've just opened a bug and filed a patch to support appointment notes - http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1793 I've also got a patch on http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1766 to retrieve conflict information. From xmlrpc@opengroupware.org Tue Oct 3 03:08:12 2006 From: xmlrpc@opengroupware.org (Adam Tauno Williams) Date: Mon, 02 Oct 2006 22:08:12 -0400 Subject: [OGo-XML-RPC] Resources and appointments In-Reply-To: <451BD2F4.4070306@abas.de> References: <44E153AB.7060906@abas.de> <0D904197-BE7D-4902-B37B-2FE6D90C6023@opengroupware.org> <44E1817A.1040100@abas.de> <1155634874.5234.3.camel@aleph.whitemice.org> <44E2BBA1.2090903@abas.de> <1155736806.4057.21.camel@aleph.whitemice.org> <4518BCC6.3070801@abas.de> <1159449182.4200.112.camel@aleph.whitemice.org> <451BCD84.1040507@abas.de> <1159450368.4200.122.camel@aleph.whitemice.org> <451BD2F4.4070306@abas.de> Message-ID: <1159841292.5759.6.camel@aleph.whitemice.org> > > BTW, for us non-JAVA developers, what is a > > "JSR168-calendar-portlet"? > The JSR 168-API defines how a functional component is integrated into > a portal-system (we are using http://www.liferay.com). These so called > portlets can be (almost) everything, eg. CMS, WIKI, > Management-Infomation-System etc. Every user can build his (or hers) > own desktop in the browser by placing the portlets in a grid with drag > and drop featured by "sexy" Ajax. > Mostly portlets give a first impression about information that is > stored in other systems. Cool. > The calendar-portlet is an application which gives the users the > possibility to have their calendar beeing displayed in the portal, > side by side with the other applications, informations and/or services > they need. > Any questions? Please ask. Is your portlet going to be free/open-source? Is the portlet read-only or does it allow appointment creation/modification? From xmlrpc@opengroupware.org Wed Oct 4 06:01:29 2006 From: xmlrpc@opengroupware.org (Tobias Kaefer) Date: Wed, 04 Oct 2006 07:01:29 +0200 Subject: [OGo-XML-RPC] Resources and appointments In-Reply-To: <1159841292.5759.6.camel@aleph.whitemice.org> References: <44E153AB.7060906@abas.de> <0D904197-BE7D-4902-B37B-2FE6D90C6023@opengroupware.org> <44E1817A.1040100@abas.de> <1155634874.5234.3.camel@aleph.whitemice.org> <44E2BBA1.2090903@abas.de> <1155736806.4057.21.camel@aleph.whitemice.org> <4518BCC6.3070801@abas.de> <1159449182.4200.112.camel@aleph.whitemice.org> <451BCD84.1040507@abas.de> <1159450368.4200.122.camel@aleph.whitemice.org> <451BD2F4.4070306@abas.de> <1159841292.5759.6.camel@aleph.whitemice.org> Message-ID: <45234029.9080901@abas.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Tauno Williams: > > Cool. I do my best to make it cool ;) > Is your portlet going to be free/open-source? We are thinking about this issue, but we did not made any decision yet. > Is the portlet read-only or does it allow appointment > creation/modification? You can view, create, edit and delete appointments with that portlet. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFI0ApdJJ1JNEzpd0RAqd2AJwM2GK1iGTqxk8iI+cxPrJzSuDuuQCguoi/ rh33Vvq1jY8vszfsI9wi2H8= =uG9h -----END PGP SIGNATURE----- From xmlrpc@opengroupware.org Wed Oct 4 08:26:50 2006 From: xmlrpc@opengroupware.org (Helge Hess) Date: Wed, 4 Oct 2006 09:26:50 +0200 Subject: [OGo-XML-RPC] Resources and appointments In-Reply-To: <45234029.9080901@abas.de> References: <44E153AB.7060906@abas.de> <0D904197-BE7D-4902-B37B-2FE6D90C6023@opengroupware.org> <44E1817A.1040100@abas.de> <1155634874.5234.3.camel@aleph.whitemice.org> <44E2BBA1.2090903@abas.de> <1155736806.4057.21.camel@aleph.whitemice.org> <4518BCC6.3070801@abas.de> <1159449182.4200.112.camel@aleph.whitemice.org> <451BCD84.1040507@abas.de> <1159450368.4200.122.camel@aleph.whitemice.org> <451BD2F4.4070306@abas.de> <1159841292.5759.6.camel@aleph.whitemice.org> <45234029.9080901@abas.de> Message-ID: On Oct 4, 2006, at 07:01, Tobias Kaefer wrote: >> Is your portlet going to be free/open-source? > We are thinking about this issue, but we did not made any decision > yet. BTW: there are also some minimal Portlet examples over here: http://www.opengroupware.org/en/devs/languages/java/ don't know how well they work though. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From xmlrpc@opengroupware.org Mon Oct 23 17:09:16 2006 From: xmlrpc@opengroupware.org (Damon Hart) Date: Mon, 23 Oct 2006 12:09:16 -0400 Subject: [OGo-XML-RPC] limitation on XML-RPC result size? experiencing incomplete result sets Message-ID: <453CE92C.7090007@sundial.com> Hi all - Is there an inherent limit on records contained in or other implicit filtering applied to the result set returned to an XML-RPC query? I'm currently migrating from an old FC1 OGo installation to FC5 OGo 1.1 (trunk) and I'm perplexed because I'm receiving apparently incomplete result sets from XML-RPC search requests to the new server. We maintain notations in person comment fields starting with 'X!' to indicate relevant mailing lists or areas of interest. Part of a Python XML-RPC script to assemble lists issues the following request: result = server.person.fetch( { 'qualifier' : "comment like '*X!*'", 'sortOrderings' : ["name","firstname"], } ) There's a Bryan Tucker record in our database, company_id = 1560250, with X!P in his comment field which should match this qualifier, and his record is returned when the script is run against the old installation. On the new installation, however, "Bryan Tucker" is not returned in the result set even though a number of other valid records are indeed returned (there seem to be a large number of expected records missing other than Bryan Tucker.) The problem is not an issue of data migration or permissions because the qualifier can be altered to "name like 'Tucker'" and the record in question is returned. Based on some earlier posts, I figured perhaps the correct form of the qualifier had changed between the two OGo versions, so I turned on database statement logging and looked at how the XML-RPC request was transformed into a database query. The initial query was exactly as expected: SELECT DISTINCT t2.company_id FROM company_info t1, person t2 WHERE ((( LOWER(t1.comment) LIKE '%x!%' )) AND (t2.db_status <> 'archived')) AND ((t2.is_template_user IS NULL) OR (t2.is_template_user = 0)) AND t2.company_id = t1.company_id In fact, running this query, copied verbatim out of the PostgreSQL log, directly in psql returns a big result set which does include 1560250 (Bryan Tucker). Reading further in the PostgreSQL log, the subsequent queries retrieve the requested information by company_id: SELECT t1.owner_id, t1.is_private, t1.is_readonly, t1.company_id FROM person t1 WHERE t1.company_id IN (628970,290030,617870,323180,623620, . . . ) SELECT t1.owner_id, t1.is_private, t1.is_readonly, t1.company_id FROM person t1 WHERE t1.company_id IN (299270,324100,628970,154640,185680, . . . ) However, 1560250 does not appear in any of these statements, even though it was returned by the first query. It seems that ogo-xmlrpcd effectively ignores this company_id (among others.) Has it been filtered somehow or the result set truncated? Is there a relevant configuration setting which could explain the difference between the two OGo installations? Incidentally, this company_id does not show up in the results of an equivalent fetchIds() XML-RPC request either. Any help would be greatly appreciated, Damon From xmlrpc@opengroupware.org Mon Oct 23 17:48:50 2006 From: xmlrpc@opengroupware.org (xmlrpc@opengroupware.org) Date: Mon, 23 Oct 2006 12:48:50 -0400 Subject: [OGo-XML-RPC] limitation on XML-RPC result size? experiencing incomplete result sets In-Reply-To: <453CE92C.7090007@sundial.com> References: <453CE92C.7090007@sundial.com> Message-ID: <20061023124850.5lpuutav1coc048o@tyr.morrison.iserv.net> > Is there an inherent limit on records contained in or other implicit > filtering applied to the result set returned to an XML-RPC query? This limit is set on the server; obviously generating a massive =20 result set would be a bad thing. The limit applied is specified by the LSMaxSearchCount default; which =20 I think defaults to 100. There is also, I beleive, an internal limit set in the logic layer via =20 the "LSDBFetchRelationCommand_MAX_SEARCH_COUNT" default; but I'm not =20 certain how that one is applied. > However, 1560250 does not appear in any of these statements, even > though it was returned by the first query. It seems that ogo-xmlrpcd Yep, this looks like typical xmlrpcd/DocumentAPI behaviour; first it =20 finds qualified objects and then it marshals them until it hits the =20 limit. > effectively ignores this company_id (among others.) Has it been > filtered somehow or the result set truncated? My guess in truncated > Is there a relevant > configuration setting which could explain the difference between the > two OGo installations? Incidentally, this company_id does not show up > in the results of an equivalent fetchIds() XML-RPC request either. Did you have a limit set on your old server? From xmlrpc@opengroupware.org Mon Oct 23 18:43:36 2006 From: xmlrpc@opengroupware.org (Damon Hart) Date: Mon, 23 Oct 2006 13:43:36 -0400 Subject: [OGo-XML-RPC] Re: limitation on XML-RPC result size? experiencing incomplete result sets In-Reply-To: <453CE92C.7090007@sundial.com> References: <453CE92C.7090007@sundial.com> Message-ID: <453CFF48.4010107@sundial.com> Damon Hart wrote: > Hi all - > > Is there an inherent limit on records contained in or other implicit > filtering applied to the result set returned to an XML-RPC query? > > I'm currently migrating from an old FC1 OGo installation to FC5 OGo > 1.1 (trunk) and I'm perplexed because I'm receiving apparently > incomplete result sets from XML-RPC search requests to the new server. I figured this out and am posting for the (hopefully small) portion of users who are tripped up on the same issue. The LSMaxSearchCount configuration parameter has a documented (http://docs.opengroupware.org/Members/olivier/List%20of%20Defaults/document_view) default value of "". A quick check using Defaults read on the two systems shows LSMaxSearchCount = "" on the old installation but no entry at all on the new installation. A careful look at the logged queries indicates that data was retrieved only on the lowest 100 company_ids which matched the qualifier. Evidently, there is an implicit limit of 100 records returned in the case that LSMaxSearchCount is not set. Setting LSMaxSearchCount in the new installation clears up the problem of truncated result sets. regards, Damon