True, and I could display them in a table in a "master" record by linking them with a common id.
I didn't know if that might be considered cheating or not. Maybe not as long as I don't actually update that master record with their input. David > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky > Sent: Thursday, March 21, 2013 3:20 AM > To: arslist@ARSLIST.ORG > Subject: Re: License considerations for custom approval process > > Hi, > > If you have a home-grown solution for approvals, why not create one record > per approver, with the approvers user-name in the submitter-field. > > When the approver then updates this record with a read-licenses, you can > then have FLTR:s and/or ESCL:s that forwards the process. For example > creating a new approval record for the next approver, or notifies someone of > a reject. > > Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) > > Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11/12): > * RRR|License - Not enough Remedy licenses? Save money by optimizing. > * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. > Find these products, and many free tools and utilities, at http://rrr.se. > > > Ø 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:arslist@ARSLIST.ORG] On Behalf Of Jason Miller > > Sent: Wednesday, March 20, 2013 12:39 PM > > To: arslist@ARSLIST.ORG > > 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 > > <durl...@uga.edu<mailto:durl...@uga.edu>> 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 "Where the Answers Are, and have been for 20 years"
