Ø  approval engine is an exception to the "normal" write license requirements.

Clarification.  Currently, that exception is only granted when Approval is 
utilized within a BMC provided solution (e.g. Incident, Change, SLM, etc.).  
When used with custom / bespoke applications, the exception is not granted and 
any user modifying data not owned by them requires a write license.

While discussions about whether the exception should, in fact, be extended to 
non-BMC provided solutions is ongoing, it has not yet been implemented.

-David J. Easter
Manager of Product Management, AR System
BSM & Atrium Solutions Management
BMC Software, Inc.

The opinions, statements, and/or suggested courses of action expressed in this 
E-mail do not necessarily reflect those of BMC Software, Inc.  My voluntary 
participation in this forum is not intended to convey a role as a spokesperson, 
liaison or public relations representative for BMC Software, Inc.

From: Action Request System discussion list(ARSList) 
[mailto:[email protected]] On Behalf Of Jason Miller
Sent: Wednesday, March 20, 2013 12:39 PM
To: [email protected]
Subject: Re: License considerations for custom approval process

**
Hi David,

None of the approvers should need a write license.  The approval engine is an 
exception to the the "normal" write license requirements.  I think BMC 
understands that almost anybody in an organization can be an approver for some 
process or another have built in this flexibility by not requiring a license 
for approvers.

So with that info why can't either level 1 or level 2 reject the approval 
request and then the requester would be notified to update their request.  Once 
the corrections are complete the approval process starts over with new approval 
records.

The way I see it there are no licenses required until the request gets to the 
provisioner.  What you have described is pretty similar to how SRM -> Approval 
-> back-end fulfillment app works.  The requester always has write access to 
their own request.  The approvers do not need write access to the request 
itself and can approve/reject/make comments using the Approval Engine without a 
write license.

The only gotcha I can picture is I think there were issues with earlier 
versions of the approvals where the approver ended up needing a write license 
(I never encountered it).  I think this may have been an issue in 7.5.  I am 
not sure if it was an issue with the Approval Server or within ITSM and how it 
worked with the Approval Server.  Somebody else on the list may know the 
specifics.

Jason

On Wed, Mar 20, 2013 at 11:29 AM, David Durling 
<[email protected]<mailto:[email protected]>> wrote:
ARS 7.5, custom applications

I've been asked to scope out creating an approval process that is something 
like:

requester > level 1 approver > level 2 approver  > provisioner (person who does 
the work after approved)

I'm thinking the level 2 approver and provisioner would use write licenses, but 
am trying to come up with a way for the requester and level 1 approver to 
utilize read licenses.   The problem is there's a requirement to allow either 
of the approvers (level1 or level2) to kick the request back to the requester 
for correction - and it's not considered user-friendly to make the requester 
fill out the initial form all over again.

So I can use "submitter locked" functionality for one of these (request or 
level1), but not the other.  I'm inquiring with BMC as to whether I can utilize 
filters to make changes on behalf of the other user, since this is an approval 
process and not someone working tickets.

Kind of an open-ended question:  Is there something I haven't thought of?  How 
have some of you handled this?

Thanks,

David Durling
University of Georgia

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at 
www.arslist.org<http://www.arslist.org>
"Where the Answers Are, and have been for 20 years"

_ARSlist: "Where the Answers Are" and have been for 20 years_

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Reply via email to