Redmine

Please add relations to #1248 and #1445.

hi brian,.very helpfull patch,. but i can't apply it against my redmine instance, it get "patch: ** Only garbage was found in the patch input.". i've try it using redmine 1.1 stable. is there something i'm missing out?

Are you using GNU patch? It works fine for me on a fresh copy of redmine 1.1 stable and the patch file directly downloaded from here. Maybe you copied and pasted the patch file rather than downloading it?

C:\redmine-1.1.0-issue-permissions>dir
 Volume in drive C has no label.
 Volume Serial Number is B0F5-5D37

 Directory of C:\redmine-1.1.0-issue-permissions

02/09/2011  10:14 AM    <DIR>          .
02/09/2011  10:14 AM    <DIR>          ..
01/09/2011  05:05 PM               322 .gitignore
01/09/2011  05:05 PM               317 .hgignore
02/09/2011  10:15 AM    <DIR>          app
02/09/2011  10:14 AM    <DIR>          config
02/09/2011  10:14 AM    <DIR>          db
02/09/2011  10:14 AM    <DIR>          doc
02/09/2011  10:14 AM    <DIR>          extra
02/09/2011  10:14 AM    <DIR>          files
02/09/2011  10:12 AM            15,061 issue-permissions-1.1.0.patch
02/09/2011  10:14 AM    <DIR>          lib
02/09/2011  10:14 AM    <DIR>          log
02/09/2011  10:14 AM    <DIR>          public
01/09/2011  05:05 PM               307 Rakefile
01/09/2011  05:05 PM               208 README.rdoc
02/09/2011  10:14 AM    <DIR>          script
02/09/2011  10:14 AM    <DIR>          test
02/09/2011  10:14 AM    <DIR>          tmp
02/09/2011  10:14 AM    <DIR>          vendor
               5 File(s)         16,215 bytes
              15 Dir(s)  205,845,831,680 bytes free

C:\redmine-1.1.0-issue-permissions>patch -p1 < issue-permissions-1.1.0.patch
patching file app/controllers/issues_controller.rb
patching file app/models/issue.rb
Hunk #2 succeeded at 246 with fuzz 1.
patching file app/models/mail_handler.rb
patching file app/views/issues/_attributes.rhtml
patching file app/views/issues/_edit.rhtml
patching file app/views/issues/_form_update.rhtml
patching file config/locales/en.yml
patching file lib/redmine/default_data/loader.rb
patching file lib/redmine.rb

+1 to move to trunk

Are you using GNU patch? It works fine for me on a fresh copy of redmine 1.1 stable and the patch file directly downloaded from here. Maybe you copied and pasted the patch file rather than downloading it?

i'm sory brian, it looks like i've downloaded the wrong file :P, i'm sory, the patch works great, but i had to use

patch -p1 < your.patch

thank you very much, this is very useful patch

Should this patch fit redmine 1.1.1 ? Or I have to downgrade to 1.1.0 ?

I'm only maintaining this patch across stable major versions. It should work, but I have not tested it with 1.1.1.

Also related to #5195

hello again brian,...i got a litle more problem regarding your patch, not how to patch it :P, but rather it's functionality. Let say user A, user B and User C. User A create an issue and assign it to User B, and before user B got the chance to update this issue, user A add notes first. My problem is, whenever this action happen, assignee always change to User C, which is the default assigne for this project, and User C had to assign it back to User B in order the workflow to proceed. So, is there some thing wrong?

for information,
1. i also use Auto Assigned Issue by Ludovic Gasc. If an user forget to assign the issue, this plugin will auto-assign to the project manager.
2. User C as Project Manager
3. User A as Consultant
4. User B as Developer

Which is the problem?

1) when user A adds notes, the assignee changes to user C?
or
2) user C is required to assign the issue back to user B (user B can't do it himself - no permission)?

If the problem is 1), then problem is in the 'auto assigned issue' plugin.

If the problem is 2), then user B (who only has the 'edit assigned issues' permission) is prohibited from updating the issue, since it's NOT assigned to user B, but assigned to user C. This is expected behavior. By giving user B the 'edit all issues' permission, then user B can edit the issue, even if it's assigned to user C. Note that a user has to have the 'edit issue planning' permission in order to edit the 'assigned to' field.

Brian Lindahl wrote:

Which is the problem?

1) when user A adds notes, the assignee changes to user C?

If the problem is 1), then problem is in the 'auto assigned issue' plugin.

yup, point no 1 is my problem, just to make sure, im going check on this plugin again. thx brian, i'll post about this as soon as i get my answer :)

hi brian,
could you look into this script for me?i'm not really a programmer

module AutoAssignedUser
  class Hooks < Redmine::Hook::ViewListener

      def controller_issues_new_before_save(context)
        autoset_user(context)
      end

      def controller_issues_edit_before_save(context)
        autoset_user(context)
      end

      def autoset_user(context)
        @settings ||= Setting.plugin_redmine_auto_assigned_user
        if context[:params][:issue]
          if context[:params][:issue][:assigned_to_id].blank?
            unless context[:issue].project.members.find(:all, :conditions => ["user_id = ? AND role_id IN (?)", User.current.id, @settings['client_roles'].collect(&:to_i)], :include => [:user, :roles]).first.blank? # If the user is the client, fill the "assigned to" field
                users_list = context[:issue].project.users_by_role
                manager_role = Role.find(@settings['project_manager_role'].to_i)
                context[:issue].assigned_to_id = users_list[manager_role].first.id unless users_list[manager_role].blank?
            end
          end
        end
      end
  end
end

Great patch, is this for sure going into 1.2? It really is need.

Any word on 1.1.1 compatibility?

Not sure. It would probably work just fine for 1.1.1, though. As far as I know, this patch is not going into v1.2.

Would love to see this included.

Our problem is Reporters assigning issues to developers as mentioned in RM #3461. Would this patch cover that? I can't tell if Edit Own Issue would give the reporter the ability to also assign it.

Brian,

The 'Edit Issue Planning' permission would solve your problem.

Brian: Thanks, I see that now, sorry I missed it. I do hope this makes it into the Redmine trunk.

+1

Why is percent done only 80%? Are there still tests for this new features?

Yes, 80% done because there are no tests written for this patch.

This functionality is important for our organization. When do you think this would be available in an offical release ?

covered by spec #8050

will this patch be included into future versions?

The problem with that patch is that it is very special to certain type of project type.
It would be better to make it configurable which fields in trackers can be

• visible (not visible)
• read only (writable))
• mandatory (optional writable)

dependent on role and status.

See #8050 for a brife description. #8050 will also cover this feature.

is there a chance to get an update for version 1.3.0?