Hierarchical Moves

Thursday 26th May, 2005
I've got a major internal project going on right now, in fact many...

One of them is to move my entire user base into a new OU, we're adding in a departmental OU that has been historically overlooked. It all sounds so simple doesn't it? Fred Bloggs/UK/Org becomes Fred Bloggs/Department/UK/Org. All good in principle, but in practice very different.

One submits a "user move in hierarchy" request, it all goes ahead and processes. The user's Notes client auto-accepts the new name (R6) and then all the email and I mean ALL the email goes unread. Absolutely f***ing useless.

Alas, we check adminp...there's a sub-process "Rename person in unread list". We wait...all excited. It processes...we're still excited. It's finished...they're all still unread.

This is now halting my entire project. There is no way in hell I can possibly break every user's unread marks just weeks after a server migration did just the same. It's consistent, it's reproducable and I have never, ever seen it work.

In my opinion, unread marks are the worst problem ever experienced in the Notes client. It's the most visible to users, they all depend on  them and they break all the time. User rename...unread marks break. Change Server...broken. Change OU...no chance. Cluster failover...if you're lucky.

I know I'm not alone, I used to work in Lotus Customer Support, I used to receive these problems and point them to technotes and SPRs that, basically, said sorry but they don't always work.

Enough is enough, I need your help. If you have problems with unread marks, please post a comment here. It's time we logged calls with Lotus and got this recognised as a major issue. As far as I can tell, this has not and will not be addressed in R7. We need it fixed...don't we?

Comments/Trackbacks [10]