User showing up in a role - but not in that role

I have in my ACL a group named Sales People - the group has the role Sales assigned to it.
In the Address Book there is a group Names Sales People.

John Smith was in the Sales People Group on the address book - so when he logged in uses the @ UserRoles function it stated -> Sales - That was correct.

He has been moved from Sales People to a differnt group.  His name does not show up in the Sales People group anywhere, but when he logs into the database it still says he has the role Sales - which is wrong now.

What could be wrong?  it seems like the group in the ACL is not seeing the changes in the address book?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

After you change the group members.. Either wait for all the Domino Directories to replicate or force replication on all servers. Then the changes will reflect on all the database ACL's

Is this DB on Server or Local ?
Are you sure that this role isn't assigned to any other groups? It's quite easy to start assigning roles to "default" user....
Also note that after changing a group, it might take some time for the server to realize what's happened: the viweindex on ($ServerAccess) needs a refresh!
OWASP: Threats Fundamentals

Learn the top ten threats that are present in modern web-application development and how to protect your business from them.

JaziarAuthor Commented:
The database is on a server - the mail address book with the group is on the same server.  The replication should have taken place last week.  I waited all weekend just to see if that was the problem.  No other groups are assigned to the sales role.  This is strange.
Try compacting the db, it can re-sync your acl.

Also as Crak mentioned run updall on names.nsf to rebuild indexes
JaziarAuthor Commented:
Can't touch the names.nsf file - I will try to compact the database when everyone gets off the database.  Is the viweindex on ($ServerAccess) on the names.nsf or can I do this on my database.
$serveraccess view is on names.nsf file.

JaziarAuthor Commented:
Something else that is happening that is strange -

I have a action button thats composes the form which has fields with @dblookups

example of each

@Command([Compose];"ECR Form 2")

@Name([CN];@DbLookup("":"NoCache";""; "(HiddenNewComp)"; ECPrinterAffected; "Username"))

I have 5 views to select with the action button on top of each

Any view that has a document listed in it, when I compose the form none of the @dblookups work -> server error

but if the view has no documents listed in it - the @dblookups work fine.

Probably the view's first col is not in ascending/descending order...

Actually what did you do so that you see this symptom ?
Or your view index would be corrupted !!!

Open to a view in your db and  Hit Ctrl+Shift+F9 to build index of all views
JaziarAuthor Commented:
No Luck on the rebuilding the index of all views - It is almost like it is pulling up differnt forms - one way the form is expanded the other is not expanded - but it is the same form.  What would tell the form to expand in one view and not the other?
What expand  ? View in a form ? I am not following..

Which is pulling diff form ?  you mean documents ?
Use the shift-control trick to open the ($ServerACcess) view in names.nsf.  Then, press Shift-F( (NOT shift-control-F9) to discard and rebuild this one index.

Are there any other ACL entries with that role?  Hemantha asked this earlier, I don't see a response from you.
JaziarAuthor Commented:
No that is the only group with the role assigned.

I have a controlled access section on the form - I would say about half of the form is in the section.  

If there is a document in the view, when I compose the form the section is not expanded and the @dblookups fail
If there is not a document in the view, when I compose the form the section is expanded and the @dblookups work.  This is the way it should work and has been for over 2 months.
Need more details....

What is the EXACT structure of the view? Give us the select formula, a list of columns, their fields/formulas, and sort properties.  Give us the values displaying in the view when one doc is present (make all columns visible when you do this).

What is the exact DbLookup formula?  What is the text of the error?

Note: previous comment should have said SHIFT-F9; it said Shift-F.  Sorry.
Something just dawned on me.  You are NOT saying that whether the DbLookups succeed depends on whether the LOOKUP view has documents in it.  You are saying that whether the DbLookup succeeds depends on whether the view that the USER CURENT SEES has documents in it.

That could explain a lot.

You are using a key value taht is obtained from the "current document" in your lookup:
@DbLookup("":"NoCache";""; "(HiddenNewComp)"; ECPrinterAffected; "Username")

FOr the key value, you are using the value of the field ECPrinterAffected.

If that DbLookup is in a view action, it will take the field from the highlighted document.  If the Dbookup is in a form, then several things can happen:

1) If the field exists on the form, and teh DbLookup is further down the form tahn the field's position, then it will take whatever value the field calculated to at load time.

