Reset all ACLs to something sensible

RT Users
1

Greetings,
I have an “organically grown” RT system with a rat’s nest of a rights
matrix. I want to clean this out and start again. I have designed and
tested a new set of rights for everyone but I’m wondering as to the best
way of getting this implemented. I have the luxury of a development box
that I can load snapshots of production onto. I can see the following
possibilities:

  • Dump PROD onto DEV, change things, dump ACL table on DEV and import to
    PROD. But this means PROD has to remain static while this is done
    otherwise horrible things will happen because of changes to table
    indices etc. I can’t see PROD not being used while this is done so I
    doubt I can do this.
  • Manually altering all the PROD ACLs. Will take hours. Horrible but
    safe.
  • Some sort of API on top of SQL like the rt command line to remove,
    replace and re-define rights?
  • Manual SQL stuff. Shudder.

Any ideas?

Philip Kime
NOPS Systems Architect
310 401 0407

2

You could install RTx::RightsMatrix and use edit mode to reset the
rights so you can then set up the rights you want.

Philip Kime wrote:

Greetings,
I have an “organically grown” RT system with a rat’s nest of a
rights matrix. I want to clean this out and start again. I have
designed and tested a new set of rights for everyone but I’m wondering
as to the best way of getting this implemented. I have the luxury of a
development box that I can load snapshots of production onto. I can
see the following possibilities:

  • Dump PROD onto DEV, change things, dump ACL table on DEV and import
    to PROD. But this means PROD has to remain static while this is done
    otherwise horrible things will happen because of changes to table
    indices etc. I can’t see PROD not being used while this is done so I
    doubt I can do this.
  • Manually altering all the PROD ACLs. Will take hours. Horrible but safe.
  • Some sort of API on top of SQL like the rt command line to remove,
    replace and re-define rights?
  • Manual SQL stuff. Shudder.

Any ideas?

–
Philip Kime
NOPS Systems Architect
310 401 0407

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

We’re hiring! Come hack Perl for Best Practical: Careers — Best Practical Solutions

Drew Barnes
Applications Analyst
Raymond Walters College
University of Cincinnati

3

I’d look at option #1. Seems viable considering that the ACLs tables seems to be limited to Groups/Queues/CF objects. Just impose a control on changes to perms on those objects during testing periods. Oh, and make sure you have a before snapshot before you roll your changes over…

Michael Eraña, CISSP
CTO
PC Network, Inc.
eranam@lanusa.comFrom: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Philip Kime
Sent: Monday, May 01, 2006 5:31 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Reset all ACLs to something sensible

Greetings,
   I have an "organically grown" RT system with a rat's nest of a rights matrix. I want to clean this out and start again. I have designed and tested a new set of rights for everyone but I'm wondering as to the best way of getting this implemented. I have the luxury of a development box that I can load snapshots of production onto. I can see the following possibilities:
 
* Dump PROD onto DEV, change things, dump ACL table on DEV and import to PROD. But this means PROD has to remain static while this is done otherwise horrible things will happen because of changes to table indices etc. I can't see PROD not being used while this is done so I doubt I can do this.
* Manually altering all the PROD ACLs. Will take hours. Horrible but safe.
* Some sort of API on top of SQL like the rt command line to remove, replace and re-define rights?
* Manual SQL stuff. Shudder.
 
Any ideas?
 
Philip Kime
NOPS Systems Architect
310 401 0407
4

At Tuesday 5/2/2006 08:49 AM, Michael Erana wrote:

I’d look at option #1. Seems viable considering that the ACLs tables
seems to be limited to Groups/Queues/CF objects. Just impose a
control on changes to perms on those objects during testing periods.
Oh, and make sure you have a before snapshot before you roll your
changes over…

Greetings,
I have an “organically grown” RT system with a rat’s nest of a
rights matrix. I want to clean this out and start again. I have
designed and tested a new set of rights for everyone but I’m
wondering as to the best way of getting this implemented. I have
the luxury of a development box that I can load snapshots of
production onto. I can see the following possibilities:

  • Dump PROD onto DEV, change things, dump ACL table on DEV and
    import to PROD. But this means PROD has to remain static while this
    is done otherwise horrible things will happen because of changes to
    table indices etc. I can’t see PROD not being used while this is
    done so I doubt I can do this.
  • Manually altering all the PROD ACLs. Will take hours. Horrible but safe.
  • Some sort of API on top of SQL like the rt command line to remove,
    replace and re-define rights?
  • Manual SQL stuff. Shudder.

Any ideas?

–
Philip Kime
NOPS Systems Architect
310 401 0407

I would steer clear of options 1 and 4 unless you’re EXTREMELY
confident you know the RT database schema inside out. I’d recommend
writing a perl script that uses the RT API. You can rerun a script
like this as many times as you’d like until you get everything the
way you want.

There are some examples of such scripts in the wiki under
Contributions->External Utils. You can view the RT API documentation
by using perldoc - Request Tracker Wiki .

Steve

5

Philip Kime wrote:

Greetings,
I have an “organically grown” RT system with a rat’s nest of a
rights matrix. I want to clean this out and start again. I have
designed and tested a new set of rights for everyone but I’m wondering
as to the best way of getting this implemented. I have the luxury of a
development box that I can load snapshots of production onto. I can
see the following possibilities:

  • Dump PROD onto DEV, change things, dump ACL table on DEV and import
    to PROD. But this means PROD has to remain static while this is done
    otherwise horrible things will happen because of changes to table
    indices etc. I can’t see PROD not being used while this is done so I
    doubt I can do this.
  • Manually altering all the PROD ACLs. Will take hours. Horrible but safe.
  • Some sort of API on top of SQL like the rt command line to remove,
    replace and re-define rights?
  • Manual SQL stuff. Shudder.

Any ideas?

–
Philip Kime
NOPS Systems Architect
310 401 0407

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

We’re hiring! Come hack Perl for Best Practical: Careers — Best Practical Solutions
Philip,

Why go to such trouble? If you have a test system of the same

version as prod, just create a Queue, create a group, create a person or
two and start playing with the rights. Hint. Try to keep the individual
stuff to a minimum. By having people in groups (except maybe the
Admincc) you don’t have to keep defining rights for people. The only
system group right we have is seeoutgoingmail. The only system group
right for groups is creating/saving, etc. search queries. For the
AdminCc, we give him the individual right to see configtab. everything
else is in groups and roles. We have created a few extra scrips for our
approval Queue (1 Queue that handles approvals for about 12 queues that
belong to the same group manager). But, keep playing with it until you
know what these rights do. Check out the WIKI on rights and privileges.

Kenn