Re: shares problem with sql addressbook - turning off use_shares turns off browsing.

> $conf['share']['no_sharing'] just means that people can't edit
> permissions on their shares. They can still edit their names, list
> them, delete them, etc, so it's appropriate to show the Address Books
> list even with it turned on.

That doesn't really explain why we're unable to browse the sql based  
addressbook if we set "use_shares" to false.

What should we do if we don't want to allow our users to create  
multiple address books?  Edit Turba's getMenu() function?  That seems  
less than ideal.

Liam

--

-- 
Turba mailing list - Join the hunt: http://horde.org/bounties/#turba
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: turba-unsubscribe <at> lists.horde.org

Re: shares problem with sql addressbook - turning off use_shares turns off browsing.

Quoting liamr <at> umich.edu:

>
>> $conf['share']['no_sharing'] just means that people can't edit
>> permissions on their shares. They can still edit their names, list
>> them, delete them, etc, so it's appropriate to show the Address Books
>> list even with it turned on.
>
> That doesn't really explain why we're unable to browse the sql based
> addressbook if we set "use_shares" to false.

Yes, that is a totally seperate issue. The use_shares attribute  
determines if that particular source should have Horde_Share support  
enabled...which basically treats all address books as a share,  
allowing users to modify permissions, create/delete their own address  
books etc...  The 'no_sharing' conf parameter basically says, for  
every one of the user's shares across Horde, always use the default  
permissions and don't let user's change them.

If you are unable to browse any address books when use_shares is  
false, then that is a separate bug/issue. First, just to clarify, with  
use_shares set to false, then *only* the single, default, address book  
for each user will be visible.  Other users will not be able to see  
your personal address book.

You also might want to check to make sure there is nothing screwy  
going on with the addressbook pref.  You might try clearing that pref  
in your pref backend for a user that is having this issue and see if  
that clears it up.  My money would be on this being the problem.

Re: shares problem with sql addressbook - turning off use_shares turns off browsing.

> You also might want to check to make sure there is nothing screwy going on 
> with the addressbook pref.  You might try clearing that pref in your pref 
> backend for a user that is having this issue and see if that clears it up. 
> My money would be on this being the problem.

Mike -

You hit the nail on the head.  Deleting the addressbooks pref has solved 
the problem.. but I wish I knew what caused it in the first place.  Is 
this what happens if you deploy with use_shares turned on, but then 
disable it?

Liam
--

-- 
Turba mailing list - Join the hunt: http://horde.org/bounties/#turba
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: turba-unsubscribe <at> lists.horde.org

Re: shares problem with sql addressbook - turning off use_shares turns off browsing.

Quoting Liam Hoekenga <liamr <at> umich.edu>:

>> You also might want to check to make sure there is nothing screwy going on
>> with the addressbook pref.  You might try clearing that pref in your pref
>> backend for a user that is having this issue and see if that clears it up.
>> My money would be on this being the problem.
>
> Mike -
>
> You hit the nail on the head.  Deleting the addressbooks pref has solved
> the problem.. but I wish I knew what caused it in the first place.  Is
> this what happens if you deploy with use_shares turned on, but then
> disable it?

The "default" personal address books are referred to differently when  
using shares vs not using shares, so when the pref is stored using  
shares, it's stored with the share_id that the share driver will  
understand...when it's stored when not using shares, it's stored as  
the "plain" sql driver will understand.

If you look in the prefs UI for Turba though, you should still see the  
personal address book, it might just be on the "don't use" side ...  
then you'd have to move it over to the (probably empty-looking) "do  
use" side. At least that's how it's *supposed* to work (and appears to  
work on my end when I tested it just now).

Thanks,
mike

--

upgradeprefs maintenance task

How / when does the "upgrade prefs" maintenance task get invoked in Turba 
2.2RCx?

I'm trying to figure out a mysterious situation where people's search 
sources are getting set to what looks like a hash for some sort..

+----------+------------+----------------+----------------------------------+
| pref_uid | pref_scope | pref_name      | pref_value                       |
+----------+------------+----------------+----------------------------------+
| liamr    | imp        | search_sources | 687f9b6c5497ce57fa72a9ecce3412b6 |
+----------+------------+----------------+----------------------------------+

