bookmark_borderJan Schneider: Automatic twitter messages with Horde_Service_Twitter and two lines of code

Jan Schneider just posted a damn cool use case for the Horde_Service_Twitter library. Using this library, just a few lines of php code are enough to send messages to your twitter stream like this:

#!/usr/bin/env php
<!--?php
/* Keys - these are obtained when registering for the service */
$keys = array(
'consumer_key'        => '',
'consumer_secret'     => '',
'access_token'        => '',
'access_token_secret' => ''
);

/* Enable autoloading. */
require 'Horde/Autoloader/Default.php';

/* Create the Twitter client */
$twitter = Horde_Service_Twitter::create(array('oauth' => $keys));

/* Send tweet */
try {
$twitter->statuses->update($argv[1]);
} catch (Horde_Service_Twitter_Exception $e) {
$error = Horde_Serialize::unserialize($e->getMessage(), Horde_Serialize::JSON);
echo "$error->error\n";
exit(1);
}

Now that’s neat, isn’t it.
In another team I worked with, we used a perl library which sent jabber/xmpp streams to our chat accounts when something ran into an uncought exception.

This might be worth porting to PHP/Horde some day.

bookmark_borderHorde 4.0.6 brings user-specific admin privileges

Traditionally, Horde only knows two kinds of users: Users with administration flag and users without. The list of admins is a static entry in the horde config file. It’s all or nothing – either a user gets access to all admin functions or to none. At least until recently.

Last October I wrote about a patch for Horde 3 which allows permission-based access to individual admin privileges. This patch has now been ported to Horde 4 and is incorporated in Horde 4.0.6. You can now assign a user the task of managing groups without allowing him to use the permissions admin and grant himself additional privileges. Or you can delegate emergency password resets to a group of trusted people without confusing them with icons like the PHP Shell. Only those admin functions are shown which the user has access to. Another side effect: Even if a user has all admin permissions, he is still not recognised as an admin and won’t be shown things that admins always have to see regardless of their permissions and settings.

In theory, you can now give yourself all admin permissions and safely delete yourself out of the admin list – as long as you have the “configuration” permission, you can always go back and restore without manually editing the conf.php file.

The Administration permissions are handled in the permissions screen just like any other user permissions. They live under the “horde” component. Currently only the “show” flag is actually recognized but this will be expanded later.

bookmark_borderMigrating Horde 3 to Horde 4 – Top 6 ways to mess up

There have been some migrations of Horde 3 to Horde 4 recently – not all went smooth from the start.

Some top issues of messing things up and how to avoid it:

  1. initial application dimpIn Horde 3 dimp was a separate application which provided an ajax interface to imp. It has since been merged into the imp application. If your Horde installation had dimp before migration to Horde 4, this might create runtime issues for your users when
    • when you locked the initial application to dimp
    • when your users decided that their initial application should be dimp

    To get around this you should

    • make sure you didn’t blindly copy your locked settings from horde 3 to horde 4
    • run a mysql update statement on the horde_prefs table to update column pref_value to “imp” if it was “dimp” before (Consider hiring a professional admin for the migration if you don’t know how that looks like)
  2. Making changes in backends.php or prefs.php
    In Horde 3 admins used to edit prefs.php or backends.php/servers.php to change values. Horde 4 ships backends.php and prefs.php as default values. Admins are supposed to copy these to backends.local.php and prefs.local.php and make their changes there. Changes to the original files will be overridden with the next rpm or pear update of the horde apps.
  3. Not unchecking utc time in kronolith
    The Horde 3 Calendaring app defaulted to store calendar events in local user time. The Horde 4 default is UTC timestamps. If you migrate from horde 3 you either have to uncheck that setting or run a migration script on the data.
    Warning: You might end up with an unrecoverable state if you add new data in UTC mode to a calendar backend which has not been converted to UTC timestamps
  4. Not converting turba and kronolith databases to utf8
    In Horde 3 installations, the calendar app kronolith and the addressbook turba often had their database tables encoded in latin1. The system wide default in Horde 4 is utf8. Not adapting this setting to the tables or the tables to this setting results in corrupted display of international characters and symbols.
    Warning: You might end up with an unrecoverable state if you add new data to addressbooks or calendars where backend encoding does not match the set horde encoding
  5. Relying on menu.php’s javascript onclick handler or target attribute
    In the ajax views of kronolith and imp there is currently no support for the target and onclick handler attributes. I do not know of any plans to re-add this support. If you want to link external sites into the iframe, consider creating a custom portal block. There was a recent blog post on creating this kind of blocks on The Upstairs Room
  6. Using the ldap prefs backend
    The ldap backend for preferences is currently not yet ported to horde 4. If you want to migrate, you first have to extract your prefs from ldap and then convert them to sql. If you need ldap prefs, consider hiring a consultant or sponsoring the development of this feature.
Tres consejos principales para ejercicios de entrenamiento de culturismo nvrzone ranbaxy drogas en venta mejor mezcla de musica ncs gym workout.