cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
320
Views
0
Helpful
8
Replies

Restriction Tables - Message Notification

lkrol
Level 1
Level 1

Hello.

I'm hoping someone can clarify a really strange situation.

This is on a Unity 3.1.5 server. I've created a custom restriction table, which is part of a custom COS. My account belongs to this COS. It allows me to have message notification to all the local 11 digit area codes, with a 9 in front.

So the restriciton table looks something like this:

91312???????

91630???????

and so on

However, anytime I would try to put in any sequence matching 91??????????,

I would get an error message saying that is a restricted sequence.

I played with it for a while and finally looked at the Default Outdial restriction table which had a 91??????????* - NO statement. I changed it to YES and I was able to put my 1312 and other numbers into the message notification number field.

So, does anyone know...is there some sort of a restriction order that if the Default REstriction table does not allow then none of the restrictions tables will allow?

Thank you!

1 Accepted Solution

Accepted Solutions

the account you're logging in to is associated with a Unity subscirber (most likely) via the grant unity access tool... when you access the SA, _this_ is the account you're accessing as and so it's _that_ user's COSes RT that's being used.

If you mapped your account to the special "installer" account, then you have a problem... it's best to map it to a real account (i.e. Example Administrator is the most often used guy here). You can make this association in GrantUnityAccess if needed (and remove the existing association if you need to).

Yeah, I get some folks that think we've lost our minds for the way the RTs are enforce. But let me run this scenario by you: an organizaiton that doesn't want end users making ANY changes to transfer numbers, dialout numbers or fax numbers - they want it all to go through the help desk (this is actually very common). As such all subscribers are associated with COSes that have RTs that allow _nothing_ at all. So... a help desk person gets a request to change someone's transfer number or setup a delivery device - presumably approved by IT or their manager or whoever needs to approve such things. When they go in to do this with our model, it uses the help desk person's RT which is presumably setup to allow such things. Otherwise they'd have to change the RT the subscriber is associated with, edit the number then change it back - realizing of course that changing the RT affects _all_ users on that COS for that time - not ideal at all.

The model we use is actually really straight foward - he who makes the change has their RT enforced. period. it's really intended for centralized admin models but works fine in either mode - just not what you may be expecting.

View solution in original post

8 Replies 8

lindborg
Cisco Employee
Cisco Employee

no... there's no logic like this in the system.

The restriction table (outdial in this case) assoicated with the COS of the person making the change is applied as you would expect - some folks stumble on this and assume it's the restriction table associated with the user the are changing - not the case, it's always the RT of the user _making_ the change (either over the phone or via the SA). Any chance you're getting bit here?

So, are you saying that its the RT of the account with which I'm logging into Unity. I'm using an administrative account that was setup during the installation and I'm making the changes using SA.

How is one supposed to change the RT tables for all the users?

I'm not entirely sure what you're asking here...

The restirction tables apply to the person making the change. This way admins can make changes to dialout/transfer/fax delivery numbers for users in their systems without having to go hack the subscriber's RT first which is very annoying and tedious if they need to stuff a transfer number in there, for instance, that's temporary and is outside of the subscriber's RT definition - if you're an admin with full-on rights you should be able to change anyone's transfer numbers to anything you want. Short story, we trust the admins to not be evil folks.

Normally RTs for subscribers are only enforced when that subscriber attempts to make a change over the phone or via the AA/PCA web interfaces.

RTs are associated with COSes, not users, so I'm not sure what you're asking with "how is one supposed to change the RT tables for all the users?" here. Presumably you have a few COS definitions that all your users are grouped into to minimize the number of such changes...

Let me see if I can be more specific.

I am the admin. I access the SA interface, and I specify the phone number to which the message notification is to be sent. The reason I'm doing this is for testing, because the users do not yet have access to the AA interface. However, I get an error on the screen when I try to input any phone number that does not match the Default Restriction table. I don;t want to use the Default Restriction table, but instead a custom one.

Does this make sense?

right... so you need to change the RT of the COS _your_ admin account is associated with... not the RT that is associated with the COS the subscriber(s) you are trying to change are associated with.

I had guessed you were changing the RT of the subscriber's COS and left yourself (in the admin COS) associated with the default RTs - if that's not the case then there's a different problem at play but since I see this mistake made now and again I'm guessing it's related to what you're seeing.

Ok. I think I understand what you are saying, but it seems like a really strange way of changing restrictions.

The admin account I'm using to login does not have a Unity subscriber account and does not have an RT associated with it.

Unless, any adminisrative account is automatically associated with the default admin RT.

If that's the case, then how do I modify the RTs for the subscribers, without changing my admin RT.

the account you're logging in to is associated with a Unity subscirber (most likely) via the grant unity access tool... when you access the SA, _this_ is the account you're accessing as and so it's _that_ user's COSes RT that's being used.

If you mapped your account to the special "installer" account, then you have a problem... it's best to map it to a real account (i.e. Example Administrator is the most often used guy here). You can make this association in GrantUnityAccess if needed (and remove the existing association if you need to).

Yeah, I get some folks that think we've lost our minds for the way the RTs are enforce. But let me run this scenario by you: an organizaiton that doesn't want end users making ANY changes to transfer numbers, dialout numbers or fax numbers - they want it all to go through the help desk (this is actually very common). As such all subscribers are associated with COSes that have RTs that allow _nothing_ at all. So... a help desk person gets a request to change someone's transfer number or setup a delivery device - presumably approved by IT or their manager or whoever needs to approve such things. When they go in to do this with our model, it uses the help desk person's RT which is presumably setup to allow such things. Otherwise they'd have to change the RT the subscriber is associated with, edit the number then change it back - realizing of course that changing the RT affects _all_ users on that COS for that time - not ideal at all.

The model we use is actually really straight foward - he who makes the change has their RT enforced. period. it's really intended for centralized admin models but works fine in either mode - just not what you may be expecting.

Got it. Now it makes sense. Thanks a ton for the explanation.

FYI: You might want to forward this to all the Unity TAC guys....I don't think they know.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: