Tickets :: [#3648] create_default_histories fails

6.0.0-beta1

8/7/25

Summary	create_default_histories fails
Queue	Turba
Queue Version	HEAD
Type	Bug
State	Resolved
Priority	1. Low
Owners	mrubinsk (at) horde (dot) org
Requester	han.spruyt (at) ijsselgroep (dot) nl
Created	03/17/2006 (7083 days ago)
Due
Updated	04/08/2006 (7061 days ago)
Assigned	04/01/2006 (7068 days ago)
Resolved	04/08/2006 (7061 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch	No

04/08/2006 05:40:38 PM	Michael Rubinsky	Comment #9 State ⇒ Resolved	Reply to this comment
Resolving. Will open again if any negative feedback.

04/01/2006 06:20:14 PM	Michael Rubinsky	Comment #8 State ⇒ Feedback	Reply to this comment
See if what I just commited to HEAD fixes this, it seems to work for me: http://cvs.horde.org/diff.php/turba/scripts/upgrades/create_default_histories.php?r1=1.1&r2=1.2&ty=u For those that are interested: The script now grabs all of turba's shares and adds them to the sources array if they are not already present. Another, sort of related problem was that since we were loading Turba's base.php before we were authenticated, Turba_Driver objects were created (and cached by singleton) - the factory method was never called after we authenticated - which broke some of the share-related code in Turba_Driver, so I had to modify the order of the include files somewhat etc...

03/30/2006 05:47:46 PM	Jan Schneider	Comment #7	Reply to this comment
No, definetely not on the framework level, this would break permissions completely. I don't know how to fix this, but you should be able to update shared sources with this script, you can update non-shared but private sources.

03/30/2006 04:28:23 PM	Michael Rubinsky	Comment #6	Reply to this comment
Yes, but it's still broken if used with shared sources. Turba::permissionsFilter($cfgSources, 'source', PERMS_EDIT); doesn't return any shared sources. I believe it's failing because, unless I'm missing something, the share/permissions system doesn't seem to care if the user is listed as an admin or not. I don't know if that is by design or not, so I'm not sure if I should implement this check at the turba level, or implement it at the framework level, so that if the user is listed as an admin in the global horde configuration, DatatreeObject_Share::hasPermission will always return true? That seems like a Bad Thing to me, although I may be just paranoid.

03/22/2006 06:21:14 PM	Jan Schneider	Comment #5 State ⇒ Assigned Assigned to Michael Rubinsky	Reply to this comment
Yes, but it's still broken if used with shared sources. Turba::permissionsFilter($cfgSources, 'source', PERMS_EDIT); doesn't return any shared sources.

03/22/2006 06:19:35 PM	Chuck Hagenbuch	Comment #4	Reply to this comment
Jan, did you just fix this?

03/18/2006 01:50:31 PM	han (dot) spruyt (at) ijsselgroep (dot) nl	Comment #3	Reply to this comment
Have you added the uid field to your sql table and to the source map? object_uid is in turba_objects and '__uid' => 'object_uid' is in source map for localsql.

03/18/2006 05:54:48 AM	Chuck Hagenbuch	Comment #2 State ⇒ Feedback	Reply to this comment
Have you added the uid field to your sql table and to the source map?

03/17/2006 09:34:56 PM	han (dot) spruyt (at) ijsselgroep (dot) nl	Comment #1 Priority ⇒ 1. Low Type ⇒ Bug Summary ⇒ create_default_histories fails Queue ⇒ Turba State ⇒ Unconfirmed	Reply to this comment
Running "turba/scripts/upgrades/2004-10-26_create_default_histories.php" does not add a 'Created' time to contacts. Output shows no errors : Creating default histories for localsql ... Default histories successfully created * There are contacts in localsql without Created time.