On Wednesday 01 November 2006 15:08, Emmanuel Blot wrote: > > As far as I can see, you can. If "restrict_owner=false", then I can put > > any user into the "assign to" field I want and a ticket is created. > > Perhaps I misunderstood what you were looking for. > Trac is an open system: the default behaviour is to allow any user - > even unknown users - to create or be assigned tickets. This default > behaviour is demonstrated on the trac.edgwall.org web site.
The question is whether or not I can *assign* a ticket to a non existant user. Although allowing anonymous users to add tickets or leaving the assignment field blank might be a good thing in certain circumstances, I cannot see any reason to be able to assign tickets to a non-existant user. > > That was part of the problem. You have to either know in advance that a > > drop-down list is possible and search for that phrase, or you have to > > quess and search for "drop-down". > > Well, the Trac web site is a wiki, and the documentation can always > been improved. Any user can contribute, so feel free ;-) I realize that anyone can change it, but that's not why I am here. I am writing an article on ticketing systems. I want to make sure I get things right and if I run across things that I think should be addressed, I will tell people. BTW I think the Wiki would be well served by a developer (or someone else) who takes ownership it. It is definately a two-edge sword and can quickly become worthless if no one keeps an eye on it. > > So there is nothing planned within Trac itself? Personally, I think that > > for any ticketing system account/user management should be part of the > > core product. > > Personally, I don't: I want to integrate Trac in an existing > environment, I do not want to have to deal with just another user > management system, I want it to fit in the existing environment. > Plus, I don't want to rely on a hand-crafted authentication system, > but on HTTP/Apache authentication schemes, as there are few chances of > security holes - as they are more widely used. There are enough open source projects with there own authentication, so you would not be re-inventing the wheel. Further, most of the problems lie not in the authentication mechanism, but failures in the rest of the code (i.e. SQL injection, assuming that if particular code is reached the user *must* be logged in, etc.) These are going to happen with HTTP authentication, so you are definately lulling yourself a false sense of security if you think "there are few chances of security holes" with HTTP authentication. Also, I have HTTP authorization only set up to access the webserver itself. That is, unless the user has an HTTP user and password, they cannot even input the URLs to the various software I have installed. Each has its own user management, which is actually **more** security. Using HTTP authentication you have a single point of failure. Granted it might be more "convenient" than an intergrated user management, but convenience is that natural enemy of security. In my case, if one package is comprimised, the cannot access any other. Knowing that the application uses HTTP authentication, I know that should I be able to compromise the application I am an authorized user from the standpoint of the web server. > However, many other people have many other needs and expectations, and > that's the beauty of plugins. It's quite easy to use an existing > plugin, or to write a custom one. My initial reaction to that is what does Trac really bring me? If you are not going to include standard features and rely so much on plugins, what's the point of a seperate project/product? Why not spend the time implementing a "plugin" to MediaWiki, OTRS or dotProject that adds the extra features you want. Why didn't you name it YABTT (Yet Another Bug Tracking Tool)? Please don't get me wrong. I respect the amount of work that went into the product so far. But if I need to spend the effort to hassle with plugins from multiple sources to get something as basic as user management, and deal with all of the mismatched dependancies and version differences, **plus** have to learn the idiosyncrasies on yet another product, what real benefit does Trac bring? > > To me that's not a good thing. > > I understand this. > Some other people, including myself, feel otherwise. It's your project. You develop it the way you see it. Just as I write the way I see it. Regards, Jim Mohr --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users -~----------~----~----~----~------~----~------~--~---
