asked on

Lotus Domino Designer - View based on username and field not showing correctly

I have a database with one form and 42 dropdown fields (Assignees to a record) populated with a group of lotus names. I have 4 views to create a dashboard for the assignees. One is all records assigned to the user, the other 3 have a restriction based on the record status. Here is the select formula for the view that pulls all records the user is assigned to:

My field names are pro1 - pro21 and sme_1 - sme_21

SELECT (@Name([CN];pro1) = @Name([CN];@UserName) |
@Name([CN];pro2) = @Name([CN];@UserName) |
@Name([CN];pro3) = @Name([CN];@UserName) |
@Name([CN];pro4) = @Name([CN];@UserName) |
@Name([CN];pro5) = @Name([CN];@UserName)|
@Name([CN];pro6) = @Name([CN];@UserName)|
@Name([CN];pro7) = @Name([CN];@UserName)|
@Name([CN];pro8) = @Name([CN];@UserName)|
@Name([CN];pro9) = @Name([CN];@UserName)|
@Name([CN];pro10) = @Name([CN];@UserName)|
@Name([CN];pro11) = @Name([CN];@UserName)|
@Name([CN];pro12) = @Name([CN];@UserName)|
@Name([CN];pro13) = @Name([CN];@UserName)|
@Name([CN];pro14) = @Name([CN];@UserName)|
@Name([CN];pro15) = @Name([CN];@UserName)|
@Name([CN];pro16) = @Name([CN];@UserName)|
@Name([CN];pro17) = @Name([CN];@UserName)|
@Name([CN];pro18) = @Name([CN];@UserName)|
@Name([CN];pro19) = @Name([CN];@UserName)|
@Name([CN];pro20) = @Name([CN];@UserName)|
@Name([CN];pro21) = @Name([CN];@UserName)|
@Name([CN];sme_1) = @Name([CN];@UserName)|
@Name([CN];sme_2) = @Name([CN];@UserName)|
@Name([CN];sme_3) = @Name([CN];@UserName)|
@Name([CN];sme_4) = @Name([CN];@UserName)|
@Name([CN];sme_5) = @Name([CN];@UserName)|
@Name([CN];sme_6) = @Name([CN];@UserName)|
@Name([CN];sme_7) = @Name([CN];@UserName)|
@Name([CN];sme_8) = @Name([CN];@UserName)|
@Name([CN];sme_9) = @Name([CN];@UserName)|
@Name([CN];sme_10) = @Name([CN];@UserName)|
@Name([CN];sme_11) = @Name([CN];@UserName)|
@Name([CN];sme_12) = @Name([CN];@UserName)|
@Name([CN];sme_13) = @Name([CN];@UserName)|
@Name([CN];sme_14) = @Name([CN];@UserName)|
@Name([CN];sme_15) = @Name([CN];@UserName)|
@Name([CN];sme_16) = @Name([CN];@UserName)|
@Name([CN];sme_17) = @Name([CN];@UserName)|
@Name([CN];sme_18) = @Name([CN];@UserName)|
@Name([CN];sme_19) = @Name([CN];@UserName)|
@Name([CN];sme_20) = @Name([CN];@UserName)|
@Name([CN];sme_21) = @Name([CN];@UserName))

Sjef Bosman

Is not going to work. It might work, for a while, but only for one user, and all other users get the same view content. Explanation: view content is more or less fixed (which is why it's fast). @UserName is calculated once for a document in the view, and then that value is used everywhere, also by other who use the view: if the document isn't updated, neither is the view.

The ideal way to get what you want to accomplish:
- create a view, first column categorized, with a formula like
@Name([CN];@Trim(sme_1:sme_2: ;;;;))
- create a page
- put an embedded view on that page, that shows a single category
- for the single category formula, use
@Name([CN];@UserName)

larsberntrop

Also, view performance will be way better if you accumulate assignee names on the document, and not in the view. At the bottom of the form create a Computed multivalue Names field 'AssigneeAccu'. I would hide it. Formula: @Sort(@Trim(@Unique(pro1:pro2:pro3:pro4:pro5:pro6:pro7:pro8:pro9:pro10:pro11:pro12:pro13:pro14:pro15:pro16:pro17:pro18:pro19:pro20:pro21:sme_1:sme_2:sme_3:sme_4:sme_5:sme_6:sme_7:sme_8:sme_9:sme_10:sme_11:sme_12:sme_13:sme_14:sme_15:sme_16:sme_17:sme_18:sme_19:sme_20:sme_21)))

Note that pro1 - pro21 and sme_1 - sme_21 should be names fields too. That way, if you assign an Administration Server to the db, and set the ACL to let the admin server kep all names up to date, if anyone changes his or her name the records stay assigned to the right person.
Then the formula for the column becomes:
AssigneeAccu

larsberntrop

Note that you could also use a reader field (the AssigneeAccu field is a good candidate) so that the single category is not necessary. That gives you more options in the view like enabling alternate sort columns (which do not work in combination with single category display).

Keep in mind that for large numbers of documents and assignees, a performance problem may arise when using Reader fields. This is because Domino likes to return 64k of view data, and if only a small percentage of the documents can be seen, Domino still needs to first plough through a lot of documents before the buffer is filled. Just test it and keep it in mind and document it, so in 10 years time you know what to look for if people complain.

ASKER CERTIFIED SOLUTION

k_ander

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Sjef Bosman

I strongly advise you not to use this type of view if you may have to change the design of the view. Even one change can become a serious pain in the neck: because the view will become a private view once used, you cannot update its design. So ONLY use this type of view when you are 100% sure its design will never change.

larsberntrop

@K_ander:

Please consider educating yourself further by exploring redbooks and other resources about Domino design.

@Sjef: that happens when people don't get the opportunity to properly study Domino, and have to opt for the first solution that works.

Sjef Bosman

@Lars: that's a little true, indeed. I asked myself yesterday: hm, yes, it apparently solved a problem, so it seems a good suggestion, but why didn't I propose it myself? Answer: it's just not in my toolbox. And for a good reason: it's a good tool, but you need to be cautious with it. It's quite often that there are many solutions to a problem in a particular situation in Notes, but one really has to know the pros and cons of them all in that situation. That takes time, months, often even years...

k_ander

ASKER

I determined this solution to be best after speaking to my internal team. When changes are needed, I created an updated view and point the outline to the new view. So far it has worked perfectly!