Columns multipling in Role based lists

Question

This one is really wierd and I am surprised if no one noticed this before. Here it goes:
I create a list on a object ( say Opty) by refining all Opty and save this under name 'All Opty Test' and assign it to role Admin
Then I create another list on same object by refining all Opty and save this under name 'All Opty Test' again and assign it to role Sales Manager
System allows me to save new list with same name as old one. But I see only one list later.
This is not it , I go to 'All Opty Test' list then I see columns duplicated and when I export for visible columns then csv file has few duplicate columns with data value but no header.
If I repeat above step to create third list with same name then columns triplicate.
Anyone faced this before , Any workaround will be appreciated!
thanks
Manny

Answer 1

I would be tempted to put the "revoke" file in a table. If the list of non-readable tables will vary between type of users, then this table should also include a column for the user type. Then, as a sufficiently privileged user, you could create a stored procedure to grant select privileges on the schema objects you want to the roles. Something along the lines of (completely untested code here):
CREATE PROCEDURE granter (p_to_role     IN VARCHAR2,
                          p_table_owner IN VARCHAR2,
                          p_writable    IN VARCHAR2) AS
   l_sql VARCHAR2(4000);
BEGIN
   FOR r IN (SELECT object_name FROM dba_objects
             WHERE owner = p_table_owner and
                   object_type IN ('TABLE', 'VIEW')
             MINUS
             SELECT table_name FROM revoke_file
             WHERE user_type = p_to_role
             MINUS
             SELECT table_name FROM dba_tab_privs
             WHERE grantee = p_to_role) LOOP
      l_sql := 'GRANT SELECT';
      IF UPPER(p_writable) = 'Y' THEN
         l_sql := l_sql||',INSERT,UPDATE,DELETE';
      END IF;
      l_sql := l_sql||' ON '||p_table_owner||'.'||r.table_name||' TO '||p_to_role;
      EXECUTE IMMEDIATE l_sql;
   END LOOP;
END;You could easily modify this to revoke already granted privileges if a previoulsy allowed table is moved to the revoke file. This procedure would also need to be re-run any time new tables were added to the application
In order to see the text of stored procedures, the role would need select privileges on the dba_source view.
In terms of system privileges, the user (or the role) should only have CREATE SESSION privilege. This allows them to connect to the database but nothing else.
HTH
John