Last wednesday anton had to be admitted to the hospital with a skin rash. Also moni stays in hospital as assistant.
So i got promoted as the family manager. Cooking, do the dishes, tidy up, launder, aerateing, wakeup service, vacuum-cleaning, go shopping, feed the dryer, being taxi, bringing to bed, and being shuttle between home and hospital are my primary tasks, just to name the important once.
As required by Murphy’s Laws Leonie also got sick with a stomach flu. So just multiply the washing/drying items by three.
It’s a full time job, I tell you! Hats off to all the once, doing this all time. Every evening I’m glad the day is off. No time for hacking and nerd stuff.
Hopefully we can fetch moni and anton tomorrow night.
Concurrency Management is needed when two or more users edit the same record at the same time. Think of a contact, which gets opened for editing at the same time by two users. After one minute, the first user finished his changes and presses the save button while the second one is still working on the contact data. Now the second user is working on an old version of the contact. At the moment he presses the save button, we have a typical concurrency problem.
What can be done in a typical concurrency situation?
The most easy way is, just to ignore the conflict and save all data-sets ‘as the come’ into the database. This is called The last one wins or just no concurrency management. Needless to say, that in this case, the work of the fist editor is destroyed. But what’s more harmful is, that the first editor is not even notified or encouraged to review the data again. This is how the current eGroupWare 1.x works.
A better way of managing this situation, is to reject the save request from the second user with the notice that a concurrency problem has occurred. Than this user can fetch the updated contact an merge his changes manually. This procedure could be annoying for the second user, especially if there is no real conflict, cause the fist user modified other fields than the second user.
So what Tine 2.0 can do, is to detect in what fields the changes where made. This way it’s possible that Tine 2.0 merges the changes silently, when the user didn’t change the same field(s). We call it a resolvable concurrency conflict. At the moment it’s not clear if we should configure Tine 2.0 to act this way, or if it just should reject changes w.o. merging. The problem is, that the second user might be confused, that the contact in the database is not exactly the one he saved.
I made a little screencast to demonstrate the implementation in addressbook of Tine 2.0. This is my first screencast, so please be patient with me 
There are these days in life of an admin, when there is no way around touching the ldap setup. There is this stupid database suffix I gave my very first ldap setup.
As today is a public holiday, and there’s also a respectable rest of sparkling wine in the fridge, I took the chance to transform this suffix to one, fitting in the rest of my infrastructure.
As I haven’t found an adequate tool for changing the suffix in an ldif file, I post my script here. Hopefully there is someone out, I can help with it.
All you need to do, is to change the $to varibale in the top of the script. Than a
slapcat | changesuffix > my.ldif
should do the job.
Last wednesday anton had to be admitted to the hospital with a skin rash. Also moni stays in hospital as assistant.
