| Summary | Removing entry from group error removeMember |
| Queue | Turba |
| Queue Version | HEAD |
| Type | Bug |
| State | Not A Bug |
| Priority | 1. Low |
| Owners | Michael Rubinsky <mrubinsk (at) horde (dot) org> |
| Requester | grahamcw (at) hurleybulldogs (dot) com |
| Created | 03/20/2008 (52 days ago) |
| Due | |
| Updated | 04/25/2008 (16 days ago) |
| Assigned | 04/25/2008 (16 days ago) |
| Resolved | 04/25/2008 (16 days ago) |
| Attachments | |
| Milestone | |
| Patch |
I believe this was due to bad data. Once I did some additional cleaning and updated the database - the problem is gone and not reccreatable
State ⇒ Feedback
Is this still happening? Did you check the object type in the database as suggested below?These address books go back to pre-shareding times - they resided in 3 seperate databeses origionally, Then last year were converted into an early Horde3/Imp4 et. al. CVS format - then converted again about a month ago to one of the RC's. They have been around for a long time.Assigned to Michael Rubinsky
Now that I think about this some more, I do remember there being an issue a while ago that had to do with parsing a name into first/last names with groups...that might be the issue here - the groups might have been created during that time?
Anyway - regardless of what caused the original issue - the fix is to make sure that the 'object_type' field (assuming your using the out-of-the-box turba_objects table) for the group entries need to be set to "Group". You can search on the 'object_id' field for the value you will see as the "key" url parameter in the link to view the group.
Please get back to us and us know if this was indeed the issue, thanks!
... oh, and are the entries in the group all from the same address book the group is in or are some of the "foreign" to the address book the group is in?> Do you want further information ?
Just some clarification since there were a number of possible "conversions" that could have been done: Do you mean it was originally a shared sql address book that was *not* using shares that was converted to a share-enabled address book or something else?
I did find another adddress bok that was converted.
It exhibits the same behavior. And same error message.
Do you want further information ?
I cannot reproduce it now.
This was a conversion address book - maybe some residue ?
I hate those answers.
Sorry for the static
I am running the snapshot form March 15th or 16th.
It is a shared local sql addressbook not my primary addressbok - a facility shared addressbook that I maintain. I go to Browse - then select the book from the dropdown list of my address books.
turba/lib/Views/Browse.php,v 1.16 2008/02/26 00:08:51 jan
State ⇒ Feedback
This seems to work fine for me. Furthermore, the file that your including *should* be taken care of by Turba_Driver::getObjects().
Can you provide more information? Are the contacts all from the same source? Are you using shares? are you sure you are 100% up to date with HEAD etc...
Patch ⇒
Milestone ⇒
Queue ⇒ Turba
Summary ⇒ Removing entry from group error removeMember
Type ⇒ Bug
Priority ⇒ 1. Low
State ⇒ Unconfirmed
Browse Address book - sql
Select group entry
From expanded lst - select entry
and selct Remove From this list
PHP Fatal error: Call to undefined method PEAR_Error::removeMember() in /var/www/html/webmail/turba/lib/Views/Browse.php on line 110
adding
require_once TURBA_BASE . '/lib/Object/Group.php';
to turba/lib/Views/Browse.php
corrected it