[Trac] Download weather toolbar
Download Weather Toolbar - Instant weather reports, forecasts, and radar images anytime for FREE! - http://surl.in/HLWTD238206SVRAKSX --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Download weather toolbar
Download Weather Toolbar - Instant weather reports, forecasts, and radar images anytime for FREE! - http://surl.in/HLWTD238206SVRAKSX --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: user profile from database
This is currently not possible. There is an open thread/ticket about it (search for IUserDirectory), so stay tuned. Currently all you could do is inject your data into the session_attribute table, somewhat hackish I suppose, but it would work. --Noah Danny Adair wrote: Hi, Using trac version 0.10.3(-1) on Debian Etch with apache2/mod-python. I'm currently letting Apache do authentication against sqlite for trac, and only allow authenticated users. The same database also holds user profiles with lots of other information. What is the cleanest way to provide the full name/email address information to trac? I would like to disable the form from trac.Settings and pull everything from the database. Do I need to create a session for this? If yes, what's the best way to do this? Looking at... http://trac.edgewall.org/browser/tags/trac-0.10.3/trac/Settings.py - already assumes a session and just sets session_attributes name and email http://trac.edgewall.org/browser/tags/trac-0.10.3/trac/web/main.py - instantiates new session on contact if necessary http://trac.edgewall.org/browser/tags/trac-0.10.3/trac/web/session.py - doesn't seem to provide an API for _outside_ session creation (so either I mimick most of trac.main (providing req, env, and so on) or I manually INSERT into trac's database and create a cookie myself) Please keep in mind I'm doing this outside of trac (if it's a session I would create it after logging the user in, i.e. before main.dispatch() created a new session). Where's a hook for this? I see another option: Hack all templates which use full name and email address to pull it from a cookie which I set at login time. This seems very dirty but if it only affects the new ticket/change ticket screens and the session-way has issues I'd consider it. If someone changes such a cookie manually it's not tragic. This would be a comfort, not a security feature. Anyone done this before? This seems so basic I suspect there is a more straightforward way... Thank you, Danny --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Build or Revision number
Hi, I am looking for advice from experienced Trac users on the following issue: There seems to be a common drawback which is common to most bug-tracking systems including Trac, i.e., the ability to link bugs to a specific build/revision number. Let me explain: I am using svn for version control. When I build the package, the relevant svn revision number is hard-coded into the software. When users report a problem they provide this number. When QA reports a bug they also provide this number. When RD closes a bug they provide the revision number according to the svn check-in. So, in theory, I can map bugs to exact revisions including: what bugs exist in each revision, what bugs were opened/closed between two revisions etc. Now, for theory to materialize, I would need my bug-tracking system to link each phase of each bug to a specific revision number and allow searching and reporting on that. In contrast, Trac enables you to see the Version on which a bug was found and when (date time) the ticket status was changed (e.g., status changed from new to closed). In order to tell which revision the bug was fixed in, I have to lookup the svn log and find the revision closest to the date/time of closing the bug. Now, suppose you are working on several branches simultaneously. The date and time don't map to a single revision. It is impossible to know which revision the bug was fixed in. Any feedback is welcome. Doy. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Build or Revision number
On Thu, Feb 08, 2007 at 11:12:55PM +0200, Reuven Harrison wrote: In order to tell which revision the bug was fixed in, I have to lookup the svn log and find the revision closest to the date/time of closing the bug. Now, suppose you are working on several branches simultaneously. The date and time don't map to a single revision. It is impossible to know which revision the bug was fixed in. You probably want http://trac.edgewall.org/browser/trunk/contrib/trac-post-commit-hook Rainer --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: user profile from database
Danny Adair wrote: Thanks Noah, Thanks Brad, That looks simple enough, Brad (though I would have preferred not to touch the (apt-get installed) trac source). I'll give it a shot. 1. So I can use DbAuth just for the IUserDirectory information? Authentication is done and user name is passed through by Apache. Ah, I see. Well, you won't really need DbAuth, then. Just the IUserDirectory patch on #2456. But there is an example of a custom UserDir plugin in DbAuth code... http://www.trac-hacks.org/browser/dbauthplugin/0.10/dbauth/userdir.py#L22 I could see you writing your own DannyUserDirectory plugin, that goes against your own tables, instead of the Trac session table... As a starting point, you could use the one in DbAuth code, or the DefaultUserDirectory one in the patch. 2. Aren't user id (for authentication - banderson) and user name (for display - Brad Anderson) two separate things? I can only see users_username_field which seems to be used for both. Is that because trac doesn't have that difference? See above, you really don't need DbAuth. (although it escapes me how people get on without it ;) ) I do see the need for you to begin messing with get_supported_attributes() and get_user_attribute() methods, for things like first name, last name, or just full name. This is the way to retrieve many other attributes from your existing table(s). Btw, I don't know how the sequence of IUserDirectory providers is currently determined, but you may want to flatten the user list (first found is only found). Not sure how that can be done with generators in a scalable fashion. Oh, that IUserDirectory is plenty rough, but got me past my issue. I imagine the fact that it's nowhere near complete has something to do with its lack of inclusion in /trunk to date. As I said, it solved my issue, and I moved on, hoping someone would embellish it and get it into /trunk at some point. nudge, nudge, wink wink. Cheers, BA --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Sent mail and modify ticket ?
Hi everyone, I have some trouble in sending mail in Trac system. System include many users. The users who in modify ticket group can sent mail (CC) easily. Other users don't in modify ticket group can not sent mail (CC) when create a new ticket . So how can i config trac.ini in oder to sent mail (CC) other users. Thank you very much. === Vasc Software Media - VMG VOS Center - CMS Department Mobile : + 0904 954495 + 0914 152615 Tel: 7722728 (ext 455) Email : [EMAIL PROTECTED] [EMAIL PROTECTED] === - Hãy ghé qua trang chủ Yahoo! Việt Nam! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] RFC: Caching for Trac
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all. As some of you might already know, I'm running the Trac installation on madwifi.org. We're happy with Trac, it's a great tool that we don't want to miss anymore. But there is one issue that we would like to see addressed: performance. Background == Our handicap is that the server that currently hosts madwifi.org a) hosts several sites b) has a slow CPU (P3-800) c) runs on Apache 2.0 with mpm_prefork and can not switch to, for example, mpm_worker - another site depends on mod_php, and mod_php doesn't like mpm_worker The site will move to a dedicated server soon, which should mitigate the performance issues we experience (as described below) a bit - no more mod_php, so mpm_worker will finally be possible. However, the available CPU power won't be much better: P3-850 instead of P3-800. Changing to a more powerful server is not (yet) possible due to a lack of money. We have to take what we get. The problem === For every request to a Trac-driven site, Trac has to render the content first. In case of a wiki page as an example that would be something like: get the markup for the page from the database and process it, getting the HTML tag soup as result that then is delivered to the requesting client. The more complex the source of a requested page is, the more CPU time is consumed by Trac to render it. An example for such a case is our compatibility list at http://madwifi.org/wiki/Compatibility - if that page gets hit by several clients in parallel, the server is getting really slow. (Yes, I'm aware that reducing the complexity of the mentioned page will be a way to relieve the pain a bit, and actually that is work in progress - but that's not the point here :)). On the other hand, the majority of the frequently requested pages seem to be rarely changed. So the question for me is: why should Trac compute the same page over and over again when most of the time the result will be the same as for the last request? The suggested solution: caching === In theory, it shouldn't be hard to store the result of rendering a page and serve subsequent requests for that page out of the cache. Adding support for conditional HTTP requests (If-None-Match and If-Modified-Since headers) at the same time could help to reduce the used bandwidth. The easiest way to handle cache updates would be to remove cached results when the corresponding page gets modified. Next time that page is requested, it is rendered (including the changes) and the result gets stored in the cache again. Caching might become a problem for really dynamic sections of a Trac site, such as the reports. But it should relieve the server for mostly-static parts, which - at least on madwifi.org - make the majority of the site. Another issue that should be considered is that pages could look different for different users - depending on their permissions. That could be solved in various ways, for example: * no caching for pages requested by a non-anonymous user * implement a per-user cache (needs to be wiped when permissions for a user are changed) * take the actual permissions into account when storing and retrieving pages to/from the cache Comments? = I'd be interested in comments on the sketched idea. Even more, it would be great if there was someone who would be interested in helping to implement it :) Bye, Mike -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iEYEARECAAYFAkXMFVMACgkQa3V7dXg8JKv1hACg2bJ3iq0UK7/two8zmxRfVlyV XXwAn29f2PkXb51iTAQNkalhGhLI3YFG =0K+W -END PGP SIGNATURE- --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: RFC: Caching for Trac
I've copied the Trac-dev list on this since it's a development issue. Please continue the discussion on that list. -- Matt Good On Feb 9, 1:31 am, Michael Renzmann [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all. As some of you might already know, I'm running the Trac installation on madwifi.org. We're happy with Trac, it's a great tool that we don't want to miss anymore. But there is one issue that we would like to see addressed: performance. Background == Our handicap is that the server that currently hosts madwifi.org a) hosts several sites b) has a slow CPU (P3-800) c) runs on Apache 2.0 with mpm_prefork and can not switch to, for example, mpm_worker - another site depends on mod_php, and mod_php doesn't like mpm_worker The site will move to a dedicated server soon, which should mitigate the performance issues we experience (as described below) a bit - no more mod_php, so mpm_worker will finally be possible. However, the available CPU power won't be much better: P3-850 instead of P3-800. Changing to a more powerful server is not (yet) possible due to a lack of money. We have to take what we get. The problem === For every request to a Trac-driven site, Trac has to render the content first. In case of a wiki page as an example that would be something like: get the markup for the page from the database and process it, getting the HTML tag soup as result that then is delivered to the requesting client. The more complex the source of a requested page is, the more CPU time is consumed by Trac to render it. An example for such a case is our compatibility list athttp://madwifi.org/wiki/Compatibility- if that page gets hit by several clients in parallel, the server is getting really slow. (Yes, I'm aware that reducing the complexity of the mentioned page will be a way to relieve the pain a bit, and actually that is work in progress - but that's not the point here :)). On the other hand, the majority of the frequently requested pages seem to be rarely changed. So the question for me is: why should Trac compute the same page over and over again when most of the time the result will be the same as for the last request? The suggested solution: caching === In theory, it shouldn't be hard to store the result of rendering a page and serve subsequent requests for that page out of the cache. Adding support for conditional HTTP requests (If-None-Match and If-Modified-Since headers) at the same time could help to reduce the used bandwidth. The easiest way to handle cache updates would be to remove cached results when the corresponding page gets modified. Next time that page is requested, it is rendered (including the changes) and the result gets stored in the cache again. Caching might become a problem for really dynamic sections of a Trac site, such as the reports. But it should relieve the server for mostly-static parts, which - at least on madwifi.org - make the majority of the site. Another issue that should be considered is that pages could look different for different users - depending on their permissions. That could be solved in various ways, for example: * no caching for pages requested by a non-anonymous user * implement a per-user cache (needs to be wiped when permissions for a user are changed) * take the actual permissions into account when storing and retrieving pages to/from the cache Comments? = I'd be interested in comments on the sketched idea. Even more, it would be great if there was someone who would be interested in helping to implement it :) Bye, Mike -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iEYEARECAAYFAkXMFVMACgkQa3V7dXg8JKv1hACg2bJ3iq0UK7/two8zmxRfVlyV XXwAn29f2PkXb51iTAQNkalhGhLI3YFG =0K+W -END PGP SIGNATURE- --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
