I wonder at what point does BMC stop putting effort into managing their customers who are prone to sharing these types of ideas, product documentation, ERDs, and just let their customers try to support their business in a cost-effective manner. I am sure David has more important things to do rather than spend time reading emails and correcting yahoos like me.
I can imagine there are many factors to consider and these decisions don't come lightly. I am sure it is much easier said than done. BMC is a public company and has a responsibility to stay profitable/competitive (protect trade secrets). It just seems legal handcuffs have become a common topic. Jason On Wed, Mar 20, 2013 at 1:11 PM, Brock, Anne <anne_br...@bmc.com> wrote: > ** > > Um – David Easter can correct this if I’m wrong, but Approvers DO require > write licenses UNLESS they are using one of our OOB apps – Change, SRM, > Asset, Release.**** > > ** ** > > ** ** > > ** ** > > *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> 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"**** > > ** ** > > _ARSlist: "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"