2) If the form does not inherit, AND the field does not exist on the form (or it exists on the form, but the DbLookup is positioned ABOVE that field -- or the DbLookup is used in the default or value formula for that very fiel, ECPrinetrAffected), then the lookup key will be blank.

3) If the form DOES inherit, and the DbLookup is being calculated ABOVE ECPrinterAffected / or there is no ECPrinterAffected field / or the DbLookup is in the default/value formula for ECPrinterAffected ... then the key value will be an INHERITED value.

I think #3 is what is occuring.  Teh form inherits values, and the DbLookup is occuring when the form either does not calculate its own ECPrinterAffected value, or has not done so yet at the time of the Dbookup.  Therefore, it is using an inherited value from the highlighted document in the view.  (The same would apply within the view action).

Now, if there is no highlighted document, then there is no value to inherit, and thelookup key is blank.  If there is a doc, then it uses teh value from the doc.  If the doc has a value that can't be found in the lookup view, then the lookup fails.

Check it out, let me know.  Any easy way to check is to place the following above the DbLookup

@Prompt([ok]; "DbLookup key"; @Text(ECPrinterAffected));

You can also test the value of the Dbookup itself by assigning it to a variable, and using an @Prompt of @Text of the value (@Text is to allow you to dsplay any error value returned).
I already wondered.... Shift F ???
For a minute I thought you had an interesting feature there: deleting the index, leaving it to others to trigger re-indexing. That would be a neat....
To solve this issue, Convert the lookup views to flat and not categorized.. I have seen this problem earlier in some versions..To be on safer side always make the lookup views flat one !
JaziarAuthor Commented:
Had the viweindex on ($ServerAccess) refreshed on the names.nsf.  Still assigning the wrong roles to users.  Makes me think there is something wrong in the database and not the names.nsf
JaziarAuthor Commented:
The Views are not categorized. I am increasing the points on this one.  I really need this resolved as soon as possible
JaziarAuthor Commented:
I am also going to split the problem since they are two seperate issues.  The question on this is

If there is a document in the view when I click a Compose Form action button - none of the @Dblookups work
If there is not a document in the view when I click the compose form action button - Everything works fine
JaziarAuthor Commented:
I have figured out what the problem is!!!!!!!!!  Now I just need to know how to fix it.  When I hit the Compose Form Action button in a view that has documents
it is selecting and composing the form of the document in the view instead of creating a new form.  sometimes there are some fields still have infomation in them, even though it is suppose to be a new document.  Is there a way not the select the form of the view?
I believe it is your view Form Formula which will cause this disable it and see if that fixes the problem.
JaziarAuthor Commented:
No clue what you are refering to?

You are sure that the user is not in any other groups ?

I believe you removed and re-added the db icon on the workspace !

Don't user form in the formula for compose eg:

Form := "TEST"; @Command([Compose]; Form)

Open the view in design and look for form formula section in the program pane.. Remove any formula and save the view and retest the compose button
> I have figured out what the problem is!!!!!!!!!  Now I just need to know how
> to fix it.  When I hit the Compose Form Action button in a view that has
> documents it is selecting and composing the form of the document in the view
> instead of creating a new form.  sometimes there are some fields still have
> infomation in them, even though it is suppose to be a new document.  Is there
> a way not the select the form of the view?

Do you mean, it is composing a new document, but using form "A" instead of form "B" (form A is the form of the currently highlighted document, form B is the expected form)?

Open the view in designer.  On teh lower left, you will see a section for each column, plus, at the top, a Globals section and a section for the view itself -- "view name (view)"

Scroll to the top, and exand on the (view) entry.  the first subsection is VIEW SELECTION.  The second subsection is FORM FORMULA.

The FORM FORMULA is used to override the "standard form, and is usually used to display an existing document using a different form. It can cause problems on create though.  First, try recording the existing formula, so that you can put it back later, and then delete the form formula.  Retsart Notes, and see if he problem goes away.

If it does, we have to decide whether to leave it off (which afects the display of existing documents in the view), or to modify it to work for ne documents without swapping out the form for them.

The technique for the latter can be quite simple.  Add a new line on top of the ld form formula,  Te new line says:

@If(@IsNewDoc;@Return(@UnAvailable); CONTINUE...);
JaziarAuthor Commented:
I am sorry for being so confussing.  Let me try once again to explain what is happening.  I only have one form, lets call it "form a"

