If I understand your question correctly, what you are doing is changing the view selection formula for the real view you use to create view1. You can check that view and you'll see that the view selection formula change to that which is not really a good practice if other user is trying to access that view because the selection formula always changes.

Also that has nothing to do with the case where the database is full-text indexed. 

However, the search in view results that you are trying to use is actually using full-text index so you are good to go. Which means your code view1.setSelectionFormula ("SELECT (@IsMember(@UserName(),ACCurrentApprovers)") is not correctly applied here.

What you need is go to here  , search for 'query syntax', read it up and build a string of query syntax to be computed into 'search in view results'.

My guess is your syntax is going to be something like this: 

 FIELD ACCurrentApprovers CONTAINS this user

By the way, go and reset the selection formula first. 

After posting my original query I realized that I really did not want to reset the Selection formula but do a full text search. I have created the following code in the search for the the dataView in question

var user = context.getUser().getFullName();
var qString  = "(FIELD ACCurrentApprovers CONTAINS \"" + @UserName() + "\")"
return qString

I have used both the var user and the @UserName() but with either case I geta 500 Internal Server Error.

From what I have read and looked  seen this should work. It compiles without error.

I'm at a bit of a loss on this.  

 Try putting this instead in the search in view result (just 1 line of code):

"FIELD ACCurrentApprovers CONTAINS "+session.getCommonUserName()  

If error occurs again, try open your database in designer > Application Configuration > Xsp Properties > Under 'Error handling', check the 'Display XPage runtime error page' > Try previewing again. Check what are exactly the errors.

Boy do I feel dumb, I had been working on a DB that was full text indexed, switched DB and the new one was not.

The code:

"FIELD ACCurrentApprovers CONTAINS " + session.getCommonUserName()

does not throw an error and seems to do the selection correctly except the names in ACCurrentApprovers are in the format CN=SomeName/O=SomeOrg. I substituted getUserName() and I get the error that the query is not understandable. Tried @UserName() with the same result. From the documentation that I have seen both should just return a String value in the form CN=SomeName/O=SomeOrg. Am I missing something?

I changed the code to:

var us:String = session.getUserName()
"FIELD ACCurrentApprovers CONTAINS " + session.getCommonUserName()

this does not throw an error but gives the wrong results, then I changed it to

var us:String = session.getUserName()
"FIELD ACCurrentApprovers CONTAINS " + us

 

and I get the error query is not understandable.  

I put the code session.getUserName() in a computed field in the pagerTop and it displays the full users name correctly so it does not appear to be an issue with session.getUserName in a Data View. This process is really getting "not understandable"

Thanks for the help. 

Get it to work with this:

 

"FIELD ACCurrentApprovers CONTAINS " + "\"" + context.getUser().getDistinguishedName() + ""\"; 

This is really strange

I have set the var user to the distinguished name  :

var user:String = context.getUser().getDistinguishedName(); 

then make the query

 

tmpArray[cTerms++] = "(FIELD ACCurrentApprovers CONTAINS \"" + user + "\")";
and it fails to find any documents, however if I set the var user to the Common Name

  var user:String = @Name("[CN]",context.getUser().getDistinguishedName());

it finds the correct users, which is OK until there are two people in the organization with the same common name but in different OU's  

would the "/" in the distinguished name CN=Some Name/O=Some Org causing problems. Clearly ACCurrentApprovers is fully distinguished as is the getUser().getDistinguishedName()

I've got it working but not deliverable.   

 

Yes it is a bit of a kludge but will work around the issue. I would think that (field Contains @UserName) would be a pretty standard search. I'd tend to call it a bug rather than an undocumented enhancement! :-) But a generalized case would require that I parse out the CN. OU, and O into separate variable then formulate the query. Because not every organization uses the OU, you would need to check if it is blank otherwise the field CONTAINS "" would fail. Just looks like a ton of extra effort for no reasonable gain. And that does not cover the several hours I've spent so far just to find out it was not my code, but what I would call a bug because if you enter the query MyField CONTAINS @UserName into the Notes FTIndex Query it returns the correct search results.

Further investigation and actually your work around will not work as a generalized case. If the field that you are querying is a multivalue fields and it contains several names from different  OU's you have no way of knowing if the CN/OU/O that it finds all relate to the same individual. I believe that the FTIndex lookup in SSJS is flawed and does not work in several different instances. I have found another instance wher I can not get the SSJS Search code does not work. I have a field in a document that may contain one or more roles, and I want to select documents where a user holds a role that is contained in the field, of course the user might possess more that one role as well. If I put the following in the Search property :

 var userRoles:Array = session.evaluate("@UserRoles");

qString =  "(FIELD ACCurentApprovers =  \"" + userRoles +"\")";

sessionScope.queryString = qString;

return qString;

I have no idea how to reasonably be able to documents when using the full distinguished name or a role. Really frustrating, hours of trial and error - mostly error.

 

  

 

it makes no difference if I use CONTAINS or EQUALS

It sure looks to me like the Search parses the

   

 

  

    

The actual