On Jul 26, 2010, at 1:57 AM, DJ Lucas wrote: > No. no need to modify it. Besides it would only add additional security > concerns. Just would be nice to elevate someone who is a pretty regular > contributor to an editor role (would save Bruce, Matt, and others? some > admin work). It's not like editors are added every day. I also wonder > how public key authentication would work with a virtual user. I'm not > familiar with OpenID. These are probably features that would not be > used anyway, I was more curious as to how it all fit together and maybe > using it to streamline the process a bit.
I wonder if we're talking at cross points here. Someone who is a regular contributor and has an account in Redmine *can* be given commit privileges through the Redmine system. The only caveats here are: 1. They must use the http(s) svn scheme when they checkout and commit code, e.g., svn co https://linuxfromscratch.org/svn/lfs/trunk/BOOK lfs-trunk. 2. They wouldn't receive a system account meaning that (with our current setup) they would not receive a @linuxfromscratch.org email address. Of course for some people this isn't a big deal since they're already using a certain mail address for LFS communication (and perhaps elsewhere on the web). This is achieved by adding proper restrictions to various svn commands in Apache's virtual host definitions, and by having Apache run a perl script to find Redmine users/passwords. See this article: http://www.redmine.org/wiki/redmine/repositories_access_control_with_apache_mod_dav_svn_and_mod_perl > Actually, in issue status you can set resolved status to = a closed > type, but I don't see a way to automatically modify status based on the > custom resolution field. I poked around on the forums, but nothing > caught my eye WRT to modifying status based on a custom field, but this > can probably be done in the code. Actually, a better option, I think, > would be to define what is currently the Resolution items as a custom > status and set the issue type to closed for all of the above. That > would probably be easiest. I'm not sure what that would do to > historical data though. I guess keep both the custom resolution and the > custom status types, but don't display the resolution field by default. > Was the resolution field pulled in by the Trac import, or manually added? Ah, I see what you're saying. Yes I believe Resolution was brought in from Trac, it's listed under 'Custom Fields' in the main Administration section. Besides the custom fields, all the rest of the workflow can be modified in the main Administration section via 'Roles and permissions', 'Trackers', 'Issue statuses', 'Workflow' & 'Enumerations'. > Also, another feature request. It might not be a bad idea to add a need > info status (that is of a closed type) and then add a re-opened status > and allow that for only the reporter and developer and manger if type > status was set to need info. This gives us the ability to close a > ticket and get it out of the queue without offending the OP by setting > invalid prematurely if they haven't answered a request after a few days. Sure, all those could be added. > My Ruby is about as fluent as my Cantonese (ie: not). Probably about > time to learn anyway. But feature requests are simply to streamline > administration (which I don't believe is that difficult anyway). The > lack of public key auth pretty much limits the use of virtual users I > think. I mean, it might be able to be hacked in, but that would > probably be a bit much to ask for so little gain. The method that is > used now works and is fairly easy to do. At any rate, the line of > questions related to the virtual users are no lesser than our current > Track setup, so we have some options gained, but certainly nothing lost. Yep, I agree. > Overall, it really doesn't look like much needs changed from the default > settings. So now that my nitpicks are done, the resulting todo list > (per my own opinions) is pretty short. The default assignees must be > set per tracker types and per sub-project, add the custom status types > added, remove the display of the resolution field, edit "Developer" > permissions and possibly even "Reporter" permissions, and acquire a cert > for https (maybe don't listen on http). The SCM browser to do an anon > checkout and create a tarball would still be nice so that users who want > to contribute patches don't have to install the SCM client. Pretty > common feature on Trac, so I'd bet that there is probably already a > plugin for that. Great, you planning on helping test this thoroughly then? Would you be able to help get HTTPS working successfully? Thanks, JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
