From jan at horde.org Mon Mar 26 13:49:34 2007 From: jan at horde.org (Jan Schneider) Date: Mon, 26 Mar 2007 15:49:34 +0200 Subject: [dev] [cvs] commit: agora moderate.php agora/docs TODO agora/lib Messages.php api.php agora/po agora.pot sl_SI.po In-Reply-To: <20070326141155.EF492BFE4@nazik.horde.org> References: <20070326141155.EF492BFE4@nazik.horde.org> Message-ID: <20070326154934.qnw3tyj00osk8g8g@neo.wg.de> Zitat von Duck : > duck 2007-03-26 10:11:55 EDT > > Modified files: > . moderate.php > docs TODO > lib Messages.php api.php > po agora.pot sl_SI.po > Log: > Use nl2br instead of text2html since conflicts with bbcode. Text2html does much more than linebreaks, e.g. linking urls and email addresses. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ From jan at horde.org Mon Mar 26 14:45:15 2007 From: jan at horde.org (Jan Schneider) Date: Mon, 26 Mar 2007 16:45:15 +0200 Subject: [dev] [cvs] commit: agora moderate.php agora/docs TODO agora/lib Messages.php api.php agora/po agora.pot sl_SI.po In-Reply-To: <4607ECCC.7080702@obala.net> References: <20070326141155.EF492BFE4@nazik.horde.org> <20070326154934.qnw3tyj00osk8g8g@neo.wg.de> <4607ECCC.7080702@obala.net> Message-ID: <20070326164515.3t58a0fcu84cw8cs@neo.wg.de> Zitat von duck : > Jan Schneider wrote: >> Text2html does much more than linebreaks, e.g. linking urls and email >> addresses. > > I experience problems using them together. For example if bbcode is > called before text2html, text2html passed html crated with bbode with > htmlscpecialchars. On the other side of bbcode is called after, it does > double linking ex [url]link[/url] becomes href=?link?>link. I personally don't like bbcode at all and don't want to require people to use [url] tags, or any tag for what it's worse. It should at least be an configuration setting, the correct rule could even be automatically detected by looking for bbcode tags upfront. And please note that the bbcode filter doesn't escape any output by default, I didn't look at the code whether you enabled escaping. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ From mdf at darksnow.net Mon Mar 26 17:00:33 2007 From: mdf at darksnow.net (Martin Fraser) Date: Mon, 26 Mar 2007 19:00:33 +0200 Subject: [dev] Generating conf.php Message-ID: Hey. I'm working on a script to automatically update my horde installation from CVS. It essentially does what I do on the command line right now. CV update, run framework installation then regenerate any out of date configs. My problem is with the config stuff. I've had a good look at the code and I can get it generate a new config, but what it currently does is simply read in the existing file with getPHPConfig() then parsing the result with eval. I then use the resultant array to generate a new config with generatePHPConfig(new Variables(), $currentConf) The problem I'm having is with config settings that cannot be evaluated. I'm running this a shell script and in the main horde conf.php there are a couple of entries that access the $_SERVER[] array, which doesn't exist on the command line. So my question is how does the ConfigForm code output defaults from the xml file and how can I parse the existing conf.php file without evaluating those strings so I can regenerate the configuration from the new xml file as needed in my automated upgrade. I hope all that makes sense. Martin... From vilius at lnk.lt Mon Mar 26 17:42:09 2007 From: vilius at lnk.lt (=?utf-8?Q?Vilius_=C5=A0umskas?=) Date: Mon, 26 Mar 2007 20:42:09 +0300 Subject: [dev] [cvs] commit: agora moderate.php agora/docs TODO agora/lib Messages.php api.php agora/po agora.pot sl_SI.po In-Reply-To: <20070326164515.3t58a0fcu84cw8cs@neo.wg.de> References: <20070326141155.EF492BFE4@nazik.horde.org> <20070326154934.qnw3tyj00osk8g8g@neo.wg.de> <4607ECCC.7080702@obala.net> <20070326164515.3t58a0fcu84cw8cs@neo.wg.de> Message-ID: <002e01c76fce$1412a1e0$3c37e5a0$@lt> > I personally don't like bbcode at all and don't want to require people > to use [url] tags, or any tag for what it's worse. It should at least I totally agree there. -- Vilius From lemon at grad.icmc.usp.br Tue Mar 27 06:13:01 2007 From: lemon at grad.icmc.usp.br (=?ISO-8859-15?Q?Lu=EDs_Fernando?=) Date: Tue, 27 Mar 2007 03:13:01 -0300 Subject: [dev] IMP authentication timeout Message-ID: <1567374329.20070327031301@grad.icmc.usp.br> after installing Horde 3.1.4 with IMP 4.1.4 and, everytime I try to log to it, I get stuck on /horde/imp/redirect.php with this error message (code 500) I'm using IMP as the authentication method -------------------------------------------------------------------------------------------------------------- Server Error The following error occurred: [code=SERVER_RESPONSE_CLOSE] The server closed the connection while reading the response. Contact your system administrator. Please contact the administrator. -------------------------------------------------------------------------------------------------------------- After debuging it, I found the problem to be on: /horde/imp/lib/Auth/imp.php (line 121): return parent::authenticate($userID, $credentials, $login); I can't debug more than that, but what I noticed that: 1) changing parent:: to Auth:: didn't change anything 2) putting a `echo a >>/tmp/test` right on the start of the function authenticate, "a" is written just once (even with this second call) any ideas/hints? thanks, Luis Fernando From mdf at darksnow.net Tue Mar 27 13:40:51 2007 From: mdf at darksnow.net (Martin Fraser) Date: Tue, 27 Mar 2007 15:40:51 +0200 Subject: [dev] Generating conf.php In-Reply-To: References: Message-ID: Nevermind! I found that the generated PHP config file contains defaults from xml file if the array containing the configuration has empty values. Initially, and what caused the question below, was that I thought if the config value was in the array, even if it was empty, would be put in the output file. Anyway, problem solved and I now have a way of automatically refreshing out of date config files. Cheers. Martin... Martin Fraser wrote: > Hey. > > I'm working on a script to automatically update my horde installation > from CVS. > It essentially does what I do on the command line right now. > CV update, run framework installation then regenerate any out of date > configs. > > My problem is with the config stuff. > > I've had a good look at the code and I can get it generate a new config, > but what it currently does is simply read in the existing file with > getPHPConfig() then parsing the result with eval. I then use the > resultant array to generate a new config with > generatePHPConfig(new Variables(), $currentConf) > > The problem I'm having is with config settings that cannot be evaluated. > I'm running this a shell script and in the main horde conf.php there are > a couple of entries that access the $_SERVER[] array, which doesn't > exist on the command line. So my question is how does the ConfigForm > code output defaults from the xml file and how can I parse the existing > conf.php file without evaluating those strings so I can regenerate the > configuration from the new xml file as needed in my automated upgrade. > > I hope all that makes sense. > > Martin... > > From duck at obala.net Tue Mar 27 15:45:23 2007 From: duck at obala.net (duck) Date: Tue, 27 Mar 2007 17:45:23 +0200 Subject: [dev] bbcode patch Message-ID: <46093C13.8070502@obala.net> adds strike, subscript, superscript, img and color -------------- next part -------------- A non-text attachment was scrubbed... Name: bbcode.diff Type: text/x-patch Size: 1794 bytes Desc: not available Url : http://lists.horde.org/archives/dev/attachments/20070327/801dd948/attachment.bin From marc at r4l.com Tue Mar 27 14:34:47 2007 From: marc at r4l.com (Marc Jauvin) Date: Tue, 27 Mar 2007 10:34:47 -0400 Subject: [dev] Generating conf.php In-Reply-To: References: Message-ID: <20070327103447.yh85rje680wcokog@mail2.jauvin.com> Can you share your code for this, I'd be interested. Thanks. Martin Fraser wrote: > Nevermind! > > I found that the generated PHP config file contains defaults from xml > file if the array containing the configuration has empty values. > > Initially, and what caused the question below, was that I thought if the > config value was in the array, even if it was empty, would be put in > the output file. > > Anyway, problem solved and I now have a way of automatically refreshing > out of date config files. > > Cheers. > > Martin... > > Martin Fraser wrote: >> Hey. >> >> I'm working on a script to automatically update my horde installation >> from CVS. >> It essentially does what I do on the command line right now. >> CV update, run framework installation then regenerate any out of date >> configs. >> >> My problem is with the config stuff. >> >> I've had a good look at the code and I can get it generate a new config, >> but what it currently does is simply read in the existing file with >> getPHPConfig() then parsing the result with eval. I then use the >> resultant array to generate a new config with >> generatePHPConfig(new Variables(), $currentConf) >> >> The problem I'm having is with config settings that cannot be evaluated. >> I'm running this a shell script and in the main horde conf.php there are >> a couple of entries that access the $_SERVER[] array, which doesn't >> exist on the command line. So my question is how does the ConfigForm >> code output defaults from the xml file and how can I parse the existing >> conf.php file without evaluating those strings so I can regenerate the >> configuration from the new xml file as needed in my automated upgrade. >> >> I hope all that makes sense. >> >> Martin... >> >> > > > -- > Horde developers mailing list - Join the hunt: http://horde.org/bounties/ > Frequently Asked Questions: http://horde.org/faq/ > To unsubscribe, mail: dev-unsubscribe at lists.horde.org > From mdf at darksnow.net Tue Mar 27 17:17:56 2007 From: mdf at darksnow.net (Martin Fraser) Date: Tue, 27 Mar 2007 19:17:56 +0200 Subject: [dev] Automated CVS Upgrade Message-ID: Hey all. I've created a little script that allows me to upgrade my horde installation from CVS. It runs the CVS update command then runs install-framework Finally, it regenerates any out of date config files. Some other people may find this handy so please find it attached. I'm planning to expand this to a more full features automated installation routine, again using a CVS client, to make deployment and updating easy (CVS seemed like the way to go for that). Comments welcome. Martin... -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: horde_upgrade.php Url: http://lists.horde.org/archives/dev/attachments/20070327/4ed57994/attachment.ksh From mdf at darksnow.net Wed Mar 28 15:57:31 2007 From: mdf at darksnow.net (Martin Fraser) Date: Wed, 28 Mar 2007 17:57:31 +0200 Subject: [dev] Is install-packages needed Message-ID: Hey, quick question. I know that install-packages.php installs the pear packages but I was wondering, if you do a cvs update and get any new versions of these packages, is it necessary to run install-packages again to install the newly updated packages or will a pear update-all pull the updated packages either from pear.horde.org of from the local files? It's just that install-packages takes so long to run that if there is a quicker way it could speed updates. Cheers, Martin... From jan at horde.org Wed Mar 28 16:35:31 2007 From: jan at horde.org (Jan Schneider) Date: Wed, 28 Mar 2007 18:35:31 +0200 Subject: [dev] Is install-packages needed In-Reply-To: References: Message-ID: <20070328183531.zm3lhgt344okggs0@neo.wg.de> Zitat von Martin Fraser : > Hey, quick question. > > I know that install-packages.php installs the pear packages but I was > wondering, if you do a cvs update and get any new versions of these > packages, is it necessary to run install-packages again to install the > newly updated packages or will a pear update-all pull the updated > packages either from pear.horde.org of from the local files? No, you have to run it again. > It's just that install-packages takes so long to run that if there is a > quicker way it could speed updates. There's horde-fw-symlinks, but that's only for developers and not officially supported. You have to stick with install-packages.php. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ From mdf at darksnow.net Wed Mar 28 16:54:42 2007 From: mdf at darksnow.net (Martin Fraser) Date: Wed, 28 Mar 2007 18:54:42 +0200 Subject: [dev] Is install-packages needed In-Reply-To: <20070328183531.zm3lhgt344okggs0@neo.wg.de> References: <20070328183531.zm3lhgt344okggs0@neo.wg.de> Message-ID: That's what I thought, thanks for the quick reply. Martin... Jan Schneider wrote: > Zitat von Martin Fraser : > >> Hey, quick question. >> >> I know that install-packages.php installs the pear packages but I was >> wondering, if you do a cvs update and get any new versions of these >> packages, is it necessary to run install-packages again to install the >> newly updated packages or will a pear update-all pull the updated >> packages either from pear.horde.org of from the local files? > > No, you have to run it again. > >> It's just that install-packages takes so long to run that if there is a >> quicker way it could speed updates. > > There's horde-fw-symlinks, but that's only for developers and not > officially supported. You have to stick with install-packages.php. > > Jan. > From duck at obala.net Thu Mar 29 17:19:46 2007 From: duck at obala.net (duck) Date: Thu, 29 Mar 2007 19:19:46 +0200 Subject: [dev] oasis OpenDocument viewer Message-ID: <460BF532.4090104@obala.net> Uses PEAR::OpenDocumenet package. It requies PHP4 and ZIP peal extension. Duck -------------- next part -------------- A non-text attachment was scrubbed... Name: oasis.php Type: application/x-php Size: 2674 bytes Desc: not available Url : http://lists.horde.org/archives/dev/attachments/20070329/66d7c3f3/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: oasis-mime.php Type: application/x-php Size: 2422 bytes Desc: not available Url : http://lists.horde.org/archives/dev/attachments/20070329/66d7c3f3/attachment-0001.bin From jan at horde.org Thu Mar 29 15:52:11 2007 From: jan at horde.org (Jan Schneider) Date: Thu, 29 Mar 2007 17:52:11 +0200 Subject: [dev] oasis OpenDocument viewer In-Reply-To: <460BF532.4090104@obala.net> References: <460BF532.4090104@obala.net> Message-ID: <20070329175211.5yfeqb0e1w0og4cg@neo.wg.de> Zitat von duck : > Uses PEAR::OpenDocumenet package. > It requies PHP4 and ZIP peal extension. Does it gain anything compared to the ooo driver? And please use bugs.horde.org like everybody else. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ From jan at horde.org Thu Mar 29 16:18:32 2007 From: jan at horde.org (Jan Schneider) Date: Thu, 29 Mar 2007 18:18:32 +0200 Subject: [dev] Shares and multiple storage backends In-Reply-To: <87ejnh5tgo.fsf@monastery.lucy.homelinux.net> References: <87k5xagwxt.fsf@monastery.lucy.homelinux.net> <20070322132217.jq0n8e2x4wwwgsgw@neo.wg.de> <87ejnh5tgo.fsf@monastery.lucy.homelinux.net> Message-ID: <20070329181832.0uxdxvfn0gc00w4o@neo.wg.de> Zitat von Gunnar Wrobel : > Jan Schneider writes: > >> Zitat von Gunnar Wrobel : >> >>> So my resulting question would be if the handling of shares should not >>> rather be linked to specific storage drivers instead of having one >>> global share configuration that allows you to choose only one driver >>> for all storage backends at the same time? >> >> This is not possible due to visibility issues. All applications and >> their storage backend can access the global share system in Horde. But >> the share system doesn't know anything about installed applications, >> available storage drivers etc. As you already noticed it's a very >> abstract view on available shares. They are only defined inside the >> share system, no matter if they have any counterpart in an >> application. Thus we can't link shares to to specific storage drivers. >> >> Unfortunately I don't have an idea how else to solve this dilemma, I >> guess we need to put the responsibility of activating shares into the >> hands of administrators, and document that properly. E.g. document in >> ingo/config/backends.php that 'shares' can only be enabled if using >> the sql storage driver or a preference driver that allows access >> without user credentials. >> >> But I don't understand what exactly your problem with the Kolab shares >> is, because due to the nature of this driver, the shares *are* already >> tightly coupled to the storage backends, because they are annotations >> of the imap folders containing the data. Or am I missing anything? > > I might have been confused by the fact that applications like Turba > and Ingo use a syntax like "kolab:MyDefaultShare" or > "sql:MyDefaultShare" in order to identify shares. I assumed that it > would be possible to use shares with different storage back ends at > the same time. > > But indeed neither Turba nor Ingo seem to allow this. Is this a fixed > rule for all Horde apps? Yes, Turba for example used the source name as a prefix to easier map a share back to the storage backend, because it's always coupled with that one. So no, you can have the same share using different backends or even switching the backend. > In that case the Kolab share driver could simply ignore the "kolab:" > prefix and assume that it always operates on a Kolab IMAP > back end. This is how I wanted to implement it initially but then I got > doubts :) > > My line of thought was going into the direction of specifying the > required share driver within the storage back end parameters. Right now > there are boolean values used for both Ingo and Turba in order to > indicate if a given back end should use shares or not ("use_shares" in > the case of Turba, "shares" in case of Ingo). > > I thought it might have been possible to enter the necessary share > driver here instead of a boolean value. So that the correct driver > would be chosen for each storage back end and you would not have the > global option currently available in the Horde configuration. No, the share driver is always defined globally and never changed. > But I assume this would also cause severe problems with backward > compatibility. > > If each app can only use shares on one back end the Kolab share driver > has no problems anyhow. Good. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ From jan at horde.org Thu Mar 29 19:04:46 2007 From: jan at horde.org (Jan Schneider) Date: Thu, 29 Mar 2007 21:04:46 +0200 Subject: [dev] [cvs] commit: imp/lib/Quota sql.php In-Reply-To: <20070329192247.2B645BFE4@nazik.horde.org> References: <20070329192247.2B645BFE4@nazik.horde.org> Message-ID: <20070329210446.49np2zfqg4owckcc@neo.wg.de> Zitat von Matt Selsky : > selsky 2007-03-29 15:22:47 EDT > > Modified files: > lib/Quota sql.php > Log: > Update phpdoc to reference 'imap' quota driver. > > Revision Changes Path > 1.4 +2 -2 imp/lib/Quota/sql.php > > Chora Links: > http://cvs.horde.org/diff.php/imp/lib/Quota/sql.php?r1=1.3&r2=1.4&ty=u This should neither be cyrus or imap, but sql, right? Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ From selsky at columbia.edu Thu Mar 29 19:48:50 2007 From: selsky at columbia.edu (Matt Selsky) Date: Thu, 29 Mar 2007 15:48:50 -0400 Subject: [dev] [cvs] commit: imp/lib/Quota sql.php In-Reply-To: <20070329210446.49np2zfqg4owckcc@neo.wg.de> References: <20070329192247.2B645BFE4@nazik.horde.org> <20070329210446.49np2zfqg4owckcc@neo.wg.de> Message-ID: On Mar 29, 2007, at 3:04 PM, Jan Schneider wrote: > Zitat von Matt Selsky : > >> selsky 2007-03-29 15:22:47 EDT >> >> Modified files: >> lib/Quota sql.php >> Log: >> Update phpdoc to reference 'imap' quota driver. >> >> Revision Changes Path >> 1.4 +2 -2 imp/lib/Quota/sql.php >> >> Chora Links: >> http://cvs.horde.org/diff.php/imp/lib/Quota/sql.php? >> r1=1.3&r2=1.4&ty=u > > This should neither be cyrus or imap, but sql, right? Yes. -- Matt From mdf at darksnow.net Sat Mar 31 08:45:01 2007 From: mdf at darksnow.net (Martin Fraser) Date: Sat, 31 Mar 2007 10:45:01 +0200 Subject: [dev] OpenId Message-ID: Hey all. Has anyone thought about adding OpenId into the Horde system, either as a client for single sign on logins or the server itself, or both? I know OpenId is quite young but the Jan Rain libs seems quite stable and good, even if the example server is bobbins. Anyway, if there is no objection I was writing a server for this anyway and could use Horde for the database backend, prefs and the likes. My problem was that I wanted to use an LDAP auth backend, but why not use Horde_Auth instead and authenticate against whatever Horde is using. Anyway, enough of my random thoughts, anyone want to comment. Martin... P.S. I'm still thinking about expanding my upgrade thing to do a full CVS install and general configuration. From fourmont at gmx.de Sat Mar 31 10:56:00 2007 From: fourmont at gmx.de (Karsten Fourmont) Date: Sat, 31 Mar 2007 12:56:00 +0200 Subject: [dev] Turba shares and SyncML Message-ID: <460E3E40.5060007@gmx.de> Hi, I need some understanding of the Tuba share system to get it working properly with the SyncML code. Currently mnemo,nag and kronolith syncs are done against the default share as defined in the respective applications (typically the username, like "karsten"). Ultimately this should be user configurable, but that's for later. In Turba, things are a bit different. $prefs->getValue('default_dir') yield the name of the source.php source, like "localsql". In such a source there are various "subsources"(?), like "karsten". For turba_import, turba_replace, and turba_export this is just fine. However syncing needs the turba_listBy functionality that lists all changes of a given sources (localsql) since a specific timestamp. So how would I implement the correct listBy functionality for Turba? First guess is to store the source (localsql) rather than the owner in the Turba history entry. Otherwise we have no way to find out changes in localsql. But then the listBy need to do some "filtering" on the entries in the history, so that only the ones available for the specific user (the right "subsources") are returned. imho this needs to be similar to the Turba_Driver::search code. But how? Can anyone provide me with input for this? A general description how turba sources work would be a start. I'd very much like to get this done for Horde 3.2. Cheers, Karsten From mike at theupstairsroom.com Sat Mar 31 19:41:26 2007 From: mike at theupstairsroom.com (Michael Rubinsky) Date: Sat, 31 Mar 2007 15:41:26 -0400 Subject: [dev] Turba shares and SyncML In-Reply-To: <460E3E40.5060007@gmx.de> References: <460E3E40.5060007@gmx.de> Message-ID: <460EB966.7040108@theupstairsroom.com> It's been a while now since I wrote the share support in Turba so I may be a little rusty on the details, but the general gist of things for sources / shares goes something like this: For sources that support shares (SQL and IMSP), each horde user has a 'default' share (not to be confused with the 'default_dir' that the user chooses as a pref). This default share corresponds to the address book that is always present and is defined by the $cfgSources entry. This address book is referred to in the main Turba code simply as the source type ('localsql' for example). Turba_Driver::factory turns this into something like 'localsql:karsten' to use as a share name in order to retrieve the share information from the datatree. If the user has access to other shares, Turba creates new $cfgSources entries on the fly for those shares. The new entry is based on the 'base' $cfrSources entry for that source type. So, for example if you have access to *my* personal SQL address book, Turba would create a new $cfgSource entry with a key of 'localsql:mike'. In this case, Turba_Driver::factory sees the ':' in the source name and knows uses the full name to retrieve the share info from DT. When you perform a search on a share enabled source, the Turba_Driver that represents the address book being searched will determine what owner_id (to use the SQL driver's nomenclature) to search. For 'default' address books this will be the horde username, for user-created address books, this will be a 'uid' string. I'm not that familiar with your SyncML code so I can only offer very general suggestions here: It seems to me that we will need to have Turba save both the source type as well as the username. I may be missing something here, and I'm not looking at the code at the moment, but it currently looks impossible to know what source an entry was added/deleted from. My thought is that we should have Turba save both bits of data as we need both in order to create a Turba_Driver that points to the correct share. For instance, in my horde_histories table, I have the following object_uid 'turba:mike:20070111195012.34nrs5u9ldyc at portal.host.com' This would have to be saved as: 'turba:localsql:mike:20070111195012.34nrs5u9ldyc at portal.host.com' Then you should be able to pass something like 'turba:localsql:mike' to Horde_History::getByTimestamp. I'd have to look more closely to see if this is a BC break or not though. Another thing to consider is that I know we are trying to get rid of the hierarchal nature of the shares in Turba to make them compatible with the framework's Horde_Share code and Chuck's thinking was to do it by making the source name part of the group_uid (So the group_uid would be something like horde.shares.turba.localsql). Without looking at the code, I'm not really sure how that would affect this...perhaps Chuck could chime in here... Hope this helps you out somewhat. If you have any other questions, please ask. When I am sitting down where I can look at the code to refresh my memory I can probably give some more in depth answers. > Hi, > > I need some understanding of the Tuba share system to get it working > properly with the SyncML code. > > Currently mnemo,nag and kronolith syncs are done against the default > share as defined in the respective applications (typically the username, > like "karsten"). Ultimately this should be user configurable, but that's > for later. > > In Turba, things are a bit different. > $prefs->getValue('default_dir') > > yield the name of the source.php source, like "localsql". > > In such a source there are various "subsources"(?), like "karsten". > > For turba_import, turba_replace, and turba_export this is just fine. > > However syncing needs the turba_listBy functionality that lists all > changes of a given sources (localsql) since a specific timestamp. > > So how would I implement the correct listBy functionality for Turba? > > First guess is to store the source (localsql) rather than the owner in > the Turba history entry. Otherwise we have no way to find out changes in > localsql. > > But then the listBy need to do some "filtering" on the entries in the > history, so that only the ones available for the specific user (the > right "subsources") are returned. imho this needs to be similar to the > Turba_Driver::search code. But how? > > Can anyone provide me with input for this? A general description how > turba sources work would be a start. I'd very much like to get this done > for Horde 3.2. > > > Cheers, > Karsten > > > -- Thanks, Mike -- The Horde Project (www.horde.org) mrubinsk at horde.org From fourmont at gmx.de Sun Apr 1 11:32:42 2007 From: fourmont at gmx.de (Karsten Fourmont) Date: Sun, 01 Apr 2007 13:32:42 +0200 Subject: [dev] Turba shares and SyncML In-Reply-To: <460EB966.7040108@theupstairsroom.com> References: <460E3E40.5060007@gmx.de> <460EB966.7040108@theupstairsroom.com> Message-ID: <460F985A.2010407@gmx.de> thanks for the info, that did help. So the history should be changed to store the share name rather than the username/owner name as it currently does. This makes it consistent with the other apps as well. So I did change the history code to look like this: $history->log('turba:' . ($this->usingShares ? $this->share->name : $this->name) . ':' . $uid I checked all usage of history in turba and adapted it. So it shouldn't break anything. However all old history entries become useless with this change. I don't see a (practical) way to convert them. Cheers, Karsten Michael Rubinsky wrote: > It's been a while now since I wrote the share support in Turba so I may > be a little rusty on the details, but the general gist of things for > sources / shares goes something like this: > > For sources that support shares (SQL and IMSP), each horde user has a > 'default' share (not to be confused with the 'default_dir' that the user > chooses as a pref). This default share corresponds to the address book > that is always present and is defined by the $cfgSources entry. This > address book is referred to in the main Turba code simply as the source > type ('localsql' for example). Turba_Driver::factory turns this into > something like 'localsql:karsten' to use as a share name in order to > retrieve the share information from the datatree. > > If the user has access to other shares, Turba creates new $cfgSources > entries on the fly for those shares. The new entry is based on the > 'base' $cfrSources entry for that source type. So, for example if you > have access to *my* personal SQL address book, Turba would create a new > $cfgSource entry with a key of 'localsql:mike'. In this case, > Turba_Driver::factory sees the ':' in the source name and knows uses the > full name to retrieve the share info from DT. > > When you perform a search on a share enabled source, the Turba_Driver > that represents the address book being searched will determine what > owner_id (to use the SQL driver's nomenclature) to search. For > 'default' address books this will be the horde username, for > user-created address books, this will be a 'uid' string. > > I'm not that familiar with your SyncML code so I can only offer very > general suggestions here: It seems to me that we will need to have Turba > save both the source type as well as the username. I may be missing > something here, and I'm not looking at the code at the moment, but it > currently looks impossible to know what source an entry was > added/deleted from. > > My thought is that we should have Turba save both bits of data as we > need both in order to create a Turba_Driver that points to the correct > share. For instance, in my horde_histories table, I have the following > object_uid 'turba:mike:20070111195012.34nrs5u9ldyc at portal.host.com' > This would have to be saved as: > 'turba:localsql:mike:20070111195012.34nrs5u9ldyc at portal.host.com' Then > you should be able to pass something like 'turba:localsql:mike' to > Horde_History::getByTimestamp. I'd have to look more closely to see if > this is a BC break or not though. > > Another thing to consider is that I know we are trying to get rid of the > hierarchal nature of the shares in Turba to make them compatible with > the framework's Horde_Share code and Chuck's thinking was to do it by > making the source name part of the group_uid (So the group_uid would be > something like horde.shares.turba.localsql). Without looking at the > code, I'm not really sure how that would affect this...perhaps Chuck > could chime in here... > > > Hope this helps you out somewhat. If you have any other questions, > please ask. When I am sitting down where I can look at the code to > refresh my memory I can probably give some more in depth answers. From fourmont at gmx.de Sun Apr 1 15:51:37 2007 From: fourmont at gmx.de (Karsten Fourmont) Date: Sun, 01 Apr 2007 17:51:37 +0200 Subject: [dev] [Fwd: [cvs] commit: turba/config sources.php.dist turba/scripts/sql turba_objects.mssql.sql turba_objects.mysql.sql turba_objects.oci8.sql turba_objects.pgsql.sql turba_objects.sql] Message-ID: <460FD509.4040101@gmx.de> Hi, I modified the default localsql source to a more "groupware-like" field definition: separate firstname/lastname fields, split address fields etc. I hope that's fine with everyone. Please have a look at the sql to see if that's correct. I'm not an expert on the various sql flavors. Cheers, Karsten karsten 2007-04-01 08:45:13 EDT Modified files: config sources.php.dist scripts/sql turba_objects.mssql.sql turba_objects.mysql.sql turba_objects.oci8.sql turba_objects.pgsql.sql turba_objects.sql Log: Move default sql address book to a more "groupware-like" field definition: seperate firstname/lastname fields, split address fields... Revision Changes Path 1.162 +38 -23 turba/config/sources.php.dist 1.4 +38 -21 turba/scripts/sql/turba_objects.mssql.sql 1.6 +39 -23 turba/scripts/sql/turba_objects.mysql.sql 1.5 +39 -22 turba/scripts/sql/turba_objects.oci8.sql 1.7 +39 -23 turba/scripts/sql/turba_objects.pgsql.sql 1.6 +39 -23 turba/scripts/sql/turba_objects.sql Chora Links: http://cvs.horde.org/diff.php/turba/config/sources.php.dist?r1=1.161&r2=1.162&ty=u http://cvs.horde.org/diff.php/turba/scripts/sql/turba_objects.mssql.sql?r1=1.3&r2=1.4&ty=u http://cvs.horde.org/diff.php/turba/scripts/sql/turba_objects.mysql.sql?r1=1.5&r2=1.6&ty=u http://cvs.horde.org/diff.php/turba/scripts/sql/turba_objects.oci8.sql?r1=1.4&r2=1.5&ty=u http://cvs.horde.org/diff.php/turba/scripts/sql/turba_objects.pgsql.sql?r1=1.6&r2=1.7&ty=u http://cvs.horde.org/diff.php/turba/scripts/sql/turba_objects.sql?r1=1.5&r2=1.6&ty=u -- To unsubscribe, mail: cvs-unsubscribe at lists.horde.org From mike at theupstairsroom.com Sun Apr 1 17:17:13 2007 From: mike at theupstairsroom.com (Michael Rubinsky) Date: Sun, 01 Apr 2007 13:17:13 -0400 Subject: [dev] [Fwd: [cvs] commit: turba/config sources.php.dist turba/scripts/sql turba_objects.mssql.sql turba_objects.mysql.sql turba_objects.oci8.sql turba_objects.pgsql.sql turba_objects.sql] In-Reply-To: <460FD509.4040101@gmx.de> References: <460FD509.4040101@gmx.de> Message-ID: <460FE919.7000604@theupstairsroom.com> I think if we do this, we need to advertise it somewhat loudly. I know that the various config/*.dist files are examples and are meant to be modified, but I know a lot of installations use this out of the box (especially the localsql source) and an upgrade will therefore break the installation. We could try an upgrade script, but I doubt that would work in all cases of splitting the name / address fields...thoughts? Karsten Fourmont wrote: > Hi, > > I modified the default localsql source to a more "groupware-like" field > definition: separate firstname/lastname fields, split address fields etc. > > I hope that's fine with everyone. Please have a look at the sql to see > if that's correct. I'm not an expert on the various sql flavors. > > Cheers, > Karsten > > > karsten 2007-04-01 08:45:13 EDT > > Modified files: > config sources.php.dist > scripts/sql turba_objects.mssql.sql > turba_objects.mysql.sql > turba_objects.oci8.sql > turba_objects.pgsql.sql turba_objects.sql > Log: > Move default sql address book to a more "groupware-like" field > definition: > seperate firstname/lastname fields, split address fields... > > Revision Changes Path > 1.162 +38 -23 turba/config/sources.php.dist > 1.4 +38 -21 turba/scripts/sql/turba_objects.mssql.sql > 1.6 +39 -23 turba/scripts/sql/turba_objects.mysql.sql > 1.5 +39 -22 turba/scripts/sql/turba_objects.oci8.sql > 1.7 +39 -23 turba/scripts/sql/turba_objects.pgsql.sql > 1.6 +39 -23 turba/scripts/sql/turba_objects.sql > > Chora Links: > > http://cvs.horde.org/diff.php/turba/config/sources.php.dist?r1=1.161&r2=1.162&ty=u > > http://cvs.horde.org/diff.php/turba/scripts/sql/turba_objects.mssql.sql?r1=1.3&r2=1.4&ty=u > > http://cvs.horde.org/diff.php/turba/scripts/sql/turba_objects.mysql.sql?r1=1.5&r2=1.6&ty=u > > http://cvs.horde.org/diff.php/turba/scripts/sql/turba_objects.oci8.sql?r1=1.4&r2=1.5&ty=u > > http://cvs.horde.org/diff.php/turba/scripts/sql/turba_objects.pgsql.sql?r1=1.6&r2=1.7&ty=u > > http://cvs.horde.org/diff.php/turba/scripts/sql/turba_objects.sql?r1=1.5&r2=1.6&ty=u > > -- Thanks, Mike -- The Horde Project (www.horde.org) mrubinsk at horde.org From jan at horde.org Sun Apr 1 22:34:17 2007 From: jan at horde.org (Jan Schneider) Date: Mon, 02 Apr 2007 00:34:17 +0200 Subject: [dev] [cvs] commit: turba/config sources.php.dist turba/scripts/sql turba_objects.mssql.sql turba_objects.mysql.sql turba_objects.oci8.sql turba_objects.pgsql.sql turba_objects.sql In-Reply-To: <20070401124513.1C137BFE4@nazik.horde.org> References: <20070401124513.1C137BFE4@nazik.horde.org> Message-ID: <20070402003417.445inhna1w84wsck@neo.wg.de> Zitat von Karsten Fourmont : > karsten 2007-04-01 08:45:13 EDT > > Modified files: > config sources.php.dist > scripts/sql turba_objects.mssql.sql > turba_objects.mysql.sql > turba_objects.oci8.sql > turba_objects.pgsql.sql turba_objects.sql > Log: > Move default sql address book to a more "groupware-like" field definition: > seperate firstname/lastname fields, split address fields... > > Revision Changes Path > 1.162 +38 -23 turba/config/sources.php.dist > 1.4 +38 -21 turba/scripts/sql/turba_objects.mssql.sql > 1.6 +39 -23 turba/scripts/sql/turba_objects.mysql.sql > 1.5 +39 -22 turba/scripts/sql/turba_objects.oci8.sql > 1.7 +39 -23 turba/scripts/sql/turba_objects.pgsql.sql > 1.6 +39 -23 turba/scripts/sql/turba_objects.sql We need to provide an update script too. Probably a combination of SQL statements and PHP code, e.g. to split up the name field. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/