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 <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"

Reply via email to