Re: prevent changing Status for new issues

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.

>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.

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.

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.

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) 

  # 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) 

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')

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.

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk