Question

I have some views that uses @UserName in the selection formula. For working that, the view must be “Shared, Desktop Private on 1st use”. That is no problem.

But this views are going to be redesigned quiet often.

As this is a bunch of views it is very uncomfortable for the user to delete each of this views to recreate from scratch with design changes.

I try different things to get that done with an agent but no one is fool-proof and give some strange results (sometimes even do not update the design).

Best result so far is to delete the icon from the workspace and open the application again. That works (until now) always. But this is so annoying for end users to reopen the app from the (deep leveled) server folders.

Any other method to update the design of “private on 1st use” views ?

Answer 1

I have tried to solve the same problem and ended up doing two things – (1) automatically send the user an email with a link to the database and ask them to remove the database icon so that the private views get deleted and (2) alert the user when the design of a private view has changed.

The first part was fairly simple – I wrote a LotusScript function that would send the current user an email message containing a link to the current database (the one that contains the private views), along with some meaningful text and database information. All the user had to do then was exit the database, remove the database icon, open the email they just received and open the database again using the link. No need to navigate the server folders or wonder which server to go to. This can be used on its own, e.g. in a button, but I ended up combining it with something a little more tricky.

The second part was devising a way to alert the user that the design of the view they are opening is outdated. The tricky part was detecting that the design of the view has changed. What made this possible was what actually caused the problem in the first place – the fact that Notes caches the private view. When caching the private view, Notes also caches constants that the script in the view events refer to, that are part of LotusScript libraries the view uses.

Here’s a description of the design I used:

• Let the view use shared script library, PrivateViewsCode.
• In PrivateViewsCode‘s (Declarations) declare Const DESIGN_VERSION = "1.0".
• In PrivateViewsCode declare function myQueryopen. One of the parameters myQueryopen receives is string designVersion.
• In the private view’s Queryopen event call myQueryopen, passing DESIGN_VERSION to designVersion. Since this code is in the view that is cached, DESIGN_VERSION will contain the constant value as it were in the moment the view design was cached (when the user first opened it), in this case – "1.0".

• In myQueryopen compare designVersion to DESIGN_VERSION.

  Dim designChanged As Integer  
  designChanged = (designVersion <> DESIGN_VERSION)  
  

  Since myQueryopen is part of PrivateViewsCode script library, here you actually compare the DESIGN_VERSION (as cached in the private view and then passed to myQueryopen) to DESIGN_VERSION from PrivateViewsCode, which is always current.

• The only thing left is to be sure to recompile the views (Tools\Recompile all LotusScript) after changing DESIGN_VERSION.

I hope this explains the design, here is how it works:

• After making changes to private views design you change the version:

  DESIGN_VERSION = "1.1"  
  

• Recompile all LotusScript.
• Refresh the database design.
• Users open any private view that uses this functionality.
• They get a message saying they will receive link to the database and that they have to remove the icon from the workspace and open it again using the provided link.
• The user closes the database and removes the icon – private views are deleted.
• The user opens the database link in the email, the next time they open one of the private views, the new design is cached along with the new value of DESIGN_VERSION (here, "1.1").
• The comparison (designVersion <> DESIGN_VERSION) now yields false. Everything is back to normal until the next update.

Ken’s way of handling this has the major advantage of not involving the users at all. This wasn’t an option for me because of the frequency with which I made changes to the views (the application was just deployed and I had many requests for changes to the views) as well as the big number of private views in the application.

(Edit)
I assumed you had a specific reason to use private views, but I used the “Show Single Category” in an embedded view (just as leyrer suggests) ever since it became available and was quite happy with it. If you see any limitations to using the “Show Single Category” option, I’ll try to help you with that.