Do you allow users to program feature buttons on their phone?
-
My initial response to this is "no," as I'm generally wary of users configuring anything; however, consider this scenario.
Let's say there are unused buttons available on the phone (think page 2 or 3 of your feature buttons on a Yealink phone. Should a user be allowed to say configure their own speed dial buttons, or would you have the phone locked down, requiring the user to submit a request to IT (me) to configure that for them?
On one hand, I say "yes, lock it down." That way the user can't mess up the base configuration you've created and deployed through auto provisioning.
On the other hand, I think "maybe there is a middle ground," which allows just the lock down of the first page of buttons, so the user can do some customizations.
On the other other hand, users are probably not going to ever bother to learn how to use stuff and would come to me anyway to ask for something to be programmed; thus, the original hand (Yes, lock it down) the best option.
I know I've answered my on question here, but, as always, I'm curious to hear your folks' opinions.
-
This assumes such locking down can actually be done.
-
Generally, no.
-
Yes, because the Yealink phones have a "user" level login that cannot fuck up any important settings.
-
@eddiejennings said in Do you allow users to program feature buttons on their phone?:
uld a user be allowed to say configure their own speed dial buttons, or would you have the phone locked down, requiring the us
I say let them do it, assuming you lock them out of setting that really break the phone.
Your third option where you say it's unlikely that they will do it on their own anyway, so they will reach out to you, but what about those few who will? You've just wasted yours and their time doing something they were willing to do on their own.
-
By default the login is user:user
I can disable my extension, but not change anything other than display name and label
Yet still have full access to the DSS keys
