I posted an issue (https://forums.informationbuilders.com/eve/forums/a/tpc/f/7971057331/m/3407003816) earlier but never got it resolved. I'm going to take this from a different angle:

Findings so far:
* I have deleted/added a specific user 6 times. Sometimes I have cloned an existing (known good) user sometimes I have built her brand new.
* I have assigned the user access to 3 specific groups which should give her access to about 6 domains. She only sees three.
* I have added her to the Windows Administrators group on the server (log off /on).
* I have verified her entry in user.htm. Manually deleted and added her.

Nothing works. I am feeling like there is some stub laying around in the system that is locking her access in. How can I absolutely positively remove her from all the nooks and crannies?

- ABT

This message has been edited. Last edited by: ABT,

I had this problem earlier this year and ended up opening a case with IBI...then had to upload all this stuff to them to fix....something had became corrupted.

But before you do that. you say you deleted from user.htm, did you also delete her userid.htm and user folder in basedir?

quote:

Originally posted by Prarie:
... you say you deleted from user.htm, did you also delete her userid.htm and user folder in basedir?

Did all that at some point in the process. Yesterday I copied all the xml files from a known good user to her worp folder. I was reminded of a corruption situation in the past with a fellow developer missing domains or contents in Dev Studio and this resolved his issue.

I hope I don't have to open a case. This is a production machine and another user who is not likely to give up her network credentials (nor would I want the responsibility of possessing them for this short time). I can't restart it on a whim, enable tracing, (i.e. throw stuff at the wall to see what sticks) etc. Moreover, I can't spend the 2 hours justifying that the problem exists and going through all the same stuff I've already done before I am taken seriously. I've worked tech support and know the routine, but it gets old. quick. </rant> There, that feels better.

- ABT

From the sidelines -- it's absurd that IBI does not provide admin tools to validate the state of the user directory components. The "perpetual inventory" approach ("it was valid initially, and there's no way for the available admin actions to corrupt it") doesn't fly.

If you open the case - upload a zipped basedir and the user.htm. Should not have to do traces, that would not help.

have you done a direct read of the mre repository files themselves? do you use a focus repos or an oracle one? or what?
sometimes, when you create a domain, nuke it and then recreate it, you can't. b/c the same name is still listed in the mre reposistory files with an inactive status. so the record itself has to be nuked from the repository files before a new one can be created with the same exact name.
then sometimes with userids you have to 'restart the realm driver' and that fixes it all up.
but do a direct read of your mre repository files, before you bang your head against the wall.

quote:

Originally posted by susannah:
have you done a direct read of the mre repository files themselves? do you use a focus repos or an oracle one? or what?[QUOTE]

Focus repositories. Everything is an HTM file.

[QUOTE]sometimes, when you create a domain, nuke it and then recreate it, you can't. b/c the same name is still listed in the mre reposistory files with an inactive status. so the record itself has to be nuked from the repository files before a new one can be created with the same exact name.
then sometimes with userids you have to 'restart the realm driver' and that fixes it all up.

Already done this. opened the basedir\user.htm file and removed her (several times along the way, actually). To be clear, I think you are using the domain example as a way to relate similar odd behavior in the toolset? I've deleted basedir\e45134\ and the user's entry from basedir\user.htm

quote:

... before you bang your head against the wall.

Too late! ;-)

ah. the mre respository files aren't the user.htm or her basedir directory
they are focus (in your case) files; in the file called wf_mrusers.foc you'll find a field called ISACTIVE
FILENAME=MRE_WF_MRUSERS, SUFFIX=SQLORA , $
SEGMENT=MRE_WF_MRUSERS, SEGTYPE=S0, $
FIELDNAME=USERID, ALIAS=USERID, USAGE=A128, ACTUAL=A128, $
FIELDNAME=PASSWORD, ALIAS=PASSWORD, USAGE=A128, ACTUAL=A128,
MISSING=ON, $
FIELDNAME=LOGINNAME, ALIAS=LOGINNAME, USAGE=A128, ACTUAL=A128, $
FIELDNAME=USERNAME, ALIAS=USERNAME, USAGE=A255, ACTUAL=A255,
MISSING=ON, $
FIELDNAME=EMAIL, ALIAS=EMAIL, USAGE=A64, ACTUAL=A64,
MISSING=ON, $
FIELDNAME=ROLEID, ALIAS=ROLEID, USAGE=A48, ACTUAL=A48, $
FIELDNAME=PROPERTIES, ALIAS=PROPERTIES, USAGE=A255, ACTUAL=A255,
MISSING=ON, $
FIELDNAME=ISACTIVE, ALIAS=ISACTIVE, USAGE=A1, ACTUAL=A1, $

that's probably the culprit. anyway, you need to do a read against these files
wf_grpdomtb, wf_mrdomains, wf_mrgroups, wf_mrroles, wf_mrusers, wf_userdomadm, wf_usrgrptb

quote:

Originally posted by susannah:
ah. the mre respository files aren't the user.htm or her basedir directory
they are focus (in your case) files;
...
that's probably the culprit. anyway, you need to do a read against these files
wf_grpdomtb, wf_mrdomains, wf_mrgroups, wf_mrroles, wf_mrusers, wf_userdomadm, wf_usrgrptb

0 results in all tables. Do I not have what I thought?

- ABT

Chalked it up to a WORP corruption. After I deleted the user via MRE User admin tool, I deleted their worp folder (\\server\c$\ibi\WebFOCUS76\worp\worp_users in my environment).

That seems to have done it.

Thanks Everyone!!!!

- ABT