Possible solutions to limit access to Object Designer

ReisC

Up until now, both the consulting team and the Client's IT Department had administrator access to Object Designer through SUPER access.

Now because the IT department created a new module, they do not want the consulting team to have any kind of access to the module's associated tables, while still maintaining administrator access.

Is there any way to allow me to have one team have administrator access to Object Designer except for a few tables while another has full access?

Any kind of alternative/idea would be appreciated, whether it'd be something like hiding tables, forbidding access, creating different companies and integrating the 2 for G/L data. As long as it achieves the pretended final result.

Thank you.

Dakkon

The only way I know for that to be possible is for both groups to have separate licenses with access to different object ranges. So in short, I think you are out of luck there.

David_Singleton

Just set permission for the second group to the appropriate designers and don't give them read access to the tables you don't want to access. This seems to be pretty much standard NAV security. Am I missing something that makes it complex?

vaprog

David Singleton wrote:

Just set permission for the second group to the appropriate designers

According to what I understood that are all designers (understanding designers to be functional entities of NAV, not developers).

David Singleton wrote:

and don't give them read access to the tables you don't want to access.

How do you do this, allowing them access to tables they have just created? To my knowing there is no way to revoke rights, only to grant rights. Furthermore, validation allows to grant rights only on existing objects (as of NAV 2009 R2) and only on single objects, no ranges (except for the 'all' range denoted by object ID 0) as in the license.

David Singleton wrote:

This seems to be pretty much standard NAV security. Am I missing something that makes it complex?

This seems to be standard NAV security on a license level. On a role/access right level, this certainly is out of the ordinary. Do you know, without experimenting or studying license permissions, from the top of your head, what rights you need to not grant in order for them to do everything with those tables except whatever you can do in the designer? Do you know any (official) place this is documented.

David_Singleton

Create a roll with these permissions.

Object Type	Object ID	Read Permission	Insert Permission	Modify Permission	Delete Permission	Execute Permission
Table Data	50000	Yes	Yes	Yes	Yes	 
Table	50000	Yes	Yes	Yes	Yes	Yes
Form	50000	Yes	 	 	 	 
System	1310	 	 	 	 	Yes
System	1320	 	 	 	 	Yes
System	1330	 	 	 	 	Yes
System	1340	 	 	 	 	Yes
System	1530	 	 	 	 	Yes
System	1540	 	 	 	 	Yes
System	1550	 	 	 	 	Yes
System	1570	 	 	 	 	Yes
System	1580	 	 	 	 	Yes
System	1610	 	 	 	 	Yes
System	1630	 	 	 	 	Yes
System	1640	 	 	 	 	Yes
System	2510	 	 	 	 	Yes
System	2520	 	 	 	 	Yes
System	3220	 	 	 	 	Yes
System	3230	 	 	 	 	Yes
System	3410	 	 	 	 	Yes
System	3510	 	 	 	 	Yes
System	5210	 	 	 	 	Yes
System	5310	 	 	 	 	Yes
System	5315	 	 	 	 	Yes
System	5320	 	 	 	 	Yes
System	5330	 	 	 	 	Yes
System	5410	 	 	 	 	Yes
System	5420	 	 	 	 	Yes
System	9010	 	 	 	 	Yes
System	9015	 	 	 	 	Yes
System	9020	 	 	 	 	Yes
System	9025	 	 	 	 	Yes
System	9030	 	 	 	 	Yes
System	9035	 	 	 	 	Yes
System	9040	 	 	 	 	Yes
System	9045	 	 	 	 	Yes
System	9050	 	 	 	 	Yes
System	9055	 	 	 	 	Yes
System	9060	 	 	 	 	Yes
System	9065	 	 	 	 	Yes
System	9070	 	 	 	 	Yes
System	9075	 	 	 	 	Yes

This user will be able to design Table 50000 and Form 50000 and nothing else.

This is really basic Navision security.

<edit> also you don't need all those System permissions, I just didn't have time to experiment, so added everything.

einsTeIn.NET

You just have to give Read Permissions to every Object No. the Designer Team should have access to. Don't forget the System Permission that allow you to use the Object Designer itself and the Design Modules.

Records for Objects that doesn't exist at the moment could be created by importing Permisssions (e.g. Dataport) or by creating a batch report. You just have to make sure it doesn't validate the Object ID.

Another possible solution is to use the lock/unlock functionality of the Object Designer introduced in 2009 R2. If you are on a lower version and can't perform a technical update then the Object Manager Advanced (http://www.mibuso.com/forum/viewtopic.php?f=7&t=17454) could be a way to go. It's also using some kind of lock/unlock functionality.

ReisC

Thank you very much for your support.

We weren't aware it was something so basic. In fact we talked with Microsoft partners and even they vehemently told us this kind of thing wasn't possible.

After testing this out it seems to work very well. The only issue is that one of the teams is going to have to forfeit the Export function for FOBs otherwise someone could just export the tables with the forbidden data and import it to another database.

Also, something it'll take us time to test out but maybe someone can answer this quickly: In relation to the Debug function, does it allow me in any way to see the data inside a table, run it or edit in any form?

Doing it directly on a forbidden table seems to be impossible but we're wondering if a table we have access too indirectly interacts with a forbidden one, will debug allow us to see the data in the forbidden one or change the table itself somehow?

ta5

Please allow the following questions: Why are the data so secret? Isn't it possible to handle it through the organization, not through a technical solution?
Thomas

Dakkon

Thanks for pointing out that solution David. I had it in my head that restricting the permissions in that fashion for a developer would interfere with their ability to develop (in general that is). Always nice to learn something new.