Paul Davies posted a very interesting question in response to our Changing a Lotus Notes view’s status from private to shared article:
I’ve spent some time (not much admittedly) looking for a stable and consistent method to delete ‘shared private on first use’ views (so they can be rebuilt with a new design) and have not found a combination of $Flag values that do this. They seem to change across versions. I might be able to do it by looking at the Class and $Reader and $Author fields. Any tips on that?
Around here, we pretty much gave up using Private on First Use and Private views/Private folders about a year ago.
The reason: We found them to be too much trouble. (For example, they can cause some headaches if the user does not have at least “Create personal folders/views” enabled in the ACL. In such cases, the private view or folder will be saved in the user’s local Notes desktop file, no matter what).
Nowadays, instead of using private views, we mostly use code to generate views and change the formula by ourselves. This involves a bit more work at the onset but it’s ultimately a time-saver and really much easier to manage afterward. And what’s even nicer: this approach gives you the flexibility to allow more than one user (or role/group etc) to access a view. This will be explained in detail in an upcoming Ytria Tech Lab post.
So back to the original question…
Listed below are a couple of functions we’d used a while back in some applications that had Private on First Use views (the functions are called in the PostOpen event of the DatabaseScript).
As you’ll see, we were looking for Flags$ that contain a “V” value–this signifies the view is private (see the aforementioned earlier article for more on this “V” value); this approach was more than sufficient in our particular case (we never encountered any trouble related to this).
But I should warn you, we did have one big issue with this code: it was sloooow…. This less-than-ideal performance was mainly due to the fact it had to look for all the views in the database (using dbCurrent.Views).
(An aside: Going way back, before we adopted this code, we had something even slower. This old code needed to find the “original” Private on First Use view then check to see if anything changed. If the private view in question did not match the ‘original,’ it would be updated).
So here’s the code (I should mention that despite its lackluster speed, it worked quite acceptably in the applications we used it for) :
The Hack Approach
For another application built later on, we tried a completely different approach: We used special ‘hack’ views designed to list the private views and private on first use views. These hack views let you quickly find any private views needed to be updated/removed (by looking at their modification dates).
This approach is really quite efficient. And since it uses the design class as a filter, it’s pretty much foolproof. You will find an example database that you can download below.
This example database contains:
1 agent named “Launch Private View code” which uses 1 Script Library (PrivateViewScript) with 1 function (RemoveOldPrivateView). It also includes 2 views (AllPrivateView and AllPrivateFirstUseView).
But here’s a word of warning: you should not re-save the views in this database in the Domino Designer because the $FormulaClass fields have been altered (naturally, we used scanEZ to perform these alterations).
Credit: All code in this post was written by Eric Houvenaghel.