From developer@opengroupware.org Thu May 8 03:21:11 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Wed, 07 May 2008 22:21:11 -0400 Subject: [OGo-Developer] Bug#929 Committed (AsteriskDialer) Message-ID: <1210213271.4717.3.camel@aleph> I've committed the Asterisk CTI dialer bundle from bug#929 -- Consonance: an Open Source .NET OpenGroupware client. Contact:awilliam@whitemiceconsulting.com http://freshmeat.net/projects/consonance/ From developer@opengroupware.org Thu May 8 07:53:05 2008 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Thu, 08 May 2008 08:53:05 +0200 Subject: [OGo-Developer] Bug#929 Committed (AsteriskDialer) Message-ID: <20080508065306.1844C4D9E0@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > I've committed the Asterisk CTI dialer bundle from bug#929 > Great, many thanks. Now I need to figure out, how to build rpm's including the dialer ;) cheers Sebastian > -- > Consonance: an Open Source .NET OpenGroupware client. > Contact:awilliam@whitemiceconsulting.com http://freshmeat.net/projects/consonance/ > > -- > OpenGroupware.org Developer > developer@opengroupware.org > http://mail.opengroupware.org/mailman/listinfo/developer > From developer@opengroupware.org Fri May 9 12:09:21 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Fri, 09 May 2008 07:09:21 -0400 Subject: [OGo-Developer] 05_historyProject? Message-ID: <1210331361.12010.8.camel@aleph> I was looking for a bug in Project Logic when I bumped into this bit I hadn't noticed before. - (void)_checkForHistoryProject { id obj; NSString *pName; NSString *pKind; obj = [self object]; pName = [obj valueForKey:@"name"]; pKind = [obj valueForKey:@"kind"]; if ([pName hasPrefix:@"History - "]) [obj takeValue:@"05_historyProject" forKey:@"kind"]; else if (pKind != nil && [pKind isEqualToString:@"05_historyProject"]) [obj takeValue:[EONull null] forKey:@"kind"]; } This method is called from the commands _prepareForExecutionInContext method. Looks like it forces the kind field to "05_historyProject" if the name of the project starts with "History -". This occurs in both the new and set commands relating to projects. Otherwise the project types are only used to exclude various projects from the WebUI: @"00_invoiceProject", @"05_historyProject", @"10_edcProject", I assume this is just derelict gunk from a previous feature? Can it be removed? From developer@opengroupware.org Fri May 9 12:14:14 2008 From: developer@opengroupware.org (Helge Hess) Date: Fri, 9 May 2008 13:14:14 +0200 Subject: [OGo-Developer] 05_historyProject? In-Reply-To: <1210331361.12010.8.camel@aleph> References: <1210331361.12010.8.camel@aleph> Message-ID: <2BBD12CB-FA93-44B1-8C56-925734EB8CAA@opengroupware.org> On 09.05.2008, at 13:09, Adam Tauno Williams wrote: > This occurs in both the new and set commands relating to projects. > Otherwise the project types are only used to exclude various projects > from the WebUI: @"00_invoiceProject", @"05_historyProject", > @"10_edcProject", > > I assume this is just derelict gunk from a previous feature? Can it > be removed? Can be removed, I'm not aware of any frontend which makes use of that. EDC is customer specific, I don't remember what history-project was. Thanks, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Fri May 9 14:07:55 2008 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Fri, 09 May 2008 15:07:55 +0200 Subject: [OGo-Developer] 05_historyProject? Message-ID: <20080509130755.624194DF73@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > On 09.05.2008, at 13:09, Adam Tauno Williams wrote: > > This occurs in both the new and set commands relating to projects. > > Otherwise the project types are only used to exclude various projects > > from the WebUI: @"00_invoiceProject", @"05_historyProject", > > @"10_edcProject", > > > > I assume this is just derelict gunk from a previous feature? Can it > > be removed? > > Can be removed, I'm not aware of any frontend which makes use of that. > EDC is customer specific, I don't remember what history-project was. I think, if someone wants to use the Invoice App for testing/playing around, It would be great, if you could create a patch, that could be placed into Misc/Invoice, to add the functionality for people that want it. kind regards Sebastian From developer@opengroupware.org Fri May 9 14:37:49 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Fri, 09 May 2008 09:37:49 -0400 Subject: [OGo-Developer] 05_historyProject? In-Reply-To: <20080509130755.624194DF73@smtp.l00-bugdead-prods.de> References: <20080509130755.624194DF73@smtp.l00-bugdead-prods.de> Message-ID: <20080509093749.nbw8uo66lckkkokg@tyr.morrison.iserv.net> >> On 09.05.2008, at 13:09, Adam Tauno Williams wrote: >> > This occurs in both the new and set commands relating to projects. >> > Otherwise the project types are only used to exclude various projects >> > from the WebUI: @"00_invoiceProject", @"05_historyProject", >> > @"10_edcProject", >> > I assume this is just derelict gunk from a previous feature? Can it >> > be removed? >> Can be removed, I'm not aware of any frontend which makes use of that. >> EDC is customer specific, I don't remember what history-project was. > I think, if someone wants to use the Invoice App for testing/playing aroun= d, > It would be great, if you could create a patch, that could be placed into > Misc/Invoice, to add the functionality for people that want it. Both the DocumentAPI and the WebUI specifically exclude kinds of =20 projects like - v =3D [[NSArray alloc] initWithObjects: @"00_invoiceProject", @"05_historyProject", @"10_edcProject", @"15_accountLog", nil]; - although I think the feature is inconsistently implemented. By suggestion is we eliminate the hardcoded project kinds, especially =20 from Logic, and either filter out all the projects in the DocumentAPI =20 where the kind is not null (specific applications would use Logic =20 directly anyway?) or make the filtered projects a default. This filtering happens in: DocumentAPI/OGoProject/SkyProjectDataSource.m DocumentAPI/OGoDatabaseProject/SkyProjectDocumentDataSource.m WebUI/Project/LSWProject/SkyProjectAssignment.m The capturing of the "History" description happens in both =20 Logic/LSProject/LSNewProjectCommand.m and =20 Logic/LSProject/LSSetProjectCommand.m: From developer@opengroupware.org Fri May 9 14:50:35 2008 From: developer@opengroupware.org (Helge Hess) Date: Fri, 9 May 2008 15:50:35 +0200 Subject: [OGo-Developer] 05_historyProject? In-Reply-To: <20080509093749.nbw8uo66lckkkokg@tyr.morrison.iserv.net> References: <20080509130755.624194DF73@smtp.l00-bugdead-prods.de> <20080509093749.nbw8uo66lckkkokg@tyr.morrison.iserv.net> Message-ID: <319B43DC-FBB4-497F-9FE6-A6A9AC600742@opengroupware.org> On 09.05.2008, at 15:37, Adam Tauno Williams wrote: > By suggestion is we eliminate the hardcoded project kinds, > especially from Logic, I'm fine with that. > and either filter out all the projects in the DocumentAPI where the > kind is not null (specific applications would use Logic directly > anyway?) or make the filtered projects a default. Actually the WebUI already allows configurable filtering (configurable tabs in the projects application). Maybe this would need to be added to more panels. From the (very old) internal Skyrix database: ---snip--- OGoSx=> SELECT kind, COUNT(*) FROM project GROUP BY kind; kind | count -------------------+------- | 4867 05_historyProject | 2233 00_invoiceProject | 452 (3 rows) ---snap--- Seems there are quite a few history projects. No idea what they were good for. Maybe the core idea was indeed to have a project which doesn't show up as a regular project? Don't remember. It should be filtered in the UI in any case. Greets, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Fri May 9 16:02:43 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Fri, 09 May 2008 11:02:43 -0400 Subject: [OGo-Developer] 05_historyProject? In-Reply-To: <319B43DC-FBB4-497F-9FE6-A6A9AC600742@opengroupware.org> References: <20080509130755.624194DF73@smtp.l00-bugdead-prods.de> <20080509093749.nbw8uo66lckkkokg@tyr.morrison.iserv.net> <319B43DC-FBB4-497F-9FE6-A6A9AC600742@opengroupware.org> Message-ID: <1210345363.8968.8.camel@WM_ADAM1.morrison.iserv.net> On Fri, 2008-05-09 at 15:50 +0200, Helge Hess wrote: > On 09.05.2008, at 15:37, Adam Tauno Williams wrote: > > By suggestion is we eliminate the hardcoded project kinds, > > especially from Logic, > I'm fine with that. Removed from Logic in r2109; I created a project with a name of "History - ..." and the kind remained null. I'd guess the "feature" came from - Thu Aug 17 19:30:46 2000 Joerg Grimm * LSNewProjectCommand.m, LSSetProjectCommand.m: kind 05_historyProject is set for projects with name prefix 'History - ' From developer@opengroupware.org Fri May 9 16:09:31 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Fri, 09 May 2008 11:09:31 -0400 Subject: [OGo-Developer] 05_historyProject? In-Reply-To: <319B43DC-FBB4-497F-9FE6-A6A9AC600742@opengroupware.org> References: <20080509130755.624194DF73@smtp.l00-bugdead-prods.de> <20080509093749.nbw8uo66lckkkokg@tyr.morrison.iserv.net> <319B43DC-FBB4-497F-9FE6-A6A9AC600742@opengroupware.org> Message-ID: <1210345771.8968.14.camel@WM_ADAM1.morrison.iserv.net> > Actually the WebUI already allows configurable filtering (configurable > tabs in the projects application). Yep. > Maybe this would need to be added to more panels. > From the (very old) internal Skyrix database: > ---snip--- > OGoSx=> SELECT kind, COUNT(*) FROM project GROUP BY kind; > kind | count > -------------------+------- > | 4867 > 05_historyProject | 2233 > 00_invoiceProject | 452 > (3 rows) Interesting; I've got none, but my database only goes back to 2003. > ---snap--- > Seems there are quite a few history projects. No idea what they were > good for. > Maybe the core idea was indeed to have a project which doesn't show up > as a regular project? Don't remember. This is one of the things we are doing; using projects for containers. > It should be filtered in the UI in any case. The "kind" can't be set via the WebUI; what it is best way to replace the current filter? Just filter out everything where kind isn't NULL or to create a default? Since you can't set kind via the WebUI I don't see how it would ever get set for "normal" projects, thus a kind value indicates the project is something other than normal. From developer@opengroupware.org Fri May 9 16:14:48 2008 From: developer@opengroupware.org (Helge Hess) Date: Fri, 9 May 2008 17:14:48 +0200 Subject: [OGo-Developer] 05_historyProject? In-Reply-To: <1210345771.8968.14.camel@WM_ADAM1.morrison.iserv.net> References: <20080509130755.624194DF73@smtp.l00-bugdead-prods.de> <20080509093749.nbw8uo66lckkkokg@tyr.morrison.iserv.net> <319B43DC-FBB4-497F-9FE6-A6A9AC600742@opengroupware.org> <1210345771.8968.14.camel@WM_ADAM1.morrison.iserv.net> Message-ID: <9D8DC6F2-FA07-47CE-929C-0EF82B658C46@opengroupware.org> On 09.05.2008, at 17:09, Adam Tauno Williams wrote: >> It should be filtered in the UI in any case. > > The "kind" can't be set via the WebUI; what it is best way to > replace the current filter? Just filter out everything where kind > isn't NULL or to create a default? I would create some kind of default. An EOQualifier default which restricts the projects which show up in 'other' places. Eg: "kind = nil OR name LIKE 'Show up*'" Don't know how much work that is (how many components access the kind). I don't think its very important. > Since you can't set kind via the WebUI I don't see > how it would ever get set for "normal" projects, thus a kind value > indicates the project is something other than normal. Well, yes, those are set by custom applications currently. But a set kind does not necessarily imply that the project must not show up. Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Fri May 9 17:32:43 2008 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Fri, 09 May 2008 18:32:43 +0200 Subject: [OGo-Developer] Bug#929 Committed (AsteriskDialer) Message-ID: <20080509163244.376C84E05A@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > developer@opengroupware.org wrote: > > I've committed the Asterisk CTI dialer bundle from bug#929 > > It does not show up in the changeblogger, shouln't it? Sebastian From developer@opengroupware.org Fri May 9 18:52:43 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Fri, 09 May 2008 13:52:43 -0400 Subject: [OGo-Developer] Bug#929 Committed (AsteriskDialer) In-Reply-To: <20080509163244.376C84E05A@smtp.l00-bugdead-prods.de> References: <20080509163244.376C84E05A@smtp.l00-bugdead-prods.de> Message-ID: <1210355563.8968.17.camel@WM_ADAM1.morrison.iserv.net> > developer@opengroupware.org wrote: > > developer@opengroupware.org wrote: > > > I've committed the Asterisk CTI dialer bundle from bug#929 > > > > It does not show up in the changeblogger, shouln't it? There is no ChangeLog in that folder; there isn't one for the other CTI dialer either. I believe the changeblogger only trolls for ChangeLog files. From developer@opengroupware.org Fri May 9 19:30:23 2008 From: developer@opengroupware.org (=?ISO-8859-1?Q?Marcus_M=FCller?=) Date: Fri, 9 May 2008 20:30:23 +0200 Subject: [OGo-Developer] Bug#929 Committed (AsteriskDialer) In-Reply-To: <1210355563.8968.17.camel@WM_ADAM1.morrison.iserv.net> References: <20080509163244.376C84E05A@smtp.l00-bugdead-prods.de> <1210355563.8968.17.camel@WM_ADAM1.morrison.iserv.net> Message-ID: <791BAE18-48A1-4E1A-B665-4A9E574AE0CE@mulle-kybernetik.com> --Apple-Mail-22-122389487 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 09.05.2008, at 19:52, Adam Tauno Williams wrote: >> developer@opengroupware.org wrote: >>> developer@opengroupware.org wrote: >>>> I've committed the Asterisk CTI dialer bundle from bug#929 >>>> >> It does not show up in the changeblogger, shouln't it? > > There is no ChangeLog in that folder; there isn't one for the other > CTI > dialer either. I believe the changeblogger only trolls for ChangeLog > files. Correct - and even then, only those that he knows of. Cheers, Marcus -- Marcus Mueller . . . crack-admin/coder ;-) Mulle kybernetiK . http://www.mulle-kybernetik.com Current projects: http://www.mulle-kybernetik.com/znek/ --Apple-Mail-22-122389487 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On 09.05.2008, at = 19:52, Adam Tauno Williams wrote:

