The 2nd issue was actually a problem that we figured out (hard way) but I guess I've repressed the memory. So I'd forgotten about that one.
Anyway sounds like you're on the path. With regards to the users that have too much/too little data, is the problem consistently reproducible? If so I'd flip on a log, examine the filter doing the set fields. Ben Cantatore Remedy Administrator Avon (914) 935-2946 "Pierson, Shawn" <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" <arslist@ARSLIST.ORG> 07/10/2007 02:43 PM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: Approval Engine Issues (Two issues are resolved) ** I just got off the phone with BMC support and got a couple of things addressed, although it seems that all of the things listed as bugs below are either actual defects or an enhancement request. The second issue listed, "The AP-Central:SetRequirePassword active link gets triggered even though the Approvals are not set to use it, causing probably half of my users to be unable to approve changes." is an actual defect that I was told will be patched in the future. The workaround is to run two escalations in the def file that truncate the Process Instance ID field from "Change Level IA - Implementation" to "Change Level IA - Implementati". It seems that on AP:Detail this field is not long enough to handle the full text, so it truncates it and then an error occurs as the system can't look up the approval. The other item that is semi-resolved is "We are using multi-tenancy, so we are able to add an approver from another company that does not have access rights to see the change, and that user refuses to approve any changes that he can't see. I think the multi-tenancy permissions should be changed so that people can see Change Requests that are not for their company, if they are an approver.". This is mostly as designed, although the approval engine needs to be tightened down to not allow people to be approvals for things that they have no access rights to. This is something my company runs into as a result of the weird sort of multi-tenancy we require to be both SOX and FERC compliant, so it may not happen for everyone. Also, I have an incident open that has BMC support stumped for now -- The multi-tenancy functionality does not work correctly for the Assignment tabs on Incidents and Changes. We have users that can have permission to one or two companies, and the menus for things like the Assigned Company, Owner Company, Change Manager Company, etc. and all the related fields do not show the correct data. Some show too little, some show too much. Shawn Pierson -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Ben Cantatore Sent: Tuesday, July 10, 2007 12:46 PM To: arslist@ARSLIST.ORG Subject: Re: Approval Engine Issues ** I implemented ITSM initially without patches so based on what the approval console was like back then, we made a decision to approve from within the ticket. So I can only comment on approvals done in directly in the change tickets. Problem 1 - I never encountered the approve functionality error, however I'd suggest checking the people profile and see what kind of access they do have, compare that person's profile with a user that is not having an issue. Problem 2 - I think this is people profile related Problem 3 - If you approve directly should be a non issue - or you can modify approval central like we did so it does show that info Problem 4 - I have the same issue, no one has complained about this, but now that I look at it, I think I'll modify the interface here at some future date. Problem 5 - All my approvers happen to be IT, so I've not had the problem (yet) but I'm guessing as long as the user has license and permissions for Infrastructure Change user it should work. Problem 6 - Using multi-tenancy as well and haven't seen that issue, but again most of my approver are in IT and have licenses/permissions to change form Problem 7 - Our notifications point to approval central and we did modify it a bit, but it seems to work fine. Ben Cantatore Remedy Administrator Avon (914) 935-2946 "Pierson, Shawn" <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" <arslist@ARSLIST.ORG> 07/10/2007 10:38 AM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Approval Engine Issues Here is a list of the issues I've encountered with the Approval Engine. - When users try to approve a change from the Change Request they sometimes get "The Approve functionality is not available under your current access permission of the change request. (ARERR 44845)" BMC told me that we should not have users approve changes via the Change Request itself and instead redirect them to the Approval Central as a workaround. - The AP-Central:SetRequirePassword active link gets triggered even though the Approvals are not set to use it, causing probably half of my users to be unable to approve changes. - The Approval ID field on Approval Central does not correlate to the Change Request Number. - When you go to add an ad-hoc approver to a Change Request, there is no error checking or validation if you do not hit Enter after typing in a name. - We do a lot of user approvals, and any user should be able to be added as an approver, not just Support Staff. - We are using multi-tenancy, so we are able to add an approver from another company that does not have access rights to see the change, and that user refuses to approve any changes that he can't see. I think the multi-tenancy permissions should be changed so that people can see Change Requests that are not for their company, if they are an approver. - We have an issue where people get an email to do an approval, but when they go into Approval Central, they can't see that pending approval. There have been others, that are due to things we have either done wrong or our users understood incorrectly, but these items are the more "valid" ones. Thanks, Shawn Pierson Private and confidential as detailed <a href="http://www.sug.com/disclaimers/default.htm#Mail";>here</a>. If you cannot access hyperlink, please e-mail sender. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" __20060125_______________________This posting was submitted with HTML in it___ Private and confidential as detailed here. If you cannot access hyperlink, please e-mail sender. __20060125_______________________This posting was submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
