[Trac] Re: Automatic Ticket creation
It might be useful to have standard http POST request to create tickets, the simple gate for automation. It should be simpler than XML RPC, and won't depend on the any ticket API changes and DB backend. I suppose that generating http POST is fairly simple regardless of the system used. It could use registered account credentials to avoid spam. -Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Erik Bray Sent: Wednesday, August 22, 2007 6:13 PM To: trac-users@googlegroups.com Subject: [Trac] Re: Automatic Ticket creation On 8/22/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Sue <[EMAIL PROTECTED]> wrote: > > thru the documentation but did not find anything about this other than > > some really old question regarding a similar issue. Is there a way to > > do this in a more elegant manner rather than interacting with the Trac > > sqLite database directly thru some script? If this is the only way, > > any pointers to existing database interaction documentation would be > > great. > > Well, don't use sqlite, use mysql ot postgres, since they support good > multiuser access, and then write whatever CGI,ruby,django/etc. code you need to populate the > database. > I don't see what exactly the question has to do with which DB to use or whether or not it needs to have multi-user access. On the other hand, it's not entirely clear what you're asking for. > I would like to create trac tickets automatically whenever a particular event happens. What sort of event? This is the part that's unclear. Is it an event in the Trac environment? Or something external. Regardless, using the Trac API, it's very easy to open an environment and create a ticket--depending on what you need to do, it could be a very short Python script. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- smime.p7s Description: S/MIME cryptographic signature
[Trac] Re: issue of concurrency in the trac wiki
- something like this would be really helpful. -Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Ben Wilson Sent: Tuesday, August 14, 2007 9:02 PM To: trac-users@googlegroups.com Subject: [Trac] Re: issue of concurrency in the trac wiki PmWiki does a sort of RCS-style conflict notification. That is, when subsequent editors save the page, it detects the error (by storing the mtime of the page when called to edit and comparing the mtime of the page at post back) and then returns the page to be edited with changes flagged with '>>' and '<<'. The subsequent editor then has the option to merge, delete or post the page with the conflict in place. On 8/13/07, Aaron D. Marasco <[EMAIL PROTECTED]> wrote: > We wrote a quick and dirty macro that does the equivalent of Wikipedia's > InUse... That seems to be OK for our small group. > > - Aaron > > http://en.wikipedia.org/wiki/Template%3AInuse > > > > > -- Ben Wilson "Words are the only thing which will last forever" Churchill --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- smime.p7s Description: S/MIME cryptographic signature
[Trac] Re: НА: [Trac] Re: issue of concurrency in the trac wiki
Don't think so. From my own experience, long pages, with multiple headings/topics most often need to be edited as a whole. Usual practice is to put isolated metarial to the linked wiki pages. So, having to edit each section separately might become painful. My experience is to keep page sizes within reasonable limits ant splitting them as they grow. Anyway, merging is simple to implement, elegant and complete solution for the case. Even simple, line-based diff-like merge, that could be implemented in a few hours, will close the issue. So far I've got a silly habbit to copy all the text to the clipboard before pushing submit :) -Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Filipe Correia Sent: Tuesday, August 14, 2007 4:49 PM To: Trac Users Subject: [Trac] Re: НА: [Trac] Re: issue of concurrency in the trac wiki I believe merging will be less needed when this ticket is implemented: http://trac.edgewall.org/ticket/1024 Even if merges are still needed afterwards, I think they will probably bring much lesser problems. -- Filipe Correia On Aug 14, 1:02 am, Noah Kantrowitz <[EMAIL PROTECTED]> wrote: > Possible, yes. Mind-numbingly difficult, also yes. Branch/merge > algorithms are one of the fields of computer science currently under > a huge amount of scrutiny. Writing a decent document merge system is > a thesis-level project (and I know someone doing just that). > > --Noah > > On Aug 13, 2007, at 7:53 PM, Sergey Chernov wrote: > > > > > Btw it could try to merge edits and let last editor to manually > > edit conflictis; e.g something like the svn. Much better than just > > discarding all the editing. And doesn't seem too hard to code anyway. > > > - Исходное сообщение - > > От: Noah Kantrowitz <[EMAIL PROTECTED]> > > Отправлено: 13 августа 2007 г. 22:15 > > Кому: trac-users@googlegroups.com > > Тема: [Trac] Re: issue of concurrency in the trac wiki > > > Yes, the second (and subsequent) edits to the same base version will > > fail with an error. This is not a terribly good system, but it does > > at least prevent rollback edit glitches. > > > --Noah > > > On Aug 13, 2007, at 1:50 PM, [EMAIL PROTECTED] wrote: > > >> Folks, > > >> Has anyone dealt with the issue of concurrency in the trac wiki ? > >> Is there a "locking" mechanism available or at least a warning so > >> simultaneous sessions do not bonk one another ? > > >> Thanks ! > > >> Best Regards, > > >> Joe > > >> Joseph H. Dayney > >> Contract Software Engineer > >> Excel Resources > >> AppDev Team > > >> 435.755.4278 Office > >> 801.608.1052 Cell > >> 435.755.4210 Fax > >> 801-272-6615 SLC Home > >> [EMAIL PROTECTED] > > >> Moore Wallace, An RR Donnelly Company > >> 630 W 1000 N > >> Logan, UT 84321 > > >> CONFIDENTIALITY NOTICE: The information contained in this email > >> message is confidential and may be protected from disclosure. > >> Please be aware that any unauthorized use, printing, copying, > >> disclosure or dissemination of this communication may be subject to > >> legal restriction or sanction. If you think you have received this > >> email message in error, please reply to sender. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- smime.p7s Description: S/MIME cryptographic signature
[Trac] НА: [Trac] Re: issue of concurrency in the trac wiki
Btw it could try to merge edits and let last editor to manually edit conflictis; e.g something like the svn. Much better than just discarding all the editing. And doesn't seem too hard to code anyway. - Исходное сообщение - От: Noah Kantrowitz <[EMAIL PROTECTED]> Отправлено: 13 августа 2007 г. 22:15 Кому: trac-users@googlegroups.com Тема: [Trac] Re: issue of concurrency in the trac wiki Yes, the second (and subsequent) edits to the same base version will fail with an error. This is not a terribly good system, but it does at least prevent rollback edit glitches. --Noah On Aug 13, 2007, at 1:50 PM, [EMAIL PROTECTED] wrote: > > Folks, > > Has anyone dealt with the issue of concurrency in the trac wiki ? > Is there a "locking" mechanism available or at least a warning so > simultaneous sessions do not bonk one another ? > > Thanks ! > > > Best Regards, > > Joe > > Joseph H. Dayney > Contract Software Engineer > Excel Resources > AppDev Team > > 435.755.4278 Office > 801.608.1052 Cell > 435.755.4210 Fax > 801-272-6615 SLC Home > [EMAIL PROTECTED] > > Moore Wallace, An RR Donnelly Company > 630 W 1000 N > Logan, UT 84321 > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this email > message is confidential and may be protected from disclosure. > Please be aware that any unauthorized use, printing, copying, > disclosure or dissemination of this communication may be subject to > legal restriction or sanction. If you think you have received this > email message in error, please reply to sender. > > --~--~-~--~~~---~--~~ 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: Russian (ru_RU) translation
I've done the translation but can't add is as a patch to the #5478 due to #5848. Where should I send the patch? Btw there are some question about it, where is a proper place for the discussion concerning the translation? -Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jeroen Ruigrok van der Werven Sent: Monday, July 16, 2007 7:03 PM To: trac-users@googlegroups.com Subject: [Trac] Russian (ru_RU) translation Privet, I have added a first attempt for a Russian translation for Trac in the i18n sandbox. Parts of it are based on the TracTermsRu page and the rest I tried to fill in as well as I was able to. I would appreciate it if people could look at http://trac.edgewall.org/browser/sandbox/i18n/trac/locale/ru_RU/LC_MESSAGES/messages.po Please attach any patches/diffs to the appropriate ticket: http://trac.edgewall.org/ticket/5478 Apologies for the mistakes I will have made in that file. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ You're just like a vapor, that appears for a little while and vanishes one day... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- smime.p7s Description: S/MIME cryptographic signature
[Trac] НА: [Trac] Re: Workflow patch by PV: se t_owner_to_reporter
+1
- Исходное сообщение -
От: Morris <[EMAIL PROTECTED]>
Отправлено: 11 августа 2007 г. 1:00
Кому: Trac Users
Тема: [Trac] Re: Workflow patch by PV: set_owner_to_reporter
+1
On Aug 10, 9:08 am, "Erik Andersson" <[EMAIL PROTECTED]> wrote:
> I did an addition as well:
>
> Index: default_workflow.py
> ===
> --- default_workflow.py (revision 5898)
> +++ default_workflow.py (working copy)
> @@ -226,6 +226,8 @@
> for x in owners],
> id=id, name=id)]))
> hints.append(_("The owner will change"))
> +if 'set_owner_to_reporter' in operations:
> +hints.append(_("The owner will change to %s") %
> ticket['reporter'])
> if 'set_owner_to_self' in operations:
> hints.append(_("The owner will change to %s") % req.authname)
> if 'set_resolution' in operations:
> @@ -282,6 +284,11 @@
> if type(newowner) == list:
> newowner = newowner[0]
> updated['owner'] = newowner
> +elif operation == 'set_owner_to_reporter':
> +if ticket['reporter']:
> +updated['owner'] = ticket['reporter']
> +else:
> +updated['owner'] = ''
> elif operation == 'set_owner_to_self':
> updated['owner'] = req.authname
>
> Cheers / Erik
>
> On 8/10/07, Russ Brown <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > Erik Andersson wrote:
> > > Hi
>
> > > I'd already found the need for and implemented this locally.
>
> > > I'm +1 for adding this as soon as possible!
>
> > > /Erik
>
> > Another vote for this one. This is exactly how we use tickets too.
>
> > > On 7/31/07, *cobwebsmasher* <[EMAIL PROTECTED]
> > > > wrote:
>
> > > Hi. I'd like to submit this patch to the Trac development team,
> > > presuming it's actually useful (or still not addressed) but don't
> > > know how, so I'm hoping this is useful.
>
> > > The use case is when you want a ticket to be assigned to original
> > > reporter. Our company uses this as a enforced QA step. i.e. if you
> > > created the ticket, then you're on the hook to close the ticket.
>
> > > This would be at or around line 279 on the file:
> > > ticket/default_workflow.py
>
> > > 279 elif operation == 'set_owner_to_reporter':
> > > 280 if ticket['reporter']:
[Включен не весь текст исходного сообщения]
--~--~-~--~~~---~--~~
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] НА: [Trac] Re: HTML tags: title, head, bod y
Try javascript
- Исходное сообщение -
От: jtuchscherer <[EMAIL PROTECTED]>
Отправлено: 27 июля 2007 г. 23:16
Кому: Trac Users
Тема: [Trac] Re: HTML tags: title, head, body
As far as I understand you can use HTML markup language to structure
your text, but you cannot create a new HTML page with header and body
tags within you wiki page.
Just remember that you are already looking at a website that already
has a header with title defined. Within your website you cannot create
another website if you want to write valid HTML.
HTH,
Johannes
On Jul 27, 12:10 pm, Martin H <[EMAIL PROTECTED]> wrote:
> Noah, First of all, thanks for the answer.
>
> What do you mean with blocks?
>
> {{{
> #!html
> Virtual Library}}}
>
> doesn't work at well
>
> On Jul 27, 3:02 pm, Noah Kantrowitz <[EMAIL PROTECTED]> wrote:
>
> > That wouldn't be valid HTML anyway. Trac filters HTML in those blocks
> > to prevent abuse (XSS attacks, etc etc).
>
> > --Noah
>
> > On Jul 27, 2007, at 1:45 PM, Martin H wrote:
>
> > > Hello,
> > > I was just trying HTML in my trac wiki pages.
> > > For example, this example given in WikiHTML works
>
> > > {{{
> > > #!html
> > > HTML Test
> > > }}}
>
> > >But i tried adding the title, head, body tags and it doesn't work:
>
> > > {{{
> > > #!html
> > >
> > > Virtual Library
> > >
> > >
> > > Moved to http://example.org/";>example.org.
> > >
> > > }}}
>
> > > any ideas?
>
> > > Thanks!!
> > > 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: Russian (ru_RU) translation
Is there anybody already doing the translation - most strings are empty? I could do it but don’t want to duplicate somebody other's effort. -Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jeroen Ruigrok van der Werven Sent: Monday, July 16, 2007 7:03 PM To: trac-users@googlegroups.com Subject: [Trac] Russian (ru_RU) translation Privet, I have added a first attempt for a Russian translation for Trac in the i18n sandbox. Parts of it are based on the TracTermsRu page and the rest I tried to fill in as well as I was able to. I would appreciate it if people could look at http://trac.edgewall.org/browser/sandbox/i18n/trac/locale/ru_RU/LC_MESSAGES/messages.po Please attach any patches/diffs to the appropriate ticket: http://trac.edgewall.org/ticket/5478 Apologies for the mistakes I will have made in that file. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ You're just like a vapor, that appears for a little while and vanishes one day... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- smime.p7s Description: S/MIME cryptographic signature
[Trac] Re: Ticket creation|modification is very slow
Reconfigured reverse DNS. It works: > host 195.96.190.174 174.190.96.195.in-addr.arpa domain name pointer dev.tancher.ru. 174.190.96.195.in-addr.arpa domain name pointer office.tancher.com. > - Still pauses for 30s when changing/submitting ticket. Any clue why? From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Sergey Chernov Sent: Wednesday, June 27, 2007 4:56 PM To: trac-users@googlegroups.com Subject: [Trac] Ticket creation|modification is very slow Since along while I'm experiencing a trouble when creating/changing tickets on my site (Trac 0.10.(4?), FreeBSD, sqlite, mod_python). Each time I create or update the ticket, it freezes for about 31s (local network), while preview changes, adding/changing wiki pages, etc. works with no delay at all. At the point we're working a lot with tickets so that becomes real trouble. We're using trac since 0.9 and I can't tell when it start to happen, but there was no such problem before. We use email notifications and it works fine. Log shows nothing unusual. Any hints? smime.p7s Description: S/MIME cryptographic signature
[Trac] ??: [Trac] Installing Trac using FastCGI in a shared hosting environment
- ?-
??: "Eric Anderson" <[EMAIL PROTECTED]>
: "Trac Users"
??: 28.06.07 5:55
: [Trac] Installing Trac using FastCGI in a shared hosting environment
Not sure if this is the right place to post a installation question so
please tell me where to post if this is the wrong place.
I am trying to install the latest stable version of Trac on my shared
hosting environment (Site5 to be specific). My basic steps were:
1. Download Trac
2. Run the install with the --prefix option to install in a directory
I can manage
3. Download ClearSilver
4. Install with the --prefix option to install where I desire
5. Create a Trac environment for my project
Now at this point I can run tracd and I have a working installation of
Trac. But I would like to make trac use Apache/FastCGI instead of
tracd but at least I know it is basically working. I'm attempting
plain CGI first before I throw in FastCGI to the mix.
To get tracd working all I had to do was update my PYTHONPATH to
include the libraries installed for trac and update my LD_LIBRARY_PATH
to include the ClearSilver libraries. So my assumption is the CGI
needs the same environment variables set so it can find the necessary
libraries. So I my next steps are:
1. Symlink the directories my webserver looks loads to the htdocs and
cgi-bin directory in trac. That way the resources and scripts are
available.
2. Create a .htaccess file that looks like the following so that
trac.cgi is always run unless a resource requested exists:
###
AddHandler fastcgi-script .fcgi
AddHandler cgi-script .cgi
Options +FollowSymLinks +ExecCGI
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ cgi-bin/trac.cgi [QSA,L]
###
The .htaccess file was mostly borrowed from the way rails redirects to
it's dispatch file. This may be overkill and I may just need to
redirect a request for / to cgi-bin/trac.cgi.
3. Added the following to start of trac.cgi so the environment
variables are set right:
##
import os
os.environ['LD_LIBRARY_PATH'] = "/home/pix/lib/clearsilver/lib"
os.environ['PYTHONPATH'] = "/home/pix/apps/trac/lib/python2.4/site-
packages:/home/pix/lib/clearsilver/lib:/usr/lib/python2.3/site-
--~--~-~--~~~---~--~~
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: Ticket creation|modification is very slow
Thanks. I think it is, but I need these notifications bad. Any idea how to put notifications into separated thread? -Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Emmanuel Blot Sent: Wednesday, June 27, 2007 5:32 PM To: trac-users@googlegroups.com Subject: [Trac] Re: Ticket creation|modification is very slow > We use email notifications and it works fine. I would say: disable notifications and try again. It is likely that the trouble comes from a SMTP connection issue. HTH, Manu --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- smime.p7s Description: S/MIME cryptographic signature
[Trac] Ticket creation|modification is very slow
Since along while I'm experiencing a trouble when creating/changing tickets on my site (Trac 0.10.(4?), FreeBSD, sqlite, mod_python). Each time I create or update the ticket, it freezes for about 31s (local network), while preview changes, adding/changing wiki pages, etc. works with no delay at all. At the point we're working a lot with tickets so that becomes real trouble. We're using trac since 0.9 and I can't tell when it start to happen, but there was no such problem before. We use email notifications and it works fine. Log shows nothing unusual. Any hints? smime.p7s Description: S/MIME cryptographic signature
