RE: After upgrade from Team Coding 6 to Team Coding 7 all users have rights to change Team Coding settings and Code Collection Settings

Stephen Beausang <[email protected]> Mon, 25 Feb 2013 18:53:47 +0000
Newsgroups gmane.comp.db.oracle.toad.free
Message-ID <87842ED9F185434DBFBB6BDF630A3C2232FA3B06@ALVMBXW02.prod.quest.corp>
Hello Ana,
If the users have TC_LDR and / or TC_MGR permissions then they may still have the permissions on the underlying tables. This is the most likely scenario. Toad also allows the SYSDBA user update configuration. If any the users have SYSDBA privileges then they will have configuration permissions.

If none of the above apply, then the users still have update privileges on the Team Coding Tables.  I will send you the table privileges offline.

Stephen


From: [email protected] [mailto:[email protected]] On Behalf Of Ana Roje Ivancic
Sent: Monday, February 25, 2013 9:53 AM
To: [email protected]
Subject: [toad] RE: After upgrade from Team Coding 6 to Team Coding 7 all users have rights to change Team Coding settings and Code Collection Settings


Hello,

I checked the TC_ADMIN role on my schema and I found that only the TOAD user is in this role (he has checkboxes checked for Granted/Admin/Default in the “Configure Grantees” dialog).
None of my other users is in this role (none of their corresponding checkboxes is checked).

And they still can edit all Team Coding settings. For example, I managed to change the settings of a Code Collection, and switch Team Coding support off and back on.
In other words, they have full access to all actions on the dialogs:

-          Utilities-->Team Coding-->Configure Team Coding

-          Utilities-->Team Coding--> Team Coding Code Collections
None of the buttons/checkboxes on these dialogs is greyed out.
I can send you screenshots if you need them.

Any idea what is wrong in my case?

Thanks, Ana


From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Stephen Beausang
Sent: Friday, February 22, 2013 4:27 PM
To: [email protected]<mailto:[email protected]>
Subject: [toad] RE: After upgrade from Team Coding 6 to Team Coding 7 all users have rights to change Team Coding settings and Code Collection Settings


Hello Ana,
The upgrade from 10.6 to 11 modified the user rights for Team Coding. Users with TC_ADMIN rights have the right to modify configuration settings.
The other roles are no longer used.
Since 11.0,  the TC_ADMIN role can Configure Team Coding and Edit Projects. All other users should be read only in these windows.  The TC_LDR, and TC_MGR roles are not used in TeamCoding 7.
You can remove unused roles from all the users in the Schema Browser.  Right click on the Role and select ‘Configure Grantees’.  This will bring up a list of the users and you can select who you wish to deny the rights to. (Thanks to John D for this tip)
Stephen

From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Ana Roje Ivancic
Sent: Friday, February 22, 2013 9:21 AM
To: [email protected]<mailto:[email protected]>
Subject: [toad] After upgrade from Team Coding 6 to Team Coding 7 all users have rights to change Team Coding settings and Code Collection Settings


Hi!

I upgraded the versioning in an existing database from Team Coding 6 to Team Coding 7.
I am using several versions of Toad 11 (11.0, 11.5. 11.6.1)

I am surprised to see that now, after migration:

1.       all users have rights to change Team Coding settings (Utilities-->Team Coding-->Configure Team Coding)

2.       all users have rights to edit Team Coding Code Collections (Utilities-->Team Coding--> Team Coding Code Collections)

This is not nice.
Previously in Toad 10.6 and Team Coding 6, only the TOAD administrator user account had these rights.
If I now connect to the same database from Toad 10.6 as a “regular” user (getting the warning that the Tem Coding support is a newer version), I do not have the rights to change Team Coding Settings/Code Control Groups, as it was before.
My question is:

1.       Is this change in rights the result of the migration process or is the new default behavior?

2.       Do I need to deny rights to my “regular” users with a script or I have a better option for controlling the rights?

Thanx,
Ana