-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/25/2010 08:03 PM, Jeremy Huntwork wrote: > On Jul 25, 2010, at 2:13 AM, DJ Lucas wrote: > >> Some technical questions: What is the authentication method? > > The default seems to be some form of basic authentication. I haven't > delved into the code to see if it does any sort of password obscuring > or not, but as you say we could run it over HTTPS. >
That would be preferable. >> Can it be >> used for system accounts as well or can it use the existing system >> authentication? > > Well it can use LDAP as you noted. Other than that, I think if we wanted > it to use unix accounts we'd have to add that feature in (or look to see > if someone out there has done it). > >> You had mentioned giving an existing Redline users >> commit privileges. Can it create a system account from the existing >> user, or does the SCM (Subversion currently) use the virtual users? > > The SCM uses the virtual user. Basically, it uses an HTTP(S) subversion > setup which has been configured to look in Redmine's user table to > authenticate users. > >> Really doesn't matter for my usage, but I can see it as helpful as the >> project grows for the admins. I see that LDAP is an option, so in that >> case, certainly you can, but how about with flat files? > > Again, it's something we'd have to bake in if that's what we wanted, but > I'm sure we could do it relatively easily. Another option is using OpenID, > which redmine supports. 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 also noticed three things I didn't like right off the bat. First, we >> are using http. At very least, we should listen on 443 and get a free >> certificate that is trusted by Mozilla out of the box (since that is >> where BLFS get's its certificate store). I personally use StartCom. I >> realize that has been an outstanding problem for a long time. > > Sure, I'd be all for that. > >> Second, >> setting a resolution in the ticket does not automatically close the >> ticket. > > I believe that can be configured in the workflow section. It's fairly > customizable. 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? Also, currently users with the "Developer" role cannot change status on closed type tickets (for instance, reopening or requesting additional information). I haven't made any changes to the permissions, just browsing about to see what all would need to be modified from the defaults. 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. > >> Third, e-mail addresses are not hidden by default. I'm >> guessing that both of the last two are probably globally configurable, >> are they? Didn't see anything in user preferences...or any user >> preferences at all beyond the my account page. I didn't see anything related to default new user settings, but users are set to be BCC'd for messages globally anyway, so the option would be unneeded. I also noticed that default assignees weren't set (this would auto add to the cc list for the various sub-projects). I'm guessing that this was intentionally omitted to avoid spamming the lists while testing. >> how about public_html dirs without changing the hostname >> to www or possibly adding personal additions beyond commit messages when >> somebody clicks on a name in a ticket as opposed to maintaining our >> 'home' pages in our home directory on quantum? That would invalidate >> the need for system accounts beyond server admins if Subversion (or >> another SCM) could use the same authentication method (see above). >> Coincidentally, does Subversion have an add-on to download a tarball >> like Git? Seems to me to be correct topic while discussing server updates. > > Most of these thing would be covered either by plugins or custom code. It's > all ruby on rails so it's not that difficult to adjust if you really want > to hack some new features in. 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. 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. > Hope some of these answers helped... Absolutely. Thanks. - -- DJ Lucas -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iQIcBAEBAgAGBQJMTSO8AAoJEIUM+xKzBYsInk0QAJ+2ybuUzErJ2kCWfLdWIedJ m41A0Q2TdCHZuu1wKbgcmMbHWfHHwyNJypWMCjesJ66iS8jn4sktvdFjbU4sLok5 0mgBIC+/Q6KgdIZs3HuxhL4pHnAtygDN7FgvuxnfxTz8QpWDtSFOOPPXbhaeN8Xq tcjfh/6B4qT8mxS2IxaFE+l+9V16qFHu5zNj9zJhsmCEyPXl12XN1aExRCBeThb8 WZsJRkWHPwz3325znXD28gRXWrbV5Zi/v3yDX/lNa/FWwd7H++jgBZqDEoa/7Miz hseQSsscWij2K8BaP6gaNYDIUC7AnW5vZr0t2SE/2JdUoR8QFlT9mfh76TyH2UOB W7RdTR2foh4LEkCV/UWKbzMBhobJAFCV0iJQxo+UCOtD4XiUOczhNiMcciC7hK/l qhHAKogL56e8uSWGc75Hnln7kqpoCwebzM7dpY3tsbCtH+rnNzZ56BJndN9PyobR R3S1oOw/FzC0E0NS8NaZGlTGiyB/XwjWYImirUeL3GuF0r5QI4OwTqvHTKhHgVNN E46bY9E0us4Zu/QCrRh7mrWKDGa+7pTpVvsuOOP27SAUlpOavwW6XkSqgI44q20a zOK6eRJ54Jc5HrxODgrCe8qEU62mhgXNiwzUF5C2L57Im5UuYZ3KBUb3xq28BwMW yIJi3Srm84ZfrAc6vRqj =LWbB -----END PGP SIGNATURE----- -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
