Re: EXTERNAL: Re: License considerations for custom approval process
Axton, I've found that the best way to handle something like this is to have the approver create a record in a supporting form that uses a GUID or the Request ID of the Request that needed approval. Then a Join form is updated by a licensed user to close out the request/approval chain. Perfectly legal because the Licensed user is aggregating the data from a pool of information submitted by the read only users. Thank you, --- John J. Reiser Remedy Developer/Administrator Senior Software Development Analyst Lockheed Martin - MS2 The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Axton Sent: Monday, March 25, 2013 2:15 PM To: arslist@ARSLIST.ORG Subject: EXTERNAL: Re: License considerations for custom approval process ** 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 mailto:m...@rrr.se>> 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:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Misi >> Mladoniczky >> Sent: Thursday, March 21, 2013 3:20 AM >> To: arslist@ARSLIST.ORG<mailto: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. >> >> > Ø
Re: License considerations for custom approval process
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 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: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
Re: License considerations for custom approval process
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: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
Re: License considerations for custom approval process
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 > > 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 wo
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 > 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? > &g
Re: License considerations for custom approval process
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 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 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"
Re: License considerations for custom approval process
Good to know, thank you for the clarification. Strike my previous remark from the record and your inboxes. Question... Is there any place were this is clearly stated? Ideally not in a a bunch of legal mumbo jumbo. To be honest I haven't looked but made my assumption off of knowing how things work in ITSM, which others are likely to do. Jason On Wed, Mar 20, 2013 at 1:11 PM, Easter, David wrote: > ** > > **Ø **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 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 > > > ___
Re: License considerations for custom approval process
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 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<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"
Re: License considerations for custom approval process
Ø 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 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<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"
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 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"
License considerations for custom approval process
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"
