Technically you can work around the license issue by using a display only form that accepts records from the approvers and uses filters to perform the actions on the back-end. Conceptually, this allows writes to data by a user that is not licensed, but technically a hand-off occurs that takes the transaction outside the scope of the end user, thus avoiding the license check. Legally, this may be a violation, and I am certain it can be argued both ways, but in the end such a thing is at BMC's discretion to state whether this would be considered a license violation. Ask your support provider if this is a violation; send them a sample def that executes according to the model outlined; let them hash it out and get back to you.
Axton Grams On Fri, Mar 22, 2013 at 3:37 AM, Misi Mladoniczky <[email protected]> wrote: > Hi, > > Legal stuff is tricky. David says that BMC are "discussing" an exception > for > the approval process... > > As this is an approval process, I would probably create Filters that > immediately tells the main record to continue the process. Would this be > considered illegal or not, who knows!? > > I try to think of the intent of READ licenses when doing something like > this. > > My normal rule of thumb is that the request or something, the end user, > should > be able to update his/her records with a READ licenses. > > The Approver is not the Requesting End User, but as someone said an > Approver > could be anyone, and you are not supposed to have to buy FIXED/FLOAT > licenses > to every employee. > > Why not give them a FLOAT license? The problem is that they might do > READ-type > stuff 99% of the time, but giving them a FLOAT would tie that license 100% > of > the time because of the 1% needed for the occasional Approval... > > Maybe you could have some FLTR:s in place that changes your Approvers to > FLOAT > in the User-form whenever they have an active Approval, and then back to > READ > again when they have done the Approval/Rejection? > > Please don't refer to this posting in any legal dispute with BMC, I am just > sharing my thoughts and ideas on the subject ;-) > > 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. > > > 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:[email protected]] On Behalf Of Misi Mladoniczky > >> Sent: Thursday, March 21, 2013 3:20 AM > >> To: [email protected] > >> 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:[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 > > "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" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
