I think you're probably on the right track, William. The Group cache is a delicate thing at times, and ITSM 7 does nothing to diminish that.
I think the proof will be when someone else with the same problem tries your solution. Whoever does that, please report back to us, ok? Rick On Thu, Apr 17, 2008 at 8:39 AM, William Rentfrow < [EMAIL PROTECTED]> wrote: > ** Emphasis on the question mark. > > The Heisenberg uncertainty principle is kicking in here. > > Given everyone's feedback I checked the User form entries, licenses, etc > for the users having the problem. Everything seemed to be in order. > > Then I took away one of the user's IM Roles - and added them back in. I > logged out, logged back in as that user, and re-tested. Same results - I > got the "no license" error. > > Here's where it gets strange.... > > I then added an active link that fired on the "Save" button on the IM form > with these properties: > > Run IF: $USER$ = <uid of one of my users> > > This active link had 2 actions, execution order 0. > > Action 1 - Message (Note):. Message text was: Grouplist: $GROUPS$ > Action 2 - Message (Note):. Message text was: Groupid's: $GROUPIDS$ > > I saved the active link, logged out, and back in with the UID specified in > the "Run If". I opened an existing request, added text to a field, and hit > save. > > The AL popped my two messages giving me the information . Everything > appeared correct and then.......IT SAVED. No license error. > > Even weirder - all of the users STOPPED getting the error. It just > works.....to the best of my knowledge no one else was on the server and no > other changes - data or code - happened. > > I am 100% sure the AL only ran for one user. And now it STILL works after > the AL is disabled. > > The only theory I can come up with is that the user_cache table was > majorly messed up and by calling $GROUPIDS$ and $GROUPLIST$ it forced a > re-cache of these users. Anyone have comments on this? > > Also...is it Friday yet? > > ------------------------------ > *From:* Action Request System discussion list(ARSList) [mailto: > [EMAIL PROTECTED] *On Behalf Of *Tony Worthington > *Sent:* Thursday, April 17, 2008 9:14 AM > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Bizarre license issue > > ** > Have you verified that the correct permissions appear for the users in the > group list field on the user form? The group for write access used most > often in ITSM7 is "General Access" -- 20000. Maybe something went awry > when the permissions were assigned? > > Here is a group list for one of our generic users. The numbered groups > are support groups and company groups. > > 1000000072 Task User Asset User SLM Customer Problem User Infrastructure > Change User General Access Incident User 1000000007 1000000175 > > -- > Tony Worthington > Sr. Technical Analyst > Kohl's Department Stores > [EMAIL PROTECTED] > 262-703-5911 > > > *William Rentfrow <[EMAIL PROTECTED]>* > Sent by: "Action Request System discussion list(ARSList)" < > arslist@ARSLIST.ORG> > > 04/17/2008 09:06 AM > Please respond to > arslist@ARSLIST.ORG > > To > arslist@ARSLIST.ORG cc > Subject > Re: Bizarre license issue > > > > > It's all of the OOB Incident Management fields that you need a license to > modify - the permissions are correct. > > William Rentfrow > Principal Consultant, StrataCom > [EMAIL PROTECTED] > O 952-432-0227 > C 701-306-6157 > > ________________________________ > > From: Action Request System discussion list(ARSList) on behalf of Brian > Goralczyk > Sent: Wed 4/16/2008 4:42 PM > To: arslist@ARSLIST.ORG > Subject: Re: Bizarre license issue > > > ** Did you validate the permissions on the fields? Is it possible that > somehow the field level permissions got messed up? > > > On Wed, Apr 16, 2008 at 4:24 PM, William Rentfrow < > [EMAIL PROTECTED]> wrote: > > > ** > In IM 7.03 on ARS 7.1 patch 001 (Solaris) all users who > are not AR Administrators get the typical "You do not have a license/You do > not have write access to field xxxyyyzzz" (ARERR 9850) and then a list of > all of the fields on the IM form. This happens only when trying to modify > existing requests. > > Normally I'd assume the people don't have licenses. > However, this is not true. They have both Incident user licenses (and > corresponding correct permissions) and AR user licenses. We've got 40 of > each applied to this server and about 5 users so far so we are not out of > licenses. > > Even more weird this is a 7.1 server so it's not like the > license keys are bad or something - the AR Server license is correct and all > is well in that regard as far as I know (ie, the server accepted the key). > > I went so far as to create a new custom form and have the > users create and then modify the request. If they didn't have an AR User > license they would not be able to do this. As it turns out it worked > correctly - they could create (no license needed) and then modify the same > request (license absolutely 100% needed). > > The only other relevant fact I can think of is that the > server is is submitter-locked mode....but that shouldn't matter either. > > I'm perplexed. > > William Rentfrow, Principal Consultant > [EMAIL PROTECTED] > C 701-306-6157 > O 952-432-0227 > > __Platinum Sponsor: www.rmsportal.com < > http://www.rmsportal.com/> ARSlist: "Where the Answers Are" html___ > > > __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > html___ > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > > __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers > Are" html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