Liam
--

-- 
Turba mailing list - Join the hunt: http://horde.org/bounties/#turba
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: turba-unsubscribe <at> lists.horde.org

Re: upgradeprefs maintenance task

Quoting Liam Hoekenga <liamr <at> umich.edu>:

> How / when does the "upgrade prefs" maintenance task get invoked in Turba
> 2.2RCx?

It gets run the very first time a user logs in to Turba 2.2 and  
his/her turba data is accessed.

>
> I'm trying to figure out a mysterious situation where people's search
> sources are getting set to what looks like a hash for some sort..

That hash represents an address book from a share enabled source.  The  
task runs to check for pref entries that reference the "old" style  
notation for those sources (pre Turba 2.2).

Thanks,
mike

--
The Horde Project (www.horde.org)
mrubinsk <at> horde.org

"Time just hates me. That's why it made me an adult." - Josh Joplin

--

-- 
Turba mailing list - Join the hunt: http://horde.org/bounties/#turba
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: turba-unsubscribe <at> lists.horde.org

composite fields look editable in Firefox

This seems like it's probably a CSS issue, but I can't figure out what 
element I'd need to change.

We've found that the composite fields for sql based addressbooks (eg 
"names", "homeAddress", etc) look like they're editable to users using 
firefox on (mac, windows, linux).  I've tried several different themes 
("blue and white", "purple horde", "silver surfer", "tango blue"), and 
they all exhibit this issue.

So, I was wondering what CSS we'd change to make the difference more 
obvious.  Or, maybe we should consider only showing the composite fields 
in the "view mode", but the component fields ( "first name", "last name", 
etc) in the "edit mode"

Liam
--

-- 
Turba mailing list - Join the hunt: http://horde.org/bounties/#turba
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: turba-unsubscribe <at> lists.horde.org

turba broken since cvs update?

Hey guys -

I did a cvs update this morning, and now Turba won't load.  I've updated 
all of my conf files.  I don't get any error messages in the horde or 
apache error logs.

Ideas?

Liam
--

-- 
Turba mailing list - Join the hunt: http://horde.org/bounties/#turba
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: turba-unsubscribe <at> lists.horde.org

Re: turba broken since cvs update?

Quoting Liam Hoekenga <liamr <at> umich.edu>:

> I did a cvs update this morning, and now Turba won't load.  I've updated
> all of my conf files.  I don't get any error messages in the horde or
> apache error logs.

Is error_reporting set to E_ALL for PHP? Is either display_errors or  
log_errors on?

And what branch did you cvs up to?

-chuck
--

-- 
Turba mailing list - Join the hunt: http://horde.org/bounties/#turba
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: turba-unsubscribe <at> lists.horde.org

Re: turba broken since cvs update?

>> I did a cvs update this morning, and now Turba won't load.  I've updated
>> all of my conf files.  I don't get any error messages in the horde or
>> apache error logs.

Actually, it did load, but it's super slow to do so.  It took me about 
3:30 minutes between clicking on Turba's icon and actually getting into 
turba.  Subsequent actions with in turba take a similarly long time.

I do see datatree activity in the horde log:

Mar 11 16:58:22 HORDE [debug] [turba] SQL Query by 
DataTree_sql::_exists(): SELECT datatree_id FROM horde_datatree WHERE 
group_uid = ? AND datatree_name = ? AND datatree_parents = ?, array (
   0 => 'horde.perms',
   1 => 'personal_sql',
   2 => ':549521:549522',
) [pid 8295 on line 398 of "/usr/lib/php/Horde/DataTree/sql.php"]

> Is error_reporting set to E_ALL for PHP? Is either display_errors or
> log_errors on?

php.ini:
     error_reporting = E_ALL

(which phpinfo() is showing as "error_reporting	6143")

horde/conf.php:
     $conf['debug_level'] = E_ALL;
     $conf['log']['priority'] = PEAR_LOG_DEBUG;