Re: prevent changing Status for new issues

On 10/05/2014 12:11 PM, John P. Rouillard wrote:
> In message <[email protected]>, Stuart McGraw writes:
>>I'm having trouble configuring Roundup.
>>
>>I am working from the "devel" template and thus have User and Developer
>>roles (in addition to others).
>>
>>I want Users, when creating a new issue or editing an existing one,
>>not to be able to change the status or resolution fields.  When a new
>>issue is created, I want status to automatically be assigned 1/new
>>and not changeable when editing existing issues. 
> 
> This should be done with an auditor, not as part of the interface.

Yes, I am using the statusauditor.py detector that comes with
Roundup.

>>For Developers, I want the status and resolution fields to be normal.
>>
>>In schema.py, I removed 'status' and 'resolution' in the following
>>statement:
>>    for cl in ('priority', 'status', 'resolution',
>>           'issue_type', 'issue', 'file', 'msg'):
>>        db.security.addPermissionToRole('User', 'Create', cl) 
>>so that now, the only permission the User role has to 'status' and
>>'resolution' is View.  I also enabled the statusauditor.py detector.
>>
>>Yet users with only User role can still set status and resolution to
>>be anything when creating a new issue.  Editing existing issue seems
>>ok (no change of status or resolution allowed).
>>
>>I think I am misunderstanding how permissions work.
> 
> IIRC, and I am sure somebody will correct me if I am wrong, these
> permissions work on the class/object.
> 
> So by deleting Create permissions for status and resolution, you
> prevent people (in the User role) from creating new status entries or
> new resolution entries.

Which I thought was the right thing to do.  Without the ability
to create a status item, it can only get created by the actions 
of an auditor, yes?  Which seemed like what I want.

> What you want is to control the permissions on the issue classes
> properties "status" and "resolution", and the loop you modified
> doesn't affect that.  (However that being said, I don't see why a
> normal User would have the rights to create new status or resolution
> (or priorities for that matter), so I claim removing the Create rights
> makes sense.)
> 
>>How do I get the behavior I am looking for?
> 
> Look at:
> 
>    http://www.roundup-tracker.org/cgi-bin/moin.cgi/ItemBasedPermissions
> 
> I could have sworn there was some documentation on this in the main
> documentation, but the only thing I can find is:
> 
>   http://roundup.sourceforge.net/docs/customizing.html#changing-access-controls
> 
> which discusses the properties and check functions for
> addPermisssion. 
> 
> I have to say I have had issues with getting these to work like I
> want, but I think in your case the following should work.
> 
> For the User role, find where Edit permissions are added, and don't
> assign addPermisssionToRole('User', 'Edit', 'issue') to it.

I am starting with the stock, out-of-the-box permissions assigned
in the "develop" template schema.py:
  http://sourceforge.net/p/roundup/code/ci/default/tree/share/roundup/templates/devel/schema.py

I think it already does what you are suggesting.  Specifically, there 
is no "addPermisssionToRole('User', 'Edit', 'issue')".  Instead there 
are:

  p = db.security.addPermission(name='Edit', klass='issue',
                                properties=('title', 'issue_type',
                                            'messages', 'files', 'nosy'),
                                description='User can report and discuss issues')
  db.security.addPermissionToRole('User', p)

and similar for Create.

I deleted both.

> Once you save this change, fire up:
> 
>    roundup-admin -i /your/tracker/directory
> 
> and run "security". The User role should not have any View or Edit
> access to issues.

Confirmed.  "User" has View and Create privs for the property classes
including "status" and "resolution", but none for "issue".

> With that done, set up the User access rights on a per property basis:
> 
>   # first create a list of all properties we want normal users to
>   # have edit access to
>   issue_props = dict.fromkeys (db.issue.properties) # get all issue props
>   del issue_props['status']   # delete status prop
>   del issue_props['resolution'] # delete resolution prop
>   issue_props = issue_props.keys() # extract remaining prop names into list
> 
>   # now create edit permissions for User for just these fields
>   # Edit implies View IIRC.
>   p=db.security.addPermission(name="Edit", klass="issue",
>           description="Normal users can't edit issue status and resolution",
>           properties=issue_props )
>   db.security.addPermissionToRole('User', p) 

OK.  But now User has no ability to create a new issue (ie "Create 
New Issue" link is gone) so I added the 
  ...addPermission(name='Create', klass='issue',...
lines back in.

>   # Add view permissions for just status and resolution to
>   # the User role.
>   p=db.security.addPermission(name="View", klass="issue",
>           description="Normal users can view issue status and resolution",
>           properties=('status', 'resolution') )
>   db.security.addPermissionToRole('User', p) 

I found had to give full access for View to issue (not just
the 'status' and 'resolution' properties so I'm not sure that 
Edit really implies View.

To make a long (all day) story short, I ended up making the 
following changes, the first being key and all basically from
your suggestions:

for cl in ('priority', 'status', 'resolution',
-           'issue_type', 'issue', 'file', 'msg'):
+           'issue_type',          'file', 'msg'):
     db.security.addPermissionToRole('User', 'Create', cl)
[...] 
p = db.security.addPermission(name='Create', klass='issue',
-                              properties=('title', 'issue_type','messages', 'files', 'nosy'),
+                              properties=('title', 'type', 'priority','messages', 'files', 'nosy'),
                               description='User can report and discuss issues')
 db.security.addPermissionToRole('User', p)
 p = db.security.addPermission(name='Edit', klass='issue',
-                              properties=('title', 'issue_type','messages', 'files', 'nosy'),
+                              properties=('title','messages', 'files', 'nosy'),
                               description='User can report and discuss issues')
 db.security.addPermissionToRole('User', p)

> For a Developer (and other users who should be able to set the
> fields):
> 
>   p=db.security.addPermission(name="Edit", klass="issue",
>           description="Full edit rights on all isssue  properties")
>   db.security.addPermissionToRole('Developer', p)
> 
>   # this could also be expressed as
>   # db.security.addPermissionToRole('Developer', 'Edit', 'issue')

The developer permissions in the "devel" templates seemed ok and I was
able to leave them unchanged.  I wanted to keep the developer/coordinator
distinction that was made there.

> I think that's close to what you need, but as I said I never really
> got property permissions to work as I wanted. That's what is stopping
> me from releasing my sysadmin tracker. Maybe one of these day's I'll
> get back to it.
> 
> Hopefully this helps or sparks a discussion on how to do it properly.

Yes, there seems to be more to permissions than it seemed on first 
reading of the docs.

Although things seem to be working now as I want, I can't say that 
I really understand why.  For example, I don't get the distinction 
between 

   db.security.addPermissionToRole('User', 'Create', 'status')

and 

  p=db.security.addPermission(name='Create', klass='issue', properties=('status',...))
  db.security.addPermissionToRole('User', p)

Are they both needed?  What happens if I do one but not the  other?  
Does one take priority over the other?  I gather they have different 
effects but I'm not sure what.

But regardless, thanks immensely for your reply.  I am sure I would 
never would have got things working were it not for your help.

------------------------------------------------------------------------------
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk