How to delete a "read-only" view?

I have a problem that a user has created a Private view and then removed his own access rights, leaving a view without other access-rights than "Everyone - Read-only". How can I remove or change the access rights for this view? I do not have access rights even as an administrator.
scr1my - Thu Nov 26 08:38:51 EST 2009

Re: How to delete a "read-only" view?
SystemAdmin - Fri Nov 27 03:44:19 EST 2009

If you are logged in with the user "Administrator" you have full access.

/Kristian

Re: How to delete a "read-only" view?
PeterVogel - Thu Dec 02 15:16:38 EST 2010

SystemAdmin - Fri Nov 27 03:44:19 EST 2009
If you are logged in with the user "Administrator" you have full access.

/Kristian

Nope, that's not true, at least not for 8.3. A user can create views that only they have edit rights to, and even Admins can't delete them. I have a view that was created by a user who departed the company. Their profile was deleted from DOORS upon their departure, but months later, when the view became obsolete, I tried deleting it and found the options greyed out.

Re: How to delete a "read-only" view?
SystemAdmin - Thu Dec 02 17:17:15 EST 2010

PeterVogel - Thu Dec 02 15:16:38 EST 2010
Nope, that's not true, at least not for 8.3. A user can create views that only they have edit rights to, and even Admins can't delete them. I have a view that was created by a user who departed the company. Their profile was deleted from DOORS upon their departure, but months later, when the view became obsolete, I tried deleting it and found the options greyed out.

PeterVogel wrote: "....A user can create views that only they have edit rights to, and even Admins can't delete them...."

Cannot replicate this - logged in as a standard user in 8.3, created a private view, removed RMCDA view rights which leaves only the EveryOne group with access rights = None, the view disappears from the module view list as expected. Logged in as Administrator, select Manage Views, I can see the private view and can delete it!

Is there a special scenario where you can replicate where an Administrator cannot see a module View?


Paul Miller

Re: How to delete a "read-only" view?
SystemAdmin - Fri Dec 03 06:39:16 EST 2010

PeterVogel - Thu Dec 02 15:16:38 EST 2010
Nope, that's not true, at least not for 8.3. A user can create views that only they have edit rights to, and even Admins can't delete them. I have a view that was created by a user who departed the company. Their profile was deleted from DOORS upon their departure, but months later, when the view became obsolete, I tried deleting it and found the options greyed out.

The Administrator account, user name 'Administrator' will be able to delete these veiws, as this one account is not constrained by access rights.
Users of type 'Database Manager' (along with all other specifically defined users) are constrained by access rights, so user name 'Bob' who is 'an Admin' will not be able to delete the view.
There is only one Administrator account, the username is always Administrator and the password should be guarded carefully because of the all-powerful nature of the account.

Re: How to delete a "read-only" view?
llandale - Fri Dec 03 15:56:11 EST 2010

PeterVogel - Thu Dec 02 15:16:38 EST 2010
Nope, that's not true, at least not for 8.3. A user can create views that only they have edit rights to, and even Admins can't delete them. I have a view that was created by a user who departed the company. Their profile was deleted from DOORS upon their departure, but months later, when the view became obsolete, I tried deleting it and found the options greyed out.

The poster said "The Administrator", not "The Admin Group". Yes, you can remove access so the admins cannot delete it, but no you cannot remove access so the "Administrator" cannot delete it.

There was a v7.1 bug ... well, that's long winded, but perhaps its remotely possible that the 'Administrator' has a specific access rights to the view. Check the Acces tab and make it Inherited, then try to delete the view.

You should advertise a policy that everyone who creates a view must immediately modify that view's properties to provide the DB Admins and the Project Admins RMCDA access to the view.

  • Louie

Re: How to delete a "read-only" view?
DUK9_Andrew_Wallen - Thu Jan 23 14:43:01 EST 2014

llandale - Fri Dec 03 15:56:11 EST 2010
The poster said "The Administrator", not "The Admin Group". Yes, you can remove access so the admins cannot delete it, but no you cannot remove access so the "Administrator" cannot delete it.

There was a v7.1 bug ... well, that's long winded, but perhaps its remotely possible that the 'Administrator' has a specific access rights to the view. Check the Acces tab and make it Inherited, then try to delete the view.

You should advertise a policy that everyone who creates a view must immediately modify that view's properties to provide the DB Admins and the Project Admins RMCDA access to the view.

  • Louie

A few years late, but I figured I'd share this.

We've built up quite an accumulation of views for defunct viewers.  Asking the user's to add RMCDA access for Admin wasn't working.

The solution I came up with had two parts:  dealing with the existing views and dealing with views yet to be created.

To deal with the existing views, I logged in as the "Administrator" user and ran the following script using multi-module run:




void AddAdminRightsForViews()
{
    Module m = current
    string viewName
    for viewName in views(m) do
    {
       View v = view(viewName)
       ModName_ mn = module(moduleVersion(m))
       if(canControl(mn, v))
       {
             string errMess = ""
             AccessRec accRec = get(v, "Admin", errMess)
       
             if(null(accRec) || isDefault(accRec) || !control(accRec))
             {
                Permission adminPermissions = read | create | modify | delete | control | write | change;
                print "Updating access for: " viewName "\n"
                errMess = set(v, adminPermissions, "Admin")
             }        
       }
    }
}




AddAdminRightsForViews();

 

To deal with the views yet to be created, I added a module pre-close trigger to the folders I cared about.  Whenever a user exits a module, the trigger runs through all of the views for which that user has control access and adds access for the Admin group if it doesn't already have access.  The code for adding the trigger is below:

void InstallAdminViewRightsTrigger()

{

    dxlTxt = 
    "
    Trigger t = current()
    Module m = module(t)
    if(!null(m))
    {
        string viewName
        for viewName in views(m) do
        {
           View v = view(viewName)
           ModName_ mn = module(moduleVersion(m))
           if(canControl(mn, v))
           {
                 string errMess
                 AccessRec accRec = get(v, \"Admin\", errMess)
               
                 if(null(accRec) || isDefault(accRec) || !control(accRec))
                 {
                    Permission adminPermissions = read | create | modify | delete | control | write | change;
                    errMess = set(v, adminPermissions, \"Admin\")
                 }        
           }
       }
    }
    "
 
    string trigName = "AddAdminAccessToViews"
 
    delete(trigName, module->all, pre, close, 15);
 
    Trigger trig = trigger(trigName, module->all, pre, close, 15, dxlTxt);
    if(!null(trig))
    {
       print "added trigger", name(trig) "\n"
    }
    else
    {
       print "trigger install failed \n"
    }
}

InstallAdminViewRightsTrigger();

Re: How to delete a "read-only" view?
llandale - Thu Jan 23 15:13:20 EST 2014

DUK9_Andrew_Wallen - Thu Jan 23 14:43:01 EST 2014

A few years late, but I figured I'd share this.

We've built up quite an accumulation of views for defunct viewers.  Asking the user's to add RMCDA access for Admin wasn't working.

The solution I came up with had two parts:  dealing with the existing views and dealing with views yet to be created.

To deal with the existing views, I logged in as the "Administrator" user and ran the following script using multi-module run:




void AddAdminRightsForViews()
{
    Module m = current
    string viewName
    for viewName in views(m) do
    {
       View v = view(viewName)
       ModName_ mn = module(moduleVersion(m))
       if(canControl(mn, v))
       {
             string errMess = ""
             AccessRec accRec = get(v, "Admin", errMess)
       
             if(null(accRec) || isDefault(accRec) || !control(accRec))
             {
                Permission adminPermissions = read | create | modify | delete | control | write | change;
                print "Updating access for: " viewName "\n"
                errMess = set(v, adminPermissions, "Admin")
             }        
       }
    }
}




AddAdminRightsForViews();

 

To deal with the views yet to be created, I added a module pre-close trigger to the folders I cared about.  Whenever a user exits a module, the trigger runs through all of the views for which that user has control access and adds access for the Admin group if it doesn't already have access.  The code for adding the trigger is below:

void InstallAdminViewRightsTrigger()

{

    dxlTxt = 
    "
    Trigger t = current()
    Module m = module(t)
    if(!null(m))
    {
        string viewName
        for viewName in views(m) do
        {
           View v = view(viewName)
           ModName_ mn = module(moduleVersion(m))
           if(canControl(mn, v))
           {
                 string errMess
                 AccessRec accRec = get(v, \"Admin\", errMess)
               
                 if(null(accRec) || isDefault(accRec) || !control(accRec))
                 {
                    Permission adminPermissions = read | create | modify | delete | control | write | change;
                    errMess = set(v, adminPermissions, \"Admin\")
                 }        
           }
       }
    }
    "
 
    string trigName = "AddAdminAccessToViews"
 
    delete(trigName, module->all, pre, close, 15);
 
    Trigger trig = trigger(trigName, module->all, pre, close, 15, dxlTxt);
    if(!null(trig))
    {
       print "added trigger", name(trig) "\n"
    }
    else
    {
       print "trigger install failed \n"
    }
}

InstallAdminViewRightsTrigger();

That's rather clever.

Some nit-picks:

  • I wonder if the trigger should do nothing if the module is not open Visibly
  • You don't need "write" and "change" accesses, they are redundant residual artifacts
  • Your "Modname mn.." line should be promoted outside the loop.
  • You don't have to save the view?
  • Your install code should allow for deleting the trigger.
  • I notice "module->all" adds it to the current Project.

This may be better than Tony's method of just removing offending views without telling anybody.

-Louie