developer@opengroupware.org wrote:
developer@opengroupware.org wrote:
I've = committed the Asterisk CTI dialer bundle from = bug#929
<= http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=3D929>
<= /blockquote>
It does = not show up in the changeblogger, shouln't it?

There = is no ChangeLog in that folder;  there isn't one for the other = CTI
dialer either.  I believe the changeblogger only trolls for = ChangeLog
files.

Correct - = and even then, only those that he knows of.

Cheers,


  Marcus


-- 

Marcus Mueller  .  .  .  crack-admin/coder = ;-)

Mulle = kybernetiK  .  http://www.mulle-kybernetik.com

Current = projects: http://www.mulle-kybernetik= .com/znek/


 =

= --Apple-Mail-22-122389487-- From developer@opengroupware.org Sat May 10 15:28:11 2008 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Sat, 10 May 2008 16:28:11 +0200 Subject: [OGo-Developer] Bug#929 Committed (AsteriskDialer) Message-ID: <20080510142812.09B764E1AD@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > > On 09.05.2008, at 19:52, Adam Tauno Williams wrote: > > >> developer@opengroupware.org wrote: > >>> developer@opengroupware.org wrote: > >>>> I've committed the Asterisk CTI dialer bundle from bug#929 > >>>> > >> It does not show up in the changeblogger, shouln't it? > > > > There is no ChangeLog in that folder; there isn't one for the other > > CTI > > dialer either. I believe the changeblogger only trolls for ChangeLog > > files. > > > Correct - and even then, only those that he knows of. ah, just was curious. thanks Sebastian From developer@opengroupware.org Sun May 11 14:52:07 2008 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Sun, 11 May 2008 15:52:07 +0200 Subject: [OGo-Developer] SkyPersonalAttribuesViewer and values from obj_properties tables Message-ID: <20080511135207.99B994E41A@smtp.l00-bugdead-prods.de> Hi, I'm working on extended task attributes, as explained in enhancement in ogo bugzilla #1043. I got LSWJobEditor working, so it stores and retrieves the values in the obj_properties table in the database. Now I'm struggling a bit with LSWJobViewer. It is using the SkyPersonalAttribuesViewer to show and edit the values. The extended fields when I click on the configure button, and they show up. Unfortunately, it does not seem to retrieve the values for the extended keys. The SkyPersonalAttributesViewer is only used in other places for Enterprises and Persons, but these store their extended values otherwise, therefore not good as example. To implement the extended task attributes, I took the extended project attributes as an example, but the project attribues viewer, is not using the SkyPersonalAttributesViewer. Do I need to "prepare" these extra properties in a special way so that the SkyPersonalAttributesViewer would be able to retreive and show them in the WebUI? kind regards Sebastian From developer@opengroupware.org Tue May 13 10:39:36 2008 From: developer@opengroupware.org (Helge Hess) Date: Tue, 13 May 2008 11:39:36 +0200 Subject: [OGo-Developer] FYI: time constrained company_value attributes Message-ID: <78BA8776-8D7D-43D6-8B03-43DC4E37DDC2@opengroupware.org> Hi, JFYI: in my 5.4 DB changes I have extended company_value with a timerange, that is, a startdate/enddate. Now you can basically have multiple, time constrained values. (eg key="membership", value="live", from=2001-03-10, to=null) Note that company_value always had an is_enum column which allowed multiple values (and therefore records) per key, not sure whether thats used a lot and whether it can be configured. Not sure how the current UI deals with all that, we'll see :-) Greets, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Tue May 13 11:04:08 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Tue, 13 May 2008 06:04:08 -0400 Subject: [OGo-Developer] FYI: time constrained company_value attributes In-Reply-To: <78BA8776-8D7D-43D6-8B03-43DC4E37DDC2@opengroupware.org> References: <78BA8776-8D7D-43D6-8B03-43DC4E37DDC2@opengroupware.org> Message-ID: <1210673048.5574.9.camel@aleph> > JFYI: in my 5.4 DB changes I have extended company_value with a > timerange, that is, a startdate/enddate. Now you can basically have > multiple, time constrained values. (eg key="membership", value="live", > from=2001-03-10, to=null) Are schema changes going to be committed soon? Having the companyId added to the notes table would be useful for us at this point. > Note that company_value always had an is_enum column which allowed > multiple values (and therefore records) per key, not sure whether > thats used a lot and whether it can be configured. I don't think I've seen a reference to such behavior before. > Not sure how the current UI deals with all that, we'll see :-) I'm guessing - badly! :) From developer@opengroupware.org Tue May 13 11:08:31 2008 From: developer@opengroupware.org (Helge Hess) Date: Tue, 13 May 2008 12:08:31 +0200 Subject: [OGo-Developer] FYI: time constrained company_value attributes In-Reply-To: <1210673048.5574.9.camel@aleph> References: <78BA8776-8D7D-43D6-8B03-43DC4E37DDC2@opengroupware.org> <1210673048.5574.9.camel@aleph> Message-ID: On 13.05.2008, at 12:04, Adam Tauno Williams wrote: >> JFYI: in my 5.4 DB changes I have extended company_value with a >> timerange, that is, a startdate/enddate. Now you can basically have >> multiple, time constrained values. (eg key="membership", >> value="live", >> from=2001-03-10, to=null) > Are schema changes going to be committed soon? Having the companyId > added to the notes table would be useful for us at this point. I'm reluctant to commit it because I would like to avoid continous database upgrades with trunk users. Also I might still change details. Well, maybe thats a non-issue and I should just commit incremental changes. I'll think about it. >> Not sure how the current UI deals with all that, we'll see :-) > I'm guessing - badly! :) Could be that the keys are merged in a single hashmap in the Document- Layer. Need to check. Greets, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Tue May 13 12:57:59 2008 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Tue, 13 May 2008 13:57:59 +0200 Subject: [OGo-Developer] referredPerson in tasks Message-ID: <20080513115759.92EE74E936@smtp.l00-bugdead-prods.de> Hi, while working on getting the extended Task attributes to work, I stumbled across the referredPerson, that can be enabled via a Default, unfortunately in the code I only found a lot of TODO: document ;) For me it seems, this feature is intended to be able to open a task, on behalf of a different person, like a helpdesk would do, and then save it in the obj_properties table in the database. Is this feature supposed to work? I enabled the Default, but in the LSWJobEditor.m method, where it decided whether to show the Collapsible or not, it evaluates self->referredPerson, and if it is empty, then the collapsible is not shown. As it is always empty when I want to create task, and later on editing, I wonder, how was/is it intended to set the referredPerson? Or was this just not implemented, if so, I'd go add this, as I think it might be useful. I'd add sth. comparable as it is done for the executant selection, so, any objections on that? kind regards Sebastian From developer@opengroupware.org Tue May 13 13:30:20 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Tue, 13 May 2008 08:30:20 -0400 Subject: [OGo-Developer] referredPerson in tasks In-Reply-To: <20080513115759.92EE74E936@smtp.l00-bugdead-prods.de> References: <20080513115759.92EE74E936@smtp.l00-bugdead-prods.de> Message-ID: <1210681820.4734.5.camel@aleph> > while working on getting the extended Task attributes to work, I stumbled > across the referredPerson, that can be enabled via a Default, unfortunately > in the code I only found a lot of TODO: document ;) > For me it seems, this feature is intended to be able to open a task, on > behalf of a different person, like a helpdesk would do, and then save it in > the obj_properties table in the database. Is this feature supposed to work? No; I'm pretty sure this feature is incomplete. It does save the attribute (I believe) but later it shows up very oddly - I tested this feature one but can't find my notes now. > I enabled the Default, but in the LSWJobEditor.m method, where it decided > whether to show the Collapsible or not, it evaluates self->referredPerson, > and if it is empty, then the collapsible is not shown. > As it is always empty when I want to create task, and later on editing, I > wonder, how was/is it intended to set the referredPerson? If I recall correctly you could do something when the task was created. It was so worthless I removed the documentation from WMOGAG and now I can't find the snippet. :( > Or was this just > not implemented, if so, I'd go add this, as I think it might be useful. > I'd add sth. comparable as it is done for the executant selection, so, any > objections on that? I'd *really* like this feature as we have people (help-desk-esque) open tasks on behalf of others and we have to sneak around and change the executant. But my preference would be to allow a certain cast of users to create an executant with a creator other than themselves. Unfortunately OGo doesn't have a role mechanism so you'd have to create a new "internal" team akin to "news editors" or "team creators". From developer@opengroupware.org Tue May 13 13:34:36 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Tue, 13 May 2008 08:34:36 -0400 Subject: [OGo-Developer] referredPerson in tasks In-Reply-To: <1210681820.4734.5.camel@aleph> References: <20080513115759.92EE74E936@smtp.l00-bugdead-prods.de> <1210681820.4734.5.camel@aleph> Message-ID: <1210682076.4734.9.camel@aleph> > > I enabled the Default, but in the LSWJobEditor.m method, where it decided > > whether to show the Collapsible or not, it evaluates self->referredPerson, > > and if it is empty, then the collapsible is not shown. > > As it is always empty when I want to create task, and later on editing, I > > wonder, how was/is it intended to set the referredPerson? > If I recall correctly you could do something when the task was created. > It was so worthless I removed the documentation from WMOGAG and now I > can't find the snippet. :( Maybe that was a long winded way of saying that my vote is to have all references to the referredPerson feature removed; then if we want a feature that does what is described below we build it from there. > > Or was this just > > not implemented, if so, I'd go add this, as I think it might be useful. > > I'd add sth. comparable as it is done for the executant selection, so, any > > objections on that? > I'd *really* like this feature as we have people (help-desk-esque) open > tasks on behalf of others and we have to sneak around and change the > executant. But my preference would be to allow a certain cast of users > to create an executant with a creator other than themselves. > Unfortunately OGo doesn't have a role mechanism so you'd have to create > a new "internal" team akin to "news editors" or "team creators". From developer@opengroupware.org Tue May 13 13:40:11 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Tue, 13 May 2008 08:40:11 -0400 Subject: [OGo-Developer] FYI: time constrained company_value attributes In-Reply-To: References: <78BA8776-8D7D-43D6-8B03-43DC4E37DDC2@opengroupware.org> <1210673048.5574.9.camel@aleph> Message-ID: <1210682411.4734.15.camel@aleph> > >> JFYI: in my 5.4 DB changes I have extended company_value with a > >> timerange, that is, a startdate/enddate. Now you can basically have > >> multiple, time constrained values. (eg key="membership", > >> value="live", > >> from=2001-03-10, to=null) > > Are schema changes going to be committed soon? Having the companyId > > added to the notes table would be useful for us at this point. > I'm reluctant to commit it because I would like to avoid continous > database upgrades with trunk users. Also I might still change details. Understood, but it is "trunk" after all. :) > Well, maybe thats a non-issue and I should just commit incremental > changes. I'll think about it. We could compromise and just commit the parts you are reasonably confident won't change. > >> Not sure how the current UI deals with all that, we'll see :-) > > I'm guessing - badly! :) > Could be that the keys are merged in a single hashmap in the Document- > Layer. Need to check. Unless there is some magic in the gdl layer I'm unaware of, looking at Logic's LSFetchExtendedAttributesCommand command I'd wager a beer it won't be happy seeing multiple records for the same companyId +attribute. :) Or maybe I haven't had enough caffeine yet. From developer@opengroupware.org Tue May 13 13:46:06 2008 From: developer@opengroupware.org (Helge Hess) Date: Tue, 13 May 2008 14:46:06 +0200 Subject: [OGo-Developer] referredPerson in tasks In-Reply-To: <1210681820.4734.5.camel@aleph> References: <20080513115759.92EE74E936@smtp.l00-bugdead-prods.de> <1210681820.4734.5.camel@aleph> Message-ID: Hi, not sure whether its what you are looking at, but there is some 'preferred job executant' facility which is turned off per default. It somehow connects a 'preferred' account to a contact, the contact viewer is extended with a 'new task' button. I don't remember the exact behaviour, but I have written it down somewhere. I think the functionality wasn't too bad, though the implementation is a bit weird. Besides that I was playing with an InReply link, maybe thats what you want: ---snip--- SELECT * FROM Job BASE WHERE BASE.job_id IN (SELECT source_id FROM obj_link WHERE target_id = 10160 AND link_type = 'InReply'); ---snap--- We could always set this if some object was created 'in reply' to another object. Eg if you create a task for a contact or something. Greets, Helge From developer@opengroupware.org Tue May 13 13:59:10 2008 From: developer@opengroupware.org (Helge Hess) Date: Tue, 13 May 2008 14:59:10 +0200 Subject: [OGo-Developer] referredPerson in tasks In-Reply-To: <1210682076.4734.9.camel@aleph> References: <20080513115759.92EE74E936@smtp.l00-bugdead-prods.de> <1210681820.4734.5.camel@aleph> <1210682076.4734.9.camel@aleph> Message-ID: <17E565B6-7A7F-48FA-AC4F-FD19E1522D8C@opengroupware.org> On 13.05.2008, at 14:34, Adam Tauno Williams wrote: > Maybe that was a long winded way of saying that my vote is to have all > references to the referredPerson feature removed; then if we want a > feature that does what is described below we build it from there. I would wait with that, I'm not 100% sure that it should be removed. I don't have the time to look it up right now, but I think its functional. Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Tue May 13 14:26:04 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Tue, 13 May 2008 09:26:04 -0400 Subject: [OGo-Developer] referredPerson in tasks In-Reply-To: References: <20080513115759.92EE74E936@smtp.l00-bugdead-prods.de> <1210681820.4734.5.camel@aleph> Message-ID: <1210685164.4734.50.camel@aleph> > not sure whether its what you are looking at, but there is some > 'preferred job executant' facility which is turned off per default. It > somehow connects a 'preferred' account to a contact, the contact > viewer is extended with a 'new task' button. Nope, that isn't the feature referred to here. "Preferred Job Executant" is document in WMOGAG and we use it in production. This is "referredPerson". Mon Oct 27 17:01:12 2003 Jan Reichmann * v5.0.24 * LSWJobViewer.m: fetch job history * LSWJob: referred person and preferred account support Referred person: The person viewer got a new link [new job]. If this link is used, you will get a job editor for a new job with the person as 'referred person'. Preferred account [enable with JobPreferredExecutantsEnabled=YES]: If a new job is created and a team is choosen as executant, you can select preferred accounts for this job. This accounts will see a new tab in their job-overview who display this jobs. So it somehow relates to the Preferred Executant functionality. I guess the above explains it, but when I tried it, it looked pretty weird (visually, in the UI). > I don't remember the exact behaviour, but I have written it down > somewhere. I think the functionality wasn't too bad, though the > implementation is a bit weird. > Besides that I was playing with an InReply link, maybe thats what you > want: > ---snip--- > SELECT * FROM Job BASE > WHERE BASE.job_id IN > (SELECT source_id FROM obj_link > WHERE target_id = 10160 AND link_type = 'InReply'); > ---snap--- > We could always set this if some object was created 'in reply' to > another object. Eg if you create a task for a contact or something. I do like that. But as far as tasks go I really need those tasks to appear in the users "delegated" list (which is "where creatorId == me"; LSFetchDelegatedJobsCommand). We have numerous widgets that show a user their task list both their to-do list and jobs they have delegated. Help desk creates tasks for a user and delegates them to some team or user, I suppose I could create a Logic command that retrieves myDelegated +myReplyTasks.... SELECT * FROM Job BASE WHERE ((BASE.job_id IN (SELECT source_id FROM obj_link WHERE target_id = 10100 AND link_type = 'InReply')) OR (creator_id = 10100)) AND job_status <> '30_archived' That isn't so bad. Or I maybe it is better to use the object link manager somewhat like the WebUI does for preferred executant tasks - links = [lm allLinksTo:(EOKeyGlobalID *)[account globalID] type:@"Preferred Job Executant"]; [self _fetchJobs:@selector(_setToDoList)]; links = [links map:@selector(sourceGID)]; res = [NSMutableArray array]; Then I can build the functionality into zOGI and not touch Logic. I suppose for my own needs that is a better and less invasive answer. Downside is I'll have to put the two lists together (delegated + InReply). From developer@opengroupware.org Tue May 13 14:28:45 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Tue, 13 May 2008 09:28:45 -0400 Subject: [OGo-Developer] referredPerson in tasks In-Reply-To: <17E565B6-7A7F-48FA-AC4F-FD19E1522D8C@opengroupware.org> References: <20080513115759.92EE74E936@smtp.l00-bugdead-prods.de> <1210681820.4734.5.camel@aleph> <1210682076.4734.9.camel@aleph> <17E565B6-7A7F-48FA-AC4F-FD19E1522D8C@opengroupware.org> Message-ID: <1210685325.4734.52.camel@aleph> On Tue, 2008-05-13 at 14:59 +0200, Helge Hess wrote: > On 13.05.2008, at 14:34, Adam Tauno Williams wrote: > > Maybe that was a long winded way of saying that my vote is to have all > > references to the referredPerson feature removed; then if we want a > > feature that does what is described below we build it from there > I would wait with that, I'm not 100% sure that it should be removed. I > don't have the time to look it up right now, but I think its functional. Ok. From developer@opengroupware.org Tue May 13 14:47:40 2008 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Tue, 13 May 2008 15:47:40 +0200 Subject: [OGo-Developer] referredPerson in tasks Message-ID: <20080513134741.7C6004E98B@smtp.l00-bugdead-prods.de> Hi, developer@opengroupware.org wrote: > > not sure whether its what you are looking at, but there is some > > 'preferred job executant' facility which is turned off per default. It > > somehow connects a 'preferred' account to a contact, the contact > > viewer is extended with a 'new task' button. > > Nope, that isn't the feature referred to here. "Preferred Job > Executant" is document in WMOGAG and we use it in production. > > This is "referredPerson". Yep, it can be enabled via the Default JobReferredPersonEnabled, used in LSWJobEditor.m, and is independent to the preferred job executant stuff. I have the preferred job executant stuff enabled, and it seems to work well. helge, when you say its ok, i'd go, do the following: 1. create a patch to remove the referredPerson stuff from the source 2. update the extended task attributes patch 3. create a new patch, that would reapply the referredPerson stuff again to the changed source 4. open an enhancement request for the referredPerson stuff, adding at least the third patch there how about that? however, take your time to take a look into the source before deciding ;) kind regards Sebastian From developer@opengroupware.org Tue May 13 14:44:34 2008 From: developer@opengroupware.org (Helge Hess) Date: Tue, 13 May 2008 15:44:34 +0200 Subject: [OGo-Developer] referredPerson in tasks In-Reply-To: <1210685164.4734.50.camel@aleph> References: <20080513115759.92EE74E936@smtp.l00-bugdead-prods.de> <1210681820.4734.5.camel@aleph> <1210685164.4734.50.camel@aleph> Message-ID: <67A6BC43-8846-4430-85E7-3CEFA41FC8FC@opengroupware.org> On 13.05.2008, at 15:26, Adam Tauno Williams wrote: > Referred person: The person viewer got a new link [new job]. If > this link is used, you will get a job editor for a new job > with the person as 'referred person'. I think thats basically my 'InReply' thing. And if the UI already supports it, all the better :-) If it works, I'll use it instead of 'InReply'. Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Tue May 13 15:17:22 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Tue, 13 May 2008 10:17:22 -0400 Subject: [OGo-Developer] referredPerson in tasks In-Reply-To: <67A6BC43-8846-4430-85E7-3CEFA41FC8FC@opengroupware.org> References: <20080513115759.92EE74E936@smtp.l00-bugdead-prods.de> <1210681820.4734.5.camel@aleph> <1210685164.4734.50.camel@aleph> <67A6BC43-8846-4430-85E7-3CEFA41FC8FC@opengroupware.org> Message-ID: <1210688242.4734.65.camel@aleph> On Tue, 2008-05-13 at 15:44 +0200, Helge Hess wrote: > On 13.05.2008, at 15:26, Adam Tauno Williams wrote: > > Referred person: The person viewer got a new link [new job]. If > > this link is used, you will get a job editor for a new job > > with the person as 'referred person'. > > > I think thats basically my 'InReply' thing. And if the UI already > supports it, all the better :-) If it works, I'll use it instead of > 'InReply'. No, the referred person feature in the WebUI uses the property manager not the link manager. That is why we thought it was wierd - it isn't a link. - (void)_processInsertProperties { id pm; NSDictionary *dic; if (![self hasJobAttributes]) return; if (self->referredPerson == nil) return; pm = [[[self session] commandContext] propertyManager]; dic = [NSDictionary dictionaryWithObjectsAndKeys: [self referredPersonAction], @"{person}referredPerson", nil]; [pm takeProperties:dic namespace:nil globalID:[[self object] globalID]]; } From developer@opengroupware.org Tue May 13 14:57:30 2008 From: developer@opengroupware.org (Helge Hess) Date: Tue, 13 May 2008 15:57:30 +0200 Subject: [OGo-Developer] FYI: time constrained company_value attributes In-Reply-To: <1210682411.4734.15.camel@aleph> References: <78BA8776-8D7D-43D6-8B03-43DC4E37DDC2@opengroupware.org> <1210673048.5574.9.camel@aleph> <1210682411.4734.15.camel@aleph> Message-ID: On 13.05.2008, at 14:40, Adam Tauno Williams wrote: > Unless there is some magic in the gdl layer I'm unaware of, looking at > Logic's LSFetchExtendedAttributesCommand command I'd wager a beer it > won't be happy seeing multiple records for the same companyId > +attribute. :) Or maybe I haven't had enough caffeine yet. Hm, that doesn't look too bad. It keeps a Map, but also seems to preserve the array: ---snip--- [obj takeValue:map forKey:@"attributeMap"]; [obj takeValue:newAttrs forKey:@"companyValue"]; ---snap--- So there is hope ;-) Greets, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Tue May 13 15:20:02 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Tue, 13 May 2008 10:20:02 -0400 Subject: [OGo-Developer] referredPerson in tasks In-Reply-To: <20080513134741.7C6004E98B@smtp.l00-bugdead-prods.de> References: <20080513134741.7C6004E98B@smtp.l00-bugdead-prods.de> Message-ID: <1210688402.4734.67.camel@aleph> > helge, when you say its ok, i'd go, do the following: > 1. create a patch to remove the referredPerson stuff from the source > 2. update the extended task attributes patch > 3. create a new patch, that would reapply the referredPerson stuff again to > the changed source > 4. open an enhancement request for the referredPerson stuff, adding at least > the third patch there > how about that? > however, take your time to take a look into the source before deciding ;) Can we just leave the referredPerson code alone when adding the task-extended-attributes patch? Attributes are currently saving (according to the bug). I haven't gotten it working yet. :( The attributes appear in the configure pane but no where in the job editor or viewer. But I'm still checking that I didn't dork something. From developer@opengroupware.org Tue May 13 15:28:48 2008 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Tue, 13 May 2008 16:28:48 +0200 Subject: [OGo-Developer] referredPerson in tasks Message-ID: <20080513142848.B50294E9C1@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > On 13.05.2008, at 15:26, Adam Tauno Williams wrote: > > Referred person: The person viewer got a new link [new job]. If > > this link is used, you will get a job editor for a new job > > with the person as 'referred person'. > Ah, it shows up in the person viewer, there I did not took a look, I expected sth. to show up in the Job editor. Obviously, need to take another look into it. Sebastian From developer@opengroupware.org Tue May 13 15:21:48 2008 From: developer@opengroupware.org (Helge Hess) Date: Tue, 13 May 2008 16:21:48 +0200 Subject: [OGo-Developer] referredPerson in tasks In-Reply-To: <1210688242.4734.65.camel@aleph> References: <20080513115759.92EE74E936@smtp.l00-bugdead-prods.de> <1210681820.4734.5.camel@aleph> <1210685164.4734.50.camel@aleph> <67A6BC43-8846-4430-85E7-3CEFA41FC8FC@opengroupware.org> <1210688242.4734.65.camel@aleph> Message-ID: <897378E7-AE72-46FF-9CBE-FFD89F777970@opengroupware.org> On 13.05.2008, at 16:17, Adam Tauno Williams wrote: > No, the referred person feature in the WebUI uses the property > manager not the link manager. That is why we thought it was wierd - > it isn't a link. Ah, ok. Actually I always wondered why we have links *and* extprops. Should be the same? :-) OK, adds a bit of semantics. Anyways, sure, I think it should be a link. Might make sense to drop the extended attribute. Thanks, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Tue May 13 15:58:31 2008 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Tue, 13 May 2008 16:58:31 +0200 Subject: [OGo-Developer] referredPerson in tasks Message-ID: <20080513145831.EDE104E9E8@smtp.l00-bugdead-prods.de> developer@opengroupware.org wrote: > > helge, when you say its ok, i'd go, do the following: > > 1. create a patch to remove the referredPerson stuff from the source > > 2. update the extended task attributes patch > > 3. create a new patch, that would reapply the referredPerson stuff again to > > the changed source > > 4. open an enhancement request for the referredPerson stuff, adding at least > > the third patch there > > how about that? > > however, take your time to take a look into the source before deciding ;) > > Can we just leave the referredPerson code alone when adding the > task-extended-attributes patch? Attributes are currently saving yep. > (according to the bug). I haven't gotten it working yet. :( The > attributes appear in the configure pane but no where in the job editor > or viewer. But I'm still checking that I didn't dork something. > > I'm just going to create another, more cleaned up patch. Sebastian From developer@opengroupware.org Wed May 14 01:08:29 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Tue, 13 May 2008 20:08:29 -0400 Subject: [OGo-Developer] Multi-Valued Company Values [Was: FYI: time constrained company_value attributes] In-Reply-To: References: <78BA8776-8D7D-43D6-8B03-43DC4E37DDC2@opengroupware.org> <1210673048.5574.9.camel@aleph> <1210682411.4734.15.camel@aleph> Message-ID: <1210723709.9890.4.camel@aleph> > > Unless there is some magic in the gdl layer I'm unaware of, looking at > > Logic's LSFetchExtendedAttributesCommand command I'd wager a beer it > > won't be happy seeing multiple records for the same companyId > > +attribute. :) Or maybe I haven't had enough caffeine yet. > Hm, that doesn't look too bad. It keeps a Map, but also seems to > preserve the array: > ---snip--- > [obj takeValue:map forKey:@"attributeMap"]; > [obj takeValue:newAttrs forKey:@"companyValue"]; > ---snap--- > So there is hope ;-) SELECT company_value_id, value_string FROM company_value WHERE company_id = 10100 AND attribute = 'salesperson' company_value_id value_string 11220290 MNO 11220280 XYZ 3962570 ABC It just returns one value, appears to be the last value processed. ogo-qsearch-persons -login adam -password fred123 'companyId = 10100' ... email2 : awilliam@whitemice.org salesperson : MNO headboy : no ... From developer@opengroupware.org Wed May 14 01:17:33 2008 From: developer@opengroupware.org (Helge Hess) Date: Wed, 14 May 2008 02:17:33 +0200 Subject: [OGo-Developer] Multi-Valued Company Values [Was: FYI: time constrained company_value attributes] In-Reply-To: <1210723709.9890.4.camel@aleph> References: <78BA8776-8D7D-43D6-8B03-43DC4E37DDC2@opengroupware.org> <1210673048.5574.9.camel@aleph> <1210682411.4734.15.camel@aleph> <1210723709.9890.4.camel@aleph> Message-ID: <1CF4AD88-2C0D-452B-AC18-02ADF8995166@opengroupware.org> On 14.05.2008, at 02:08, Adam Tauno Williams wrote: > It just returns one value, appears to be the last value processed. Yes, most existing "UI" code probably will use the Map. The most important question is whether updates affect the other values (eg delete them). Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Wed May 14 03:30:41 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Tue, 13 May 2008 22:30:41 -0400 Subject: [OGo-Developer] Multi-Valued Company Values [Was: FYI: time constrained company_value attributes] In-Reply-To: <1CF4AD88-2C0D-452B-AC18-02ADF8995166@opengroupware.org> References: <78BA8776-8D7D-43D6-8B03-43DC4E37DDC2@opengroupware.org> <1210673048.5574.9.camel@aleph> <1210682411.4734.15.camel@aleph> <1210723709.9890.4.camel@aleph> <1CF4AD88-2C0D-452B-AC18-02ADF8995166@opengroupware.org> Message-ID: <1210732241.9890.6.camel@aleph> On Wed, 2008-05-14 at 02:17 +0200, Helge Hess wrote: > On 14.05.2008, at 02:08, Adam Tauno Williams wrote: > > It just returns one value, appears to be the last value processed. > > > Yes, most existing "UI" code probably will use the Map. The most > important question is whether updates affect the other values (eg > delete them). It overwrites all of them SELECT company_value_id, value_string FROM company_value WHERE company_id = 10100 AND attribute = 'salesperson' 11220290 10,101 11220280 10,101 3962570 10,101 After updating from the WebUI. From developer@opengroupware.org Mon May 19 14:35:48 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Mon, 19 May 2008 09:35:48 -0400 Subject: [OGo-Developer] referredPerson in tasks In-Reply-To: <897378E7-AE72-46FF-9CBE-FFD89F777970@opengroupware.org> References: <20080513115759.92EE74E936@smtp.l00-bugdead-prods.de> <1210681820.4734.5.camel@aleph> <1210685164.4734.50.camel@aleph> <67A6BC43-8846-4430-85E7-3CEFA41FC8FC@opengroupware.org> <1210688242.4734.65.camel@aleph> <897378E7-AE72-46FF-9CBE-FFD89F777970@opengroupware.org> Message-ID: <1211204148.11593.0.camel@EVTLIS03.morrison.iserv.net> On Tue, 2008-05-13 at 16:21 +0200, Helge Hess wrote: > On 13.05.2008, at 16:17, Adam Tauno Williams wrote: > > No, the referred person feature in the WebUI uses the property > > manager not the link manager. That is why we thought it was wierd - > > it isn't a link > Ah, ok. Actually I always wondered why we have links *and* extprops. > Should be the same? :-) OK, adds a bit of semantics. > Anyways, sure, I think it should be a link. Might make sense to drop > the extended attribute. From developer@opengroupware.org Mon May 26 14:58:58 2008 From: developer@opengroupware.org (Wolfgang Sourdeau) Date: Mon, 26 May 2008 09:58:58 -0400 Subject: [OGo-Developer] svn server down (again...) Message-ID: <483AC222.1020101@inverse.ca> Hi, This morning, I get this: wsourdeau@Evariste:~/src/SOGo$ svn update svn: Échec de la requête PROPFIND sur '/SOGo/inverse/trunk' svn: Could not open the requested SVN filesystem wsourdeau@Evariste:~/src/SOGo$ And the http://svn.opengroupware.org/viewcvs/?root=SOGo gives a python exception related to a Berkeley DB problem... Can someone fix this? Thanks! Wolfgang From developer@opengroupware.org Tue May 27 13:00:53 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Tue, 27 May 2008 08:00:53 -0400 Subject: [OGo-Developer] svn server down (again...) In-Reply-To: <483AC222.1020101@inverse.ca> References: <483AC222.1020101@inverse.ca> Message-ID: <1211889653.5053.4.camel@aleph> > This morning, I get this: > wsourdeau@Evariste:~/src/SOGo$ svn update > svn: =C3=89chec de la requ=C3=AAte PROPFIND sur '/SOGo/inverse/trunk' > svn: Could not open the requested SVN filesystem > wsourdeau@Evariste:~/src/SOGo$ > And the http://svn.opengroupware.org/viewcvs/?root=3DSOGo gives a pytho= n=20 > exception related to a Berkeley DB problem... > Can someone fix this? Looks that way to me too. awilliam@aleph:~/Works/OpenGroupware/opengroupware.org> svn up svn: PROPFIND request failed on '/OpenGroupware.org/trunk' svn: Could not open the requested SVN filesystem From developer@opengroupware.org Wed May 28 19:53:58 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Wed, 28 May 2008 14:53:58 -0400 Subject: [OGo-Developer] svn server down (again...) In-Reply-To: <1211889653.5053.4.camel@aleph> References: <483AC222.1020101@inverse.ca> <1211889653.5053.4.camel@aleph> Message-ID: <1212000838.4990.0.camel@EVTLIS03.morrison.iserv.net> On Tue, 2008-05-27 at 08:00 -0400, Adam Tauno Williams wrote: > > This morning, I get this: > > wsourdeau@Evariste:~/src/SOGo$ svn update > > svn: =C3=89chec de la requ=C3=AAte PROPFIND sur '/SOGo/inverse/trunk' > > svn: Could not open the requested SVN filesystem > > wsourdeau@Evariste:~/src/SOGo$ > > And the http://svn.opengroupware.org/viewcvs/?root=3DSOGo gives a pyt= hon=20 > > exception related to a Berkeley DB problem... > > Can someone fix this? > Looks that way to me too. > awilliam@aleph:~/Works/OpenGroupware/opengroupware.org> svn up > svn: PROPFIND request failed on '/OpenGroupware.org/trunk' > svn: Could not open the requested SVN filesystem Anyone know anything about the status of the SVN server? From developer@opengroupware.org Wed May 28 20:26:44 2008 From: developer@opengroupware.org (Helge Hess) Date: Wed, 28 May 2008 21:26:44 +0200 Subject: [OGo-Developer] svn server down In-Reply-To: <1212000838.4990.0.camel@EVTLIS03.morrison.iserv.net> References: <483AC222.1020101@inverse.ca> <1211889653.5053.4.camel@aleph> <1212000838.4990.0.camel@EVTLIS03.morrison.iserv.net> Message-ID: <59A4B79A-9BA5-4BC6-A4F3-3CAA6ABB66D8@opengroupware.org> On 28.05.2008, at 20:53, Adam Tauno Williams wrote: > Anyone know anything about the status of the SVN server? Hm, is down, you are right. I thought you talked about svn.ogo, which is up and running: http://svn.opengroupware.org/OpenGroupware.org/trunk/ Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Fri May 30 19:47:36 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Fri, 30 May 2008 14:47:36 -0400 Subject: [OGo-Developer] svn server down In-Reply-To: <59A4B79A-9BA5-4BC6-A4F3-3CAA6ABB66D8@opengroupware.org> References: <483AC222.1020101@inverse.ca> <1211889653.5053.4.camel@aleph> <1212000838.4990.0.camel@EVTLIS03.morrison.iserv.net> <59A4B79A-9BA5-4BC6-A4F3-3CAA6ABB66D8@opengroupware.org> Message-ID: <1212173256.5225.0.camel@EVTLIS03.morrison.iserv.net> > Hm, is down, you are right. I thought you talked about svn.ogo, which > is up and running: > http://svn.opengroupware.org/OpenGroupware.org/trunk/ Any news? From developer@opengroupware.org Fri May 30 19:59:52 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Fri, 30 May 2008 14:59:52 -0400 Subject: [OGo-Developer] Notes & Deleted projects (Bug#1976) Message-ID: <1212173992.5225.10.camel@EVTLIS03.morrison.iserv.net> Currently OGo is pretty sloppy about deletes and leaves behind a fair amount of detritus. In relation to appointments, notes, and projects. When an appointment is deleted, if there are any notes attached to it they are unlinked. The appointment is gone. When a project is deleted, if there are any notes attached to it they are not unlinked. That would seem like a straight-forward bug, except... If you see an appointment via-a-note in the project editor and you click on the appointment - if the appointment has been deleted you get an error. If you see a project via-a-note in the appointment editor and the project no longer exists the project link icon is x-ed out and not a link. The later seems weird to me. If a project is deleted can we just unlink the notes like we do when an appointment is deleted? This x-project icon that doesn't go anywhere doesn't make much sense to me. If both sides (project & appointment) unlink when they are deleted then if project_id = NULL and date_id = NULL we can delete the note as well (from db & filesystem). Currently it appears that notes always remain in the filesystem. From developer@opengroupware.org Fri May 30 20:09:10 2008 From: developer@opengroupware.org (Adam Tauno Williams) Date: Fri, 30 May 2008 15:09:10 -0400 Subject: [OGo-Developer] Notes & Deleted projects (Bug#1976) In-Reply-To: <1212173992.5225.10.camel@EVTLIS03.morrison.iserv.net> References: <1212173992.5225.10.camel@EVTLIS03.morrison.iserv.net> Message-ID: <1212174550.5225.15.camel@EVTLIS03.morrison.iserv.net> On Fri, 2008-05-30 at 14:59 -0400, Adam Tauno Williams wrote: > > > Currently OGo is pretty sloppy about deletes and leaves behind a fair > amount of detritus. > The later seems weird to me. If a project is deleted can we just unlink > the notes like we do when an appointment is deleted? On top of that, just discovered (and buzzdee confirmed) that attempting to edit an appointment from the appointment side that links to a deleted project (x-project icon displayed) fails with a "cannot fault to-one for primary key" exception. -- Consonance: an Open Source .NET OpenGroupware client. Contact:awilliam@whitemiceconsulting.com http://freshmeat.net/projects/consonance/