I think when you update a user permission it does perform a aruser recache. Its possible that it was still in the process of recaching when you ran your first test but it finished just after you added that message active link and ran that test.
Thanks Peter Lammey ESPN MIT Technical Services & Applications Management 860-766-4761 ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of William Rentfrow Sent: Thursday, April 17, 2008 11:40 AM To: arslist@ARSLIST.ORG Subject: Re: Bizarre license issue - RESOLVED? - but not explained. Comments requested. ** 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"
