1 permissions if not admin You probably already know this, but just in case.... If a user is not an administrator and they attempt to click on a project where they are a member (in any role, manager, developer, reporter, etc.), there is an unexpected result: Filter chain halted as [authorize] returned false Completed in 0.00010 (10000 reqs/sec) | Rendering: 0.00000 (0%) | DB: 0.00000 (0%) | 403 [http://localhost/projects/show/1] I believe this is the relevant code in the application.rb: # admin is always authorized return true if self.logged_in_user.admin? # if not admin, check membership permission @user_membership ||= Member.find(:first, :conditions => ["user_id=? and project_id=?", self.logged_in_user.id, @project.id]) if @user_membership and Permission.allowed_to_role( "%s/%s" % [ ctrl, action ], @user_membership.role_id ) return true end render :nothing => true, :status => 403 -/- Put another way- create a non-admin user, add this user to a project in any role (manager, developer, etc.) and then login as this new user. when you click on the project, you receive a blank page -/- Thoughts? Let me know if you want any help on this or if I'm doing something strange? Todd 0 Sat Dec 30 11:35:00 +0100 2006 Thu Aug 13 18:00:17 +0200 2009 Commit messages are now scanned for referenced or fixed issue IDs. Keywords and the status to apply to fixed issues can be defined in Admin -> Settings. Default keywords: - for referencing issues: refs, references, IssueID - for fixing issues: fixes,closes There's no default status defined for fixed issue. You'll have to specify it if you want to enable auto closure of issues. Example of a working commit message: "This commit references #1, #2 and fixes #3" Tue Apr 24 15:57:27 +0200 2007 Fixed in Revision 128

Hi, You're right. There is a big problem for members of non public projects. Public actions (projects/show, ...) should be implicitly authorized to any role. For the moment, i'll fix it this way (0.4.0 should be released soon). In 0.5.0, many changes should be done on permissions management, I'll do my best to answer your needs. Thanks for your submission. Best regards, Jean-Philippe

I have solution working for me and it also solves feature request id: 6535. Maybe it will be helpful for you? On the roles page (new or edit), we could include all permissions including public. This way, we can control things like projects/show, projects/list_issues, etc. In addition, we can control whether or not certain modules will even appear for certain groups (see feature request id: 6535). For example, if a group does not have "List" permission for Documents module, the Documents link will not appear. I will upload three patch files to this ticket for your review: roles_controller.rb_PATCH.txt base.rhtml-PATCH.txt application_helper.rb-PATCH.txt

So, on further review, there are going to be many of things related to this- projects/list_issues projects/list_news etc.

I think the problem is two parts 1) default data load should include 100 in default permissions (I'll attach patch file to this ticket) 2) When creating a new Role, we need to add a permission id of 1. What is the best way to do this? hidden form field? update the "method" in roles_controller to include it?

Pardon me! The code above is perfect. The problem can be resolved by inserting into the permission_roles table. The projects/show permission is not included from default roles and also if you add a new Role. I'll research more.

__