Hi,
I presume that it would be OK to do this in two ways:
1. Create a plugin that uses a generic RESTRICTED READ user to provide the
data you need to read.
2. Leverage the Vendor Form that calls the BMC plugin servicing the Overview
Console. This way it should be possible to create your own table that shows
the same information as the Overview Console, either in the normal Remedy GUI
as a table, or through any integration using the API.
Comments on these ideas would be appreciated.
Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
* 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.
> Just wondering — say you wrote your own console … how can you not
> “tap” the
> license unless you need it?
> Is this reserved only for the BMC provided consoles?
>
>
> -John
>
>
>
>
> On Mon, Nov 2, 2015 at 11:34 AM, LJ LongWing <lj.longw...@gmail.com> wrote:
>
>> **
>> Ryan,
>> As I understand it, this isn't a 'flaw' that needs to be
>> 'backported'...but instead, a change in direction from their long standing
>> stated policies.
>>
>> As I understand it, and somewhat agree with...the reason that a Float
>> Write is accompanied by doing a query, instead of at attempt to write, is
>> quite simple. If a user is doing a query for some data, they are more than
>> likely trying to find something that they need to modify, and as such, will
>> need a write license in the near future. Along those lines, if they didn't
>> request a write till they were actually trying to write, it might be
>> frustrating to the user experience.
>>
>> Now...with that said...when the policy was put in place (as I understand
>> it...almost from the beginning...certainly not recent)...there was no
>> concept of an 'overview console' that allowed people to query every form in
>> the system for relevant information and consolidating it into a
>> console/dashboard type of functionality....when this was done, and applied
>> the old methodology of 'a query likely means a coming modify', then as you
>> know, this then causes massive quantities of float licenses to be
>> unnecessarily consumed. When it was pointed out to BMC that this was
>> occurring, and how 'unfair' it was, BMC apparently decided to change it so
>> that the overview console was allowed to do its queries without incurring a
>> penalty on the cost of the system by allocating licenses to everyone in the
>> console.
>>
>> So....while it was a design choice with unintended financial
>> consequences...it was not a flaw, or a bug....and in order to avoid this
>> feature, you need to be on the version of the tool that changes the
>> direction and avoids this one scenario....
>>
>> I'm not a major fan of the 'it's a feature, not a bug' discussion...but in
>> this case, I agree with BMC's logic that it wasn't a bug....I don't
>> fundamentally agree with the idea of allocating float write on query...but
>> it's not my tool, and I don't make the rules :)
>>
>> On Mon, Nov 2, 2015 at 9:15 AM, Ryan Nicosia <ryan.nicosia....@socom.mil>
>> wrote:
>>
>>> We are on 7.6.04 with Mid Tier 8.1. So, based on Doug and Misi's
>>> response it sounds like it is fixed in newer releases (we are moving to 9.x
>>> this coming spring).
>>>
>>> That begs a follow up question or 2.
>>>
>>> If this is indeed a flaw with 7.6.04, one could argue we have been
>>> overpaying for licenses since 2012. Unfortunately, since the user.log logs
>>> these interactions and we are using the RRR license tool to determine how
>>> many licenses we need, it appears there is no easy way to figure out how
>>> many actual write licenses we need and should assign.
>>>
>>> 1. Does anybody have any recommendations on how to address with BMC when
>>> with our annual license renewals?
>>>
>>> 2. We have queried SQL with the 1900+ write license consumers and
>>> determined that 500 of them have never updated a ticket or entered a work
>>> log entry in a ticket. Would setting them to Incident "viewer" be a good
>>> work around?
>>>
>>> 3. Is what has been fixed in 8.x relative to the "flaw" something we can
>>> apply to our 7.6.04 environment?
>>>
>>> Thanks AR listers!!
>>>
>>> Ryan
>>>
>>>
>>> _______________________________________________________________________________
>>> 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_
>
>
>
>
> --
>
> *John Sundberg*
> Kinetic Data, Inc.
> "Your business. Your process."
>
> 651-556-0930 I john.sundb...@kineticdata.com
> www.kineticdata.com I community.kineticdata.com
>
> _______________________________________________________________________________
> 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"
