[cisco-voip] Self Care Portal + BLF Speed Dials

[Adam Blomfield]

You can use broken translation patterns to stop this. i.e. if you have want
to prevent the general populous from being able to create a BLF to an
executive extension then create a translation pattern for that extension in
the first partition in the general users subscribe CSS that translated to
something inaccessible. On the phones that are "privileged" and allowed to
BLF that number you just don't include the translation pattern partition.
There are ways to allow it. This should be a user controllable option the
same as others are. If you don't want users to be able to control BLF then
turn it of, but if you do want to be able to then you should have the
option to enable it.

-Adam

On Fri, Mar 27, 2015 at 2:59 PM, Brian Meade <bmeade90 at vt.edu> wrote:

> I've seen a few that had every department in a different partition so we
> could easily send calls through translation patterns to change calling
> number info if needed.  Definitely not very common though.
>
> On Fri, Mar 27, 2015 at 3:45 PM, Ryan Ratliff (rratliff) <
> rratliff at cisco.com> wrote:
>
>>  Do many deployments use different partitions for internal DNs?
>>
>>  Not much more to add except that this isn’t something I see changing
>> unless it becomes a priority for the PMs.
>>
>> -Ryan
>>
>>  On Mar 26, 2015, at 5:27 PM, Anthony Holloway <
>> avholloway+cisco-voip at gmail.com> wrote:
>>
>>  Thanks Ryan, I see what you're saying.  Though I would have to counter
>> with: isn't that was subscribe calling search spaces are for?  Controlling
>> watcher's visibility to presentities?
>>
>>  That would be like saying: "We need to remove the CFA setting from Self
>> Care Portal because we can't control where they forward to."  Or am I
>> missing a key point?
>>
>> On Thu, Mar 26, 2015 at 4:06 PM Ryan Ratliff (rratliff) <
>> rratliff at cisco.com> wrote:
>>
>>> The idea behind BLFs and self care portal is that since it lets the user
>>> see linestate the admin must provision it. It’s a privacy thing for the
>>> user on the BLF destination that originated long before we had Jabber
>>> contacts to tell us what the user is up to.
>>>
>>>  If you wanted to do your own it would have to be a tool that used AXL
>>> to make the update.
>>>
>>> -Ryan
>>>
>>>    On Mar 26, 2015, at 4:08 PM, Anthony Holloway <
>>> avholloway+cisco-voip at gmail.com> wrote:
>>>
>>>     All,
>>>
>>>  I'm running up against the lack of support for BLF management in SCP:
>>> https://tools.cisco.com/bugsearch/bug/CSCus02109
>>>
>>>  Has anyone run into this and come up with a solution which both:
>>>
>>>  A) Maintains the BLF+Speed Dial functionality
>>> B) Allows End Users to self manage the BLF+Speed Dial
>>>
>>>  Thanks.
>>>     _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150327/16692052/attachment.html>