[Trac] Re: Some comments invisible to customers?
On Nov 3, 2008, at 1:05 AM, YitzG wrote: > > Is there any way currently - without developing a whole new > plugin - of marking some of the comments in an issue > as invisible to a group of users? > > The idea is that customers could post their own issues and > track them, but we would need to post internal comments > that the customer would not see. No, comments (really ticket changes) are not a resource of their own. This could be done in a plugin though. --Noah --~--~-~--~~~---~--~~ 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: Some comments invisible to customers?
- "YitzG" <[EMAIL PROTECTED]> wrote: > Is there any way currently - without developing a whole new > plugin - of marking some of the comments in an issue > as invisible to a group of users? > > The idea is that customers could post their own issues and > track them, but we would need to post internal comments > that the customer would not see. I too would like such a feature. RT has a feature where there were two kinds of updates: Comments and Replies. Replies were sent to the requester, and Comments were not. My use case is a bit different though. The users have been complaining about the Trac emails, and that they don't understand them. The issue is they get all of the emails about the commits, and developers comments. It would be great to be able to all of this as Comments. But then it would be a natural to have a permission level, where you can setup users to only see Replies, and not see Comments. > Thanks, > Yitz > Tom --~--~-~--~~~---~--~~ 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: removing own events from timeline view
Christian Boos <[EMAIL PROTECTED]> writes: > Olaf Meeuwissen wrote: >> I do the bulk of the work on a project so obviously most of the events >> in the timeline view are my own and events of other people drown in my >> noise. How would I only see other people's events in the timeline? > 0.12 introduces a user filter in the timeline. > I already thought about the feature you requested and think we could > extend this filter by accepting a list of users, and the possibility to > reject them. > > Examples on Trac: > - show me the changes done by Odd Simon and Remy: osimons rblank > - show me the changes ''not'' done by me: -cboos > > In the future, it would be good to accept group names there as well. Cool, but from your reply I understand that there is currently no way to achieve what I want. BTW, a number of other query constructs use ! for negation already and you may need to be careful about user names with special characters such as space and - (don't know what is currenty allowed, though). Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962 --~--~-~--~~~---~--~~ 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: issue w/ Apache+mod_wsgi+svn and multiple Trac instances
More comments below.
On Nov 4, 8:16 am, Graham Dumpleton <[EMAIL PROTECTED]>
wrote:
> On Nov 4, 6:16 am, Antti Kaihola <[EMAIL PROTECTED]> wrote:
>
>
>
> > I'm having the
> > "RuntimeError: instance.__dict__ not accessible in restricted mode"
> > problem mentioned in the FAQ and the TracSubversion wiki page.
> > However, this is onmod_wsgiinstead of mod_python. The software
> > versions are:
> > * Debian 4.0 Etch
> > * Apache 2.2.3
> > * Python 2.4.4
> > * Subversion 1.4.2
>
> > I'm running
> > * Trac instance "tracmain" with multiple Trac sites
> > * Trac instance "tracsingle" with a single Trac site
> > (which is one of the sites in instance "tracmain")
>
> > At first both Trac instances work fine, but after some time one of them
> > starts to fail with the runtime error.
>
> > Things I've tried:
> > * removing authentication directives temporarily from the Apache
> > settings
> > * mpm-prefork and mpm-worker
> > * same and different application group (also %{GLOBAL} for both)
> > * same and different process group
> > * same and different egg cache directory
>
> > After every change to the settings I always first stop then start
> > Apache. Nothing I've tried has made the problem go away yet.
>
> > I'm running out of ideas after reading through and trying all the
> > tricks mentioned in related Trac tickets,mod_wsgidocumentation and
> > mailing list messages.
>
> > Here is my configuration:
>
> > /etc/apache2/sites-available/tracmain
>
> >
> > ServerName trac.mydomain.com
> > WSGIDaemonProcess trac user=www-data group=www-data threads=25
> > WSGIScriptAlias / /var/lib/trac/apache/tracmain/trac.wsgi
>
> >
>
> Make it the directory the file is in, not the file itself.
>
> Graham
>
> > WSGIProcessGroup trac
> > WSGIApplicationGroup %{GLOBAL}
> > Order deny,allow
> > Allow from all
> >
>
> >
> > AuthType Basic
> > AuthName "Main Trac site"
> > AuthUserFile /var/lib/trac/users.htpasswd
> > Require valid-user
> >
>
> > LogLevel warn
> > CustomLog /var/log/apache2/tracmain.access.log combined
> > ServerSignature On
> >
>
> > /etc/apache2/sites-available/tracsingle
>
> >
> > ServerName tracsingle.mydomain.com
> > WSGIDaemonProcess tracsingle user=www-data group=www-data threads=25
> > WSGIScriptAlias / /var/lib/trac/apache/tracsingle/trac.wsgi
>
> >
Same again here.
> > WSGIProcessGroup trac
You meant 'tracsingle' not 'trac' for WSGIProcessGroup here, else not
in separate daemon process.
Graham
> > WSGIApplicationGroup %{GLOBAL}
> > Order deny,allow
> > Allow from all
> >
>
> >
> > AuthType Basic
> > AuthName "Trac Site"
> > AuthUserFile /var/lib/trac/users.htpasswd
> > Require valid-user
> >
>
> > LogLevel warn
> > CustomLog /var/log/apache2/tracsingle.access.log combined
> > ServerSignature On
> >
>
> > /var/lib/trac/apache/tracmain/trac.wsgi
>
> > import sys
> > sys.stdout = sys.stderr
> > import os
> > os.environ['PYTHON_EGG_CACHE'] = '/var/lib/trac/.python-eggs/tracmain'
> > import trac.web.main
>
> > def application(environ, start_response):
> > environ['trac.env_parent_dir'] = '/var/lib/trac'
> > return trac.web.main.dispatch_request(environ, start_response)
>
> > /var/lib/trac/apache/tracsingle/trac.wsgi
>
> > import sys
> > sys.stdout = sys.stderr
> > import os
> > os.environ['PYTHON_EGG_CACHE'] = '/var/lib/trac/.python-eggs/tracsingle'
> > import trac.web.main
>
> > def application(environ, start_response):
> > environ['trac.env_path'] = '/var/lib/trac/tracsingle'
> > return trac.web.main.dispatch_request(environ, start_response)
--~--~-~--~~~---~--~~
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: issue w/ Apache+mod_wsgi+svn and multiple Trac instances
On Nov 4, 6:16 am, Antti Kaihola <[EMAIL PROTECTED]> wrote:
> I'm having the
> "RuntimeError: instance.__dict__ not accessible in restricted mode"
> problem mentioned in the FAQ and the TracSubversion wiki page.
> However, this is onmod_wsgiinstead of mod_python. The software
> versions are:
> * Debian 4.0 Etch
> * Apache 2.2.3
> * Python 2.4.4
> * Subversion 1.4.2
>
> I'm running
> * Trac instance "tracmain" with multiple Trac sites
> * Trac instance "tracsingle" with a single Trac site
> (which is one of the sites in instance "tracmain")
>
> At first both Trac instances work fine, but after some time one of them
> starts to fail with the runtime error.
>
> Things I've tried:
> * removing authentication directives temporarily from the Apache
> settings
> * mpm-prefork and mpm-worker
> * same and different application group (also %{GLOBAL} for both)
> * same and different process group
> * same and different egg cache directory
>
> After every change to the settings I always first stop then start
> Apache. Nothing I've tried has made the problem go away yet.
>
> I'm running out of ideas after reading through and trying all the
> tricks mentioned in related Trac tickets,mod_wsgidocumentation and
> mailing list messages.
>
> Here is my configuration:
>
> /etc/apache2/sites-available/tracmain
>
>
> ServerName trac.mydomain.com
> WSGIDaemonProcess trac user=www-data group=www-data threads=25
> WSGIScriptAlias / /var/lib/trac/apache/tracmain/trac.wsgi
>
>
Make it the directory the file is in, not the file itself.
Graham
> WSGIProcessGroup trac
> WSGIApplicationGroup %{GLOBAL}
> Order deny,allow
> Allow from all
>
>
>
> AuthType Basic
> AuthName "Main Trac site"
> AuthUserFile /var/lib/trac/users.htpasswd
> Require valid-user
>
>
> LogLevel warn
> CustomLog /var/log/apache2/tracmain.access.log combined
> ServerSignature On
>
>
> /etc/apache2/sites-available/tracsingle
>
>
> ServerName tracsingle.mydomain.com
> WSGIDaemonProcess tracsingle user=www-data group=www-data threads=25
> WSGIScriptAlias / /var/lib/trac/apache/tracsingle/trac.wsgi
>
>
> WSGIProcessGroup trac
> WSGIApplicationGroup %{GLOBAL}
> Order deny,allow
> Allow from all
>
>
>
> AuthType Basic
> AuthName "Trac Site"
> AuthUserFile /var/lib/trac/users.htpasswd
> Require valid-user
>
>
> LogLevel warn
> CustomLog /var/log/apache2/tracsingle.access.log combined
> ServerSignature On
>
>
> /var/lib/trac/apache/tracmain/trac.wsgi
>
> import sys
> sys.stdout = sys.stderr
> import os
> os.environ['PYTHON_EGG_CACHE'] = '/var/lib/trac/.python-eggs/tracmain'
> import trac.web.main
>
> def application(environ, start_response):
> environ['trac.env_parent_dir'] = '/var/lib/trac'
> return trac.web.main.dispatch_request(environ, start_response)
>
> /var/lib/trac/apache/tracsingle/trac.wsgi
>
> import sys
> sys.stdout = sys.stderr
> import os
> os.environ['PYTHON_EGG_CACHE'] = '/var/lib/trac/.python-eggs/tracsingle'
> import trac.web.main
>
> def application(environ, start_response):
> environ['trac.env_path'] = '/var/lib/trac/tracsingle'
> return trac.web.main.dispatch_request(environ, start_response)
--~--~-~--~~~---~--~~
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: problem upgrading plugin to 0.11 - TypeError: can't compare
.M. wrote: > > Hi > > Can I get some help upgrading my plugin to trac 0.11 from trac 0.10? > > I'm getting this error - TypeError: can't compare datetime.datetime to > int > > Not sure where to change type in this case and unclear what the > revised API is doing now that requires this. As of 0.11 Trac internally only deals with timestamps as real datetime objects instead of integers. So whenever you're fetching a timestamp from the database you'll need to convert it into a datetime object like this: from trac.util.datefmt import utc from datetime import datetime date = datetime.fromtimestamp(ts, utc) / Jonas --~--~-~--~~~---~--~~ 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: Migration form svn 1.4 + Trac 0.10.4 to svn 1.5 + Trac 0.11.1.
On Mon, Nov 03, 2008 at 06:35:44AM -0800, Martin S. wrote: > On Nov 3, 2:04 pm, Greg Troxel <[EMAIL PROTECTED]> wrote: > > Upgrading subversion was trivial. I just instructed the packaging > > system (pkgsrc) to rebuild subversion and everything that depended on > > it, and I didn't have to do anything else. > You didn't upgraded the repositories? > I thought when upgrading from svn 1.4 to 1.5 you should do this. It is not mandatory, but if you want to benefit from the new directory structure that was introduced with 1.5, one would have to follow your next phrase: > It can be done by dumping the old one and loading the dumpfile to an > new empty 1.5 repositories. 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] issue w/ Apache+mod_wsgi+svn and multiple Trac instances
I'm having the
"RuntimeError: instance.__dict__ not accessible in restricted mode"
problem mentioned in the FAQ and the TracSubversion wiki page.
However, this is on mod_wsgi instead of mod_python. The software
versions are:
* Debian 4.0 Etch
* Apache 2.2.3
* Python 2.4.4
* Subversion 1.4.2
I'm running
* Trac instance "tracmain" with multiple Trac sites
* Trac instance "tracsingle" with a single Trac site
(which is one of the sites in instance "tracmain")
At first both Trac instances work fine, but after some time one of them
starts to fail with the runtime error.
Things I've tried:
* removing authentication directives temporarily from the Apache
settings
* mpm-prefork and mpm-worker
* same and different application group (also %{GLOBAL} for both)
* same and different process group
* same and different egg cache directory
After every change to the settings I always first stop then start
Apache. Nothing I've tried has made the problem go away yet.
I'm running out of ideas after reading through and trying all the
tricks mentioned in related Trac tickets, mod_wsgi documentation and
mailing list messages.
Here is my configuration:
/etc/apache2/sites-available/tracmain
ServerName trac.mydomain.com
WSGIDaemonProcess trac user=www-data group=www-data threads=25
WSGIScriptAlias / /var/lib/trac/apache/tracmain/trac.wsgi
WSGIProcessGroup trac
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
AuthType Basic
AuthName "Main Trac site"
AuthUserFile /var/lib/trac/users.htpasswd
Require valid-user
LogLevel warn
CustomLog /var/log/apache2/tracmain.access.log combined
ServerSignature On
/etc/apache2/sites-available/tracsingle
ServerName tracsingle.mydomain.com
WSGIDaemonProcess tracsingle user=www-data group=www-data threads=25
WSGIScriptAlias / /var/lib/trac/apache/tracsingle/trac.wsgi
WSGIProcessGroup trac
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
AuthType Basic
AuthName "Trac Site"
AuthUserFile /var/lib/trac/users.htpasswd
Require valid-user
LogLevel warn
CustomLog /var/log/apache2/tracsingle.access.log combined
ServerSignature On
/var/lib/trac/apache/tracmain/trac.wsgi
import sys
sys.stdout = sys.stderr
import os
os.environ['PYTHON_EGG_CACHE'] = '/var/lib/trac/.python-eggs/tracmain'
import trac.web.main
def application(environ, start_response):
environ['trac.env_parent_dir'] = '/var/lib/trac'
return trac.web.main.dispatch_request(environ, start_response)
/var/lib/trac/apache/tracsingle/trac.wsgi
import sys
sys.stdout = sys.stderr
import os
os.environ['PYTHON_EGG_CACHE'] = '/var/lib/trac/.python-eggs/tracsingle'
import trac.web.main
def application(environ, start_response):
environ['trac.env_path'] = '/var/lib/trac/tracsingle'
return trac.web.main.dispatch_request(environ, start_response)
--~--~-~--~~~---~--~~
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] import from CSV
Has anyone by any chance wrote a script to import a simple list of bugs from a CSV file to Trac? I just want to avoid multiple copy +paste, no history required. Thanks, Noam. --~--~-~--~~~---~--~~ 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: Migration form svn 1.4 + Trac 0.10.4 to svn 1.5 + Trac 0.11.1.
"Martin S." <[EMAIL PROTECTED]> writes: > On Nov 3, 2:04 pm, Greg Troxel <[EMAIL PROTECTED]> wrote: >> Upgrading subversion was trivial. I just instructed the packaging >> system (pkgsrc) to rebuild subversion and everything that depended on >> it, and I didn't have to do anything else. > You didn't upgraded the repositories? > I thought when upgrading from svn 1.4 to 1.5 you should do this. > It can be done by dumping the old one and loading the dumpfile to an > new empty 1.5 repositories. > Config files and hook scripts must be copied manually and you should > set the UUID to the old value. I definitely did not dump/restore, but now that you mention it I probably did 'svnadmin upgrade'. pgpwQC6tUmGDa.pgp Description: PGP signature
[Trac] Re: Migration form svn 1.4 + Trac 0.10.4 to svn 1.5 + Trac 0.11.1.
On Nov 3, 2:04 pm, Greg Troxel <[EMAIL PROTECTED]> wrote: > Upgrading subversion was trivial. I just instructed the packaging > system (pkgsrc) to rebuild subversion and everything that depended on > it, and I didn't have to do anything else. You didn't upgraded the repositories? I thought when upgrading from svn 1.4 to 1.5 you should do this. It can be done by dumping the old one and loading the dumpfile to an new empty 1.5 repositories. Config files and hook scripts must be copied manually and you should set the UUID to the old value. Martin --~--~-~--~~~---~--~~ 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: Migration form svn 1.4 + Trac 0.10.4 to svn 1.5 + Trac 0.11.1.
[EMAIL PROTECTED] writes: > I have a production server with svn 1.4 plus trac 0.10.4. > I wolud like to migrate to svn 1.5 + Trac 0.11.1. I plan to setup another > server (test) with 1.5 + 0.11.1, migrate all the data and then switch the > two machine. > > Do you think it's a good idea or it is better to upgrade the already > running server ? > Or use another procedure ? I have done that upgrade, but in two steps. I don't remember the order, but I did them separately because I felt comfortable about each at different times, not because of any reason about the combination. Upgrading subversion was trivial. I just instructed the packaging system (pkgsrc) to rebuild subversion and everything that depended on it, and I didn't have to do anything else. For trac, I let the packaging system upgrade trac, and then ran the basic and wiki upgrade commands. I did make extra backups before starting. This was uneventful, except that I had to add --no-backup because I'm using the postgresql backend. So it really depends on how production your production server is. I have about 50 users of whom maybe 10-15 would be put out by a few hours of downtime, and the upgrade-in-place plan was good enough for me. If you do use a second machine, I'd clone the first one and upgrade it, writing down your procedure carefully, and then execute the procedure on the first one. Switching machines means you have to make sure the databases are in sync, and it seems safer to upgrade the real one. pgp863sOpavO5.pgp Description: PGP signature
[Trac] problem upgrading plugin to 0.11 - TypeError: can't compare datetime.datetime to int
Hi Can I get some help upgrading my plugin to trac 0.11 from trac 0.10? I'm getting this error - TypeError: can't compare datetime.datetime to int Not sure where to change type in this case and unclear what the revised API is doing now that requires this. As per the following : http://paste.turbogears.org/paste/11990 My plug overrides the ticket system and search to return the summary field in the results so I can display this in a custom search.html template. Thanks in advance. .M. --~--~-~--~~~---~--~~ 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: Produce unique HTML tag id in macro
On Oct 30, 11:54 am, "Martin S." <[EMAIL PROTECTED]> wrote: > Otherwise, I could create a global array of function pointers and let > every macro push an function reference in it, which is then executed > like this: I implemented this now for the GoogleMapMacro and it works quite nice. Martin --~--~-~--~~~---~--~~ 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] Some comments invisible to customers?
Is there any way currently - without developing a whole new plugin - of marking some of the comments in an issue as invisible to a group of users? The idea is that customers could post their own issues and track them, but we would need to post internal comments that the customer would not see. Thanks, Yitz --~--~-~--~~~---~--~~ 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] Migration form svn 1.4 + Trac 0.10.4 to svn 1.5 + Trac 0.11.1.
Hi all, I have a production server with svn 1.4 plus trac 0.10.4. I wolud like to migrate to svn 1.5 + Trac 0.11.1. I plan to setup another server (test) with 1.5 + 0.11.1, migrate all the data and then switch the two machine. Do you think it's a good idea or it is better to upgrade the already running server ? Or use another procedure ? Any suggestion ? TIA Alberto Giordano Informativa sul trattamento dei dati personali (D. Lgs. 196/2003). I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Gefran S.p.A., titolare del trattamento, per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi. Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