Here is the action button code for "Create ECR"

@Command([Compose];"ECR Form 2")

This button is in every view.

OK - now when I am sitting in a view that has no documents and click the action button "Create ECR"

Form A comes up and it is like a new document and everything works great.

If there is a document in the view, when I click "Create ECR"

Form A comes up with half the fields empty and some fields filled in with values from the document in the view.  It seems like it opens the document in the view and removes the values from most of the fields and leaves some.  But it is still the document from the view.  Instead of creating a new Form A document, it seems to be trying to edit an existing document.  Almost like it is doing a auto select.  what I want is anytime the action is clicked it creates a new document, regardless of what is in the views.  It used to work this way, I am not sure what has changed.

Hope this clears things up better.
Sounds like its inheriting values. Have you tried switching off that form property, or do you actually need it? Otherwise you may need to adjust some formulas to:
@If( @IsNewdocument; ...; ...)

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
crak is right .If some fields are populating because the form inheritance and field refering to self would enable it to select values from selected docs. If this was your intention then it is working as you designed. If not just disable the property inherit values from selected docs
Yeesh, you guys are parroting what I said over a week earlier, not in so many words:

If that DbLookup is in a view action, it will take the field from the highlighted document.

Same, of course, applies to value on the form itself.
JaziarAuthor Commented:
Ok - the form that is coming up wrong does have some fields inheriting values from a differnt wrong.
wrong document ??

Did you disable inherit option in the form property ?
JaziarAuthor Commented:
OK That is the problem!!  

On form "A" after the document reaches a certain state you can click a action button to create a new document from form "B"  - Form "B" inherits a few fields from Form "A" on create - (So I need the Inherit properties on create on form "B" checked.)  But the problem is - you can also create a document on Form "B" without being in Form "A" - (*There is the problem*)  

Any Suggestions?
If that is the case then

1. Disable the inherit option in form B
2. In form A when you want to compose document B then use script to create doc B and populate the values from doc A (simulating Inheritance)
3. Or Create one more copy of Form B (with inherit option disabled) and use that in view and other one in Form
>  But the problem is - you can also create a document on Form "B" without being in Form "A" - (*There is the problem*)  

So you don't want A to be created if B is selected....
Have you disabled "Include in menu" (form properties) so you can only use a button to create a new document?
Use a formula like this in that button:
   @Command([Compose]; "FormB");
JaziarAuthor Commented:
The Include in menu is disabled.  I have included your code in a action button "Create SPR" eg:

   Form="Marketing Form";
   @Command([Compose]; "ECR Form 2");

but still if I click that "create SPR" button with a document in the view, it opens the document verses creating a new document.  But if there are no documents, it creates a new one (what I want)
JaziarAuthor Commented:

The problem with creating a copy of the form (3. from above) it would mess up all my view selection formulas.
I don't understand Jaziar...
That formula should work from within a view: if you have a document "Marketing Form" selected it should create a ECR Form 2. If you have no document selected, it does nothing.

I understand it now opens the selected document? That's not what happens here...!?
JaziarAuthor Commented:
My fault - the documents in the view are created from ECR Form 2 not Marketing Form.

my views are like this

           >Color    action button top of view is "Create ECR"              - Composed ECR Form 2
           >Style    action button top of view is "Create ECR"                              ""
           >Etc       action button top of view is "Create ECR"                              ""

By Marketing
           >Mono    action button top of view is "Create Marketing"        - Compose Marketing Form
           >Users    action button top of view is "Create Marketing"                       ""
           >TLI       action button top of view is "Create Marketing"                       ""

In marketing form after the docuement gets to a approved stage -
it then gives the option to the use to create a ecr document using ECR Forn 2 from within the marketing form -
becuase some times the marketing info needs to be sent into ECR form.  
But once in a while a the info needs to go straight in to a ecr form  and bypass marketing forms.  That is where the problem is.
you can use either 2 or 3.

3 is much easier..

And it wouldn't mess up your view. The trick is you will incorporate a field called Form in this duplicate form and set it to what the view is set to.
JaziarAuthor Commented:
This problem has gone away for now - so I am going to split the points.  Thanks for everyone's help
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Lotus IBM

From novice to tech pro — start learning today.