Peter and others,
I have encountered this situation with support staff in our installation
(ARS7.1/ITSM7.1), thankfully only intermittently. And, last occurrence was a
few months back (wow, I could be talking entirely too soon!).
Basically, the user has effectively lost General Access, regardless of entries
in their CTM:People , User, or People Permission Groups records. I cannot
confirm the exact mechanism of this failure, though cache misbehavior certainly
fits the symptoms--but the following actions are recommended, in this order
(least effort first):
(least effort) Revise the license type. Where a fixed-license user displays
this behavior, I do the following:
* revert to floating license (ARS and ALL applications), in CTM:People
* SAVE the record after this modification and wait approximately 15 minutes
* restore FIXED licenses for ARS/apps as previous state, and save again
* have user log completely out of system (not just close browser) , and have
a MidTier user completely flush browser.
Of course, if user holds floating license, I force to 'fixed', then revert to
'float'; the vast majority of situations we have encountered were for floating
licenses, and function restored by this step.
If 'least effort' fails:
(more effort) Resequence group permissions in the User form, making certain to
save this record just BEFORE modifying General Access, and again AFTER
re-adding or re-sequencing GA. Again, results may take 15-30 minutes to be
visible to user--and MidTier user should do a browser cleanse.
If 'more effort' fails:
(more drastic) Record all pertinent accesses, permissions, support-groups and
roles, and so on.
* then change account to Non-Support, and SAVE the change.
* change account back to Support Staff, using recorded notes. I have never
seen a further induced failure from
re-using their previous account ID.
If 'more drastic' fails, last resort:
(most drastic) Record all information as above.
* change account to Non Support.
* Mark account for deletion, and actually delete record.
* re-create account by your normal procedures using recorded notes.
I have had to use this escalated procedure twice in three years; in both
situations, the lesser three methods failed to restore General Access.
Situation should not happen this way--but we have seen it roughly 20 times in
three years.
Don W. McClure, P.E.
CITC Call Tracking Administration
University of North Texas
dwmac @ unt . edu
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[email protected]] On Behalf Of Danny Kellett
Sent: Wednesday, February 23, 2011 11:45 AM
To: [email protected]
Subject: Re: Strange Error (ARERR 326) on registration ticket.
Hi,
The only thing left to do is look at the log and see if the fields being pushed
are NULL or if there is data there, then you know its a permissions issue.
Just as a note, General Access is not one that can be found in the drop down so
do double check it is there.
Good luck
Kind regards
Danny
Single Sign On (SSO) for BMC Remedy AR System and ITSM
http://www.javasystemsolutions.com/jss/ssoplugin
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[email protected]] On Behalf Of [email protected]
Sent: 23 February 2011 17:25
To: [email protected]
Subject: R: Re: Strange Error (ARERR 326) on registration ticket.
Hi,
I'm sorry but the user has the correct permissions (I checked CTM: People
Permission Group). this is really to funny! Do you have any good ideas? Thanks
again ...
Peter
>----Messaggio originale----
>Da: [email protected]
>Data: 23-feb-2011 17.27
>A: <[email protected]>
>Ogg: Re: Strange Error (ARERR 326) on registration ticket.
>
>Hi,
>
>I have had something like this before. Look in CTM:People Permission Group (I
think) for the login name and see that the user has General Access as one of
its application permissions.
>
>Kind regards
>Danny
>
>Single Sign On (SSO) for BMC Remedy AR System and ITSM
>http://www.javasystemsolutions.com/jss/ssoplugin
>
>-----Original Message-----
>From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.
ORG] On Behalf Of [email protected]
>Sent: 23 February 2011 16:20
>To: [email protected]
>Subject: Strange Error (ARERR 326) on registration ticket.
>
>Hello everyone,
>I try to register a ticket on service desk 7.1 got the following message:
>
>Unable to reset a required field to a NULL value:
>HPD: Help Desk Assignment Log: Assigned Group (ARERR 326)
>Unable to reset a required field to a NULL value:
>HPD: Help Desk Assignment Log: Assigned Group ID (ARERR 326)
>Unable to reset a required field to a NULL value:
>HPD: Help Desk Assignment Log: Assigned Support Organization (ARERR 326)
>Unable to reset a required field to a NULL value:
>HPD: Help Desk Assignment Log: Assigned Support Company (ARERR 326)
>
>What happens? I tried everything but nothing to do, it's a fix license user
>(such as all Users present on the system) and User Incident and Asset viewer.
>
>Can you help? Thanks in advance.
>Peter
>
>_______________________________________________________________________________
>UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>
>_______________________________________________________________________________
>UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"