Then I started working with other things and more or less stopped following the development of Alfresco. But now I’ve had a reason to install it again, for a customer project and I must say that it has improved a lot in just one year.

One of the things I missed most in earlier versions was the ability to search in a meningful way. I mean, if you have a site full of content it’s not very useful to be able to search for keywords only and get every single item that matches the keywords in any way at all. But nowadays a more powerful advanced search has been introduced and at a first glance it looks really useful.

I also like the fact that it’s possible to create content directly in the document library. Since that’s basically the same functionality as the Wiki it seems a bit odd that it hasn’t been included before, but still, it’s nice to see that it’s there now.

(Speaking of the Wiki, I really don’t see the need for that as it is today. Sure, you can link between pages, but other than that there’s really not much of a difference between creating a wiki page and a document. I’d like to see a proper wiki implementation, more like MediaWiki.)

Besides that, there are many more new or extended features that I look forward to test out (workflows etc), but the one thing that caught my interest the most is the new replication functionality. Not so much for the possibility to replicate between production sites, but for the fact that it might be a nice backup and disaster recovery tool.

Previously I’ve always found that hot backups were a pain in the *** with Alfresco. Ok, you could backup files with CIFS, but then you’d lose all meta data and what about the rest of the stuff? Backing up the repository could be done, but without exact timing of database backup and file backup there’s a big risk to end up with an inconsistency that might break the entire repository.

I haven’t really looked in to the new replication feature, so I don’t know to what extent it could be useful for backup purposes, but it sure seems interesting at first glance.

To allow for that you may populate an array in the LDAP config file (config.ldap.php) with users that should be authenticated against the database. It could look like this:

$AUTHCFG['sql_accounts']         = array("user1","admin");

This config means that users admin and user1 will authenticate with whatever password is stored in the SQL database.

The problem comes if user1 wishes to change his or her password in vTiger. If the system is set up for LDAP authentication no users, except for admin, which is an exception, will be able to change their passwords on their profile pages. The password field will only say LDAP Authentication, instead of showing a Change Password-button.

The reason for this is that the code creating the profile page checks which type of authentication that is used as standard, not which type that is used for this particular user.

To fix this you need to edit the file that contains the code creating the profile page: modules/Users/DetailView.php

Locate this section:

        global $AUTHCFG;
        $auth_type = strtoupper($AUTHCFG['authType']);

        // Allow to change the password of the local predefined 'admin' account
        if ($focus->user_name == 'admin') $auth_type = 'SQL';

        switch ($auth_type)
        {
        case 'AD':
                $buttons = "Active Directory authentification";
                break;
        case 'LDAP':
                $buttons = "LDAP authentification";
                break;
        default:
                $buttons = "";
                break;
        }

Comment out this line:

if ($focus->user_name == 'admin') $auth_type = 'SQL';

And instead add something like this:

// A bit of code to see wether the user authenticates through SQL
if (in_array($focus->user_name, $AUTHCFG['sql_accounts'])) $auth_type = 'SQL';

That should fix the problem!

I samband med det här så söker man just nu testpiloter via Smartson, 1 000 personer ska få chansen att tycka till om maten. Perfekt för någon som mig, som tyvärr äter alldeles för mycket dåliga luncher på jobbet!

Ett litet frågetecken är att grädden bara innehåller 27% fett, men enligt Arla så ska den gå utmärkt att vispa ändå och i så fall är det ju faktiskt ingen nackdel att den är lite magrare än vanlig vispgrädde.

Hursomhelst, Smartson ger just nu chansen att prova grädden och blogga om den, så med lite tur får jag anledning att återkomma till den inom en snar framtid.

I don’t know about that, but I figured that downgrading is never a preferred option, so instead I simply tried to disable smooth scrolling in the system settings. And voila, all of a sudden the problem is gone. As for the scrolling in other applications, it’s very well possible that it’s no longer as smooth as it could be, but honestly, I really can’t tell the difference. At least it’s not a degradation that disturbs me in any way.

for i in `find . -name "*DS_Store"`; do rm -i "$i"; done

One particularly annoying example is the fact that Apple for some reason thinks it’s important to send along file metadata when creating archives designated for file systems that cannot handle this metadata. Or in plain English: Whenever you create a tar archive in OS X, it will be full of hidden files, beginning with a dot, that contains metadata about the files in the tar archive. This might be good if you unpack the files in OS X, where the metadata could automatically be restored with the files. But if you, which is very likely if you use tar in the first place, intend to unpack the archive in another unix-ish environment you will have no use of the dot files, they will only be an annoyance.

Fortunately this could all be avoided, by telling OS X that you have no interest in the metadata. This could be done by simply setting an environmental variable. To do this, issue this command in a Terminal window:

export COPYFILE_DISABLE=true