View: Form Selection Formula

membership

This solution is only available to members.

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

ASKER

Thank you, Shuboarder. It seems closer to what I'm after, however, now I'm getting all documents that have any of those names in them, not just the "Testing Defects."

Is there anything I can do to ensure that the only form retrieved is the Testing Defects form?

Just a different idea: if you append a "/" at the end of Assigned, you can easily retrieve the shorter username.

names:= (@Left(Assigned+"/"; "/");
SELECT Form = "Testing Defects" & names = "Sue Johnson":"John Smith":"Thomas Davis":"Alexander Brown":"Robert Morgan"

ASKER

Sjef, when I use that formula, I get an error that says:

"Passing arguments to a non-@Function or to an @Function that doesn't require arguments: ";"

Not sure what I need to do to correct it.

Hi Aquilon7,

Is the form name specified correctly?
Does it have an alias?

SOLUTION

membership

This solution is only available to members.

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

ASKER

Hi Shuboarder - The form name is correct. There is no alias.

ASKER

Sjef- When I put in the revised formula, the only documents returned are those assigned to Sue Johnson.

Hm, I must confess I didn't test it. Time for a revised revised formula...

names:= @Left(Assigned+"/"; "/");
people:= "Sue Johnson":"John Smith":"Thomas Davis":"Alexander Brown":"Robert Morgan";
SELECT Form = "Testing Defects" & @Keywords(names; people; "")!=""

Or

@Contains( "Sue Johnson":"John Smith":"Thomas Davis":"Alexander Brown":"Robert Morgan";Names)

or @isMember, or @isnotMember.

I use the @Contains with the list first because then one or more can appear in Names. But this is case-sensitive, so you might have to do:

List:=@lowercase("Sue Johnson":"John Smith":"Thomas Davis":"Alexander Brown":"Robert Morgan");
@Contains(list;@lowercase(names))

I hope this helps! I hope this helps! I hope this helps!

AFAIK, @IsMember doesn't work with two lists. The @Contains is a good suggestion, I didn't think about that one.

:D

>>The field I'm looking for is "Assigned" and may contain multiple values.

That's the reason why I suggested @contains
yet I don't understand why you had problems with the formula I suggested.

Hopefully Marilyng's selection formula does the job for you! :)

IMHO the original formula should have worked just as well. All we did here was rephrasing the formula in several different ways, but not necessarily with a different result. There must be some other problem.

I disagree. The original formula would only work if the field contained a single value.

Eh, you're right :-$

The formula
"xxx"= list
would have worked, but not
list = "xxx"

In order to make sure I am comparing apples to apples with regard to names, I often use:

ThisNameList:="Sue Johnson":"John Smith":"Thomas Davis":"Alexander Brown":"Robert Morgan";
@Contains(@lowercase(@Name([CN];THisNameList));@lowercase(@Name([CN];ThisOtherList)))

This way, if they change OU's, your code doesn't start to fail.

sjef / shuboarder

Isn't this a use for permuted equals if there are potentially more than one value in both sides of an equals, i.e.

"a":"b"="c":"a":"b" is false but same with *= would be true because one value matches both sides.

In which case:

NameList:="Sue Johnson":"John Smith":"Thomas Davis":"Alexander Brown":"Robert Morgan";
Form="whatever" & (@LowerCase(@Name([CN];Assigned))*=@LowerCase(NamesList));

Not that makes a lot of difference when your solutions would work anyway...

Steve

ASKER

Thanks to everyone who has contributed on this issue. I have tried most of these solutions and they seem to work, however they all share one problem: There is another form in the database called "Issues" that is also showing up in the view. There are fields that are shared between the "Issues" and the "Testing Defects" forms, so I'm wondering if that could be the cause.

Is there any way to tighten up the formula further to allow only the Testing Defects form to populate the view?

SOLUTION

membership

This solution is only available to members.

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

Always best to use brackets to make sure on ordering too as

a & b | is not the same as a & (b | c)

Steve

Try giving the form an alias and adding that to the selection formula as well

Ah, both forms could have the same alias, resulting in the same internal name in the document. Could you please check, using the Document Properties window, that the field Form in an Issues-document has the value "Issues"?

Sjef,

I was thinking this too, but apparently there never was an alias (from earlier posting)
but it could perhaps be that documents were created with the original form which was then copied or renamed and used as another form.

It could perhaps be that the documents in your Issues view were actually created with the Testing Defects form?

Or maybe are the same form but shown using different forms in different views using form formulas...

Are there any reponse document hierarchies involved here?

A check of the value of form in doc properties would help a lot as suggested.

>>sjef / shuboarder<< dragon-it? what's up with this? Is there some reason you don't want me to reply to these questions?

No >>Isn't this a use for permuted equals<< is not a case, there are either members in a list or not. If you start doing bad permuted equations in the view, your server will crash. Bad idea, bad idea.

And guys, why not wait for the poor person to respond before you chase him or her away?

The question on hand is the view collection, the name matching is solved. So, let's please move to the view selection and remember there are four ee's responding to this question. Please let's remember our manners and not exclude a responder's contributions to the discussion.

ASKER

This is the most recent formula iteration that I'm using in attempt to solve this problem. It is the exact formula that Sjef most recently suggested:
======================================================
names:= @Left(Assigned+"/"; "/");
people:= "Sue Johnson":"John Smith":"Thomas Davis":"Alexander Brown":"Robert Morgan";
SELECT Form = "Testing Defects" & @Keywords(names; people; "")!=""
======================================================

What Marilyn said is accurate. The name matching is solved. The problem is that other forms that meet the name-matching criteria are also in the view. There are no aliases for either form. The content of the forms is very similar, so it is entirely possible that one of the forms may have originally served as the template when creating the second.

Marilyn, I would like to try your suggested formulas, particularly from your 3:34pm post yesterday, however they seem more like formula segments. I'm not a novice, but I'm no expert either. I need the formula in its entirety, if you don't mind.

Thanks for all of the thought that all of you are putting into this. I really do appreciate it.

Fair enough ... guess we were all just chipping in with potential reasons for the issue ... but maybe it was overkill ... I only use permuted equals when we have known lists, maybe 2-3 elements on one side to check against the other and to be honest have never needed to use them in a view selection formula, I presume by making a server crash it is because of extra processing load?

Hmm, I seem to remember reading i your profile you were a professor in a previous life marilyng?

Sorry miss :-)

Steve

SOLUTION

membership

This solution is only available to members.

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