Re: [Trac] Upgrading 1.0 to 1.4 - ChildTicketsPlugin

[Peter Suter]

On 17 May 2023 15:55, Frank R. wrote:
That's what I found out. And it was plugin TracDynamicVariables. 
Deactivating that plugin and the error was gone. But I don't remember 
or know whether other plugins do need this plugin... maybe my sneaky 
feeling prove true, because I now get


TypeError: childtickets() takes exactly 2 arguments (1 given)


(I would recommend new threads for new problems, and always include the 
full error message and related plugin versions etc.)


This error seems to  match the one in https://trac-hacks.org/ticket/13088
so you probably have a very old ChildTicketsPlugin and need the newer 
version mentioned there.


--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/trac-users/532c35dc-947d-83cf-73cc-70f937dddab6%40gmail.com.

Re: [Trac] "Notify: Any ticket changes" seems to have disappeared from Notification Preferences

[Peter Suter]

As far a I remember 1.0.3 had no such notification preferences, unless 
you used the Announcer plugin.
1.4.3 replaces most of that plugin with built-in functionality, and 
indeed has that example but confusingly that rule was never added.


You can add such a rule yourself though. See
https://trac.edgewall.org/ticket/4056#comment:40
https://trac.edgewall.org/browser/psuter.hg/tracopt/notification/all_tickets.py?rev=10400=20%2C44#L20
https://trac.edgewall.org/wiki/CookBook/Notification/Subscriptions#Subscribetoallticketnotifications


On 15 Apr 2023 03:29, Rick Macdonald wrote:


I've upgraded from 1.0.3 to 1.4.3. I'm pretty sure there used to be an 
optional rule in user Preferences for Notification rules to be 
notified of "Any ticket changes". This option is no longer in the list 
of available rules, but the comment below the configured default rules 
still shows:


Example: The rule *"Never notify: I update a ticket"* should be above 
*"Notify: Any ticket changes"* to get notifications of any ticket 
changes except when you update a ticket.


What am I missing?


--
You received this message because you are subscribed to the Google 
Groups "Trac Users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to trac-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/trac-users/6bc390b7-9964-4d5f-b6c0-e36165f3daafn%40googlegroups.com 
.


--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/trac-users/a29bce89-e08f-2b4c-6da5-ff5c1043af12%40gmail.com.

Re: [Trac] Re: e-mail notifications in Trac 1.5dev

[Peter Suter]

On 21 Sep 2022 16:07, Roger Oberholtzer wrote:

On Tue, Sep 20, 2022 at 6:45 PM Peter Suter  wrote:

Are the EmailDistributor and TicketFormatter components enabled?

At first I read this as that these were things to add and enable. I
missed that they were Trac components.

Well, this is embarrassing. It seems that when I disabled the
Announcer plugin, I failed to enable EmailDistributor in Trac. Now I
see this in the log:

2022-09-21 11:12:38,135 Trac[api] DEBUG: Adding (roger [1]) for
'always' on rule (TicketOwnerSubscriber) for (email)
2022-09-21 11:12:38,136 Trac[api] DEBUG: Adding (ssma [1]) for
'always' on rule (TicketPreviousUpdatersSubscriber) for (email)
2022-09-21 11:12:38,136 Trac[mail] DEBUG: EmailDistributor has found
the following formats capable of handling 'email' of 'ticket':
text/plain
2022-09-21 11:12:38,136 Trac[mail] DEBUG: EmailDistributor format
text/html not available for email ticket
2022-09-21 11:12:38,206 Trac[mail] DEBUG: EmailDistributor is sending
event as 'text/plain' to: s...@somewhere.com
2022-09-21 11:12:38,213 Trac[mail] INFO: Sending notification through
SMTP at smtp.somewhere.com:25 to ['s...@somewhere.com']

Anyway, e-mail notifications are working. False alarm.

--
Roger Oberholtzer


Right, I assume those are usually enabled by default, but I don't 
remember if new components get enabled when upgrading.
Maybe you could add a hint to 
https://trac.edgewall.org/wiki/TracNotification#Troubleshooting
I guess maybe a check could somehow be added to Trac to log a warning 
when a notification is not sent because no distributor is available.


--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/trac-users/8b7532c4-3ac6-3b87-b8e8-bf9d189eed97%40gmail.com.

Re: [Trac] Re: e-mail notifications in Trac 1.5dev

[Peter Suter]

On 20 Sep 2022 14:41, Roger Oberholtzer wrote:

On Mon, Sep 12, 2022 at 1:43 PM Peter Suter  wrote:

Hi,
Just FYI Trac ~1.2+ has a lot of the Announcer plugin functionality
integrated in core, and provides its own "new" extension interfaces.
Joinable groups were prepared here:
https://trac.edgewall.org/wiki/TracDev/Proposals/AdvancedNotification#Advancedsubscriptions
https://trac.edgewall.org/changeset/ad2174686247456fb9b6ec3cd97506b863828ca8/psuter.hg/
https://trac.edgewall.org/ticket/11870
but never finalized. Nobody seemed really interested in this feature.
This is the first time I see it mentioned by anyone.

The Announcer plugin could also provide these optional features based on
the core interfaces, but nobody seems to have been interested in doing
this so far:
https://trac-hacks.org/ticket/12120

I'm not sure what the overall goal is with "@Tickets", that is not
already solved by subscribing to tickets in the default notification
preferences.
https://trac.edgewall.org/prefs/notification
https://trac.edgewall.org/wiki/TracNotification#SubscriberConfiguration
https://trac.edgewall.org/wiki/CookBook/Notification/Subscriptions

Cheers,
Peter

On 12 Sep 2022 12:13, Roger Oberholtzer wrote:

On Mon, Sep 12, 2022 at 10:11 AM Roger Oberholtzer
  wrote:

In Trac 1.2, say, I could define an e-mail tag called @Tickets, and
all that have subscribed to Tickets in their notifications would get
e-mails when appropriate.

I have updated to Trac 1.5dev, and I get this when e-mail should be sent:

2022-09-12 10:05:29,561 Trac[mail] DEBUG: Invalid email address: @Tickets
2022-09-12 10:05:29,561 Trac[api] DEBUG: Adding (roger [1]) for
'always' on rule (TicketUpdaterSubscriber) for (email)


The first line is the issue. The second implies that I will still be
added to the list of recipients. However, no e-mail is sent. How best
to proceed?

I see that this was set up in the announcer plugin as follows:

[announcer]
joinable_groups = Tickets

But that seems not to be Python3 ready.

2022-09-12 12:02:56,771 Trac[loader] ERROR: Skipping
"announcer.distributors.mail = announcer.distributors.mail":
ModuleNotFoundError: No module named 'Queue'
2022-09-12 12:02:56,814 Trac[loader] ERROR: Skipping
"announcer.email_decorators = announcer.email_decorators":
ModuleNotFoundError: No module named 'Queue'
2022-09-12 12:02:56,968 Trac[loader] ERROR: Skipping "announcer.pref =
announcer.pref": ImportError: cannot import name
'ITemplateStreamFilter' from 'trac.web.api'
(/usr/lib/python3.10/site-packages/Trac-1.5.4.dev0-py3.10.egg/trac/web/api.py)


   I will see what I can do.

I have removed using the Announcer plugin. I will try to get the
notifications working in just Trac and see where that gets me.

I have removed the @Tickets group from the Cc field. So the tickets I
am testing this with are rather straight forward. No Cc at all.

When I change a ticket, for example, I see this in the log (DEBUG level):

  Trac[api] DEBUG: Adding (roger [1]) for 'always' on rule
(TicketOwnerSubscriber) for (email)
  Trac[api] DEBUG: Adding (ssma [1]) for 'always' on rule
(TicketPreviousUpdatersSubscriber) for (email)

That looks reasonable. These users should get a notification.

However, nothing happens. I have this configuration, which looks
reasonable to me.


[notification]
admit_domains =
always_notify_owner = true
always_notify_reporter = true
always_notify_updater = true
email_sender = SmtpEmailSender
ignore_domains =
mime_encoding = base64
smtp_default_domain =
smtp_enabled = enabled
smtp_from =t...@systems.rst.ramboll.se
smtp_from_author = disabled
smtp_from_name = Do Not Reply
smtp_replyto = trac@localhost
smtp_server = smtp.somewherel.com
ticket_subject_template = ${prefix} #${ticket.id}: ${summary}
use_public_cc = enabled
use_short_addr = disabled
use_tls = disabled

[notification-subscriber]
always_notify_cc = CarbonCopySubscriber
always_notify_new_ticket = NewTicketSubscriber
always_notify_owner = TicketOwnerSubscriber
always_notify_previous_updater = TicketPreviousUpdatersSubscriber
always_notify_reporter = TicketReporterSubscriber
always_notify_updater = TicketUpdaterSubscriber


The SMTP server is the same one I used with Trac 1.2 (last version I
was using). As trac opens the SMPT port directly, I would not expect
any messages in the system log. And that is the case.

As nothing else is reported, I can't guess why the mail was not sent.

Having said that, in my Trac Preferences->Notifications, it just says
"Subscriptions" in bold text. And a "Save changes" button. But there
is no way to actually see or do anything. Perhaps I am missing
something here so the message is not sent? Or perhaps the Announcer
plugin has left something in my user info in Trac that is confusing
things? The plugin is disabled. But maybe more needs to be done?


What components are enabled/disabled?
Are the EmailDistributorand TicketFormattercomponents enabled?
What are the next lin

Re: [Trac] Re: e-mail notifications in Trac 1.5dev

[Peter Suter]

Hi,
Just FYI Trac ~1.2+ has a lot of the Announcer plugin functionality 
integrated in core, and provides its own "new" extension interfaces.

Joinable groups were prepared here:
https://trac.edgewall.org/wiki/TracDev/Proposals/AdvancedNotification#Advancedsubscriptions
https://trac.edgewall.org/changeset/ad2174686247456fb9b6ec3cd97506b863828ca8/psuter.hg/
https://trac.edgewall.org/ticket/11870
but never finalized. Nobody seemed really interested in this feature. 
This is the first time I see it mentioned by anyone.


The Announcer plugin could also provide these optional features based on 
the core interfaces, but nobody seems to have been interested in doing 
this so far:

https://trac-hacks.org/ticket/12120

I'm not sure what the overall goal is with "@Tickets", that is not 
already solved by subscribing to tickets in the default notification 
preferences.

https://trac.edgewall.org/prefs/notification
https://trac.edgewall.org/wiki/TracNotification#SubscriberConfiguration
https://trac.edgewall.org/wiki/CookBook/Notification/Subscriptions

Cheers,
Peter

On 12 Sep 2022 12:13, Roger Oberholtzer wrote:

On Mon, Sep 12, 2022 at 10:11 AM Roger Oberholtzer
 wrote:

In Trac 1.2, say, I could define an e-mail tag called @Tickets, and
all that have subscribed to Tickets in their notifications would get
e-mails when appropriate.

I have updated to Trac 1.5dev, and I get this when e-mail should be sent:

2022-09-12 10:05:29,561 Trac[mail] DEBUG: Invalid email address: @Tickets
2022-09-12 10:05:29,561 Trac[api] DEBUG: Adding (roger [1]) for
'always' on rule (TicketUpdaterSubscriber) for (email)


The first line is the issue. The second implies that I will still be
added to the list of recipients. However, no e-mail is sent. How best
to proceed?

I see that this was set up in the announcer plugin as follows:

[announcer]
joinable_groups = Tickets

But that seems not to be Python3 ready.

2022-09-12 12:02:56,771 Trac[loader] ERROR: Skipping
"announcer.distributors.mail = announcer.distributors.mail":
ModuleNotFoundError: No module named 'Queue'
2022-09-12 12:02:56,814 Trac[loader] ERROR: Skipping
"announcer.email_decorators = announcer.email_decorators":
ModuleNotFoundError: No module named 'Queue'
2022-09-12 12:02:56,968 Trac[loader] ERROR: Skipping "announcer.pref =
announcer.pref": ImportError: cannot import name
'ITemplateStreamFilter' from 'trac.web.api'
(/usr/lib/python3.10/site-packages/Trac-1.5.4.dev0-py3.10.egg/trac/web/api.py)


  I will see what I can do.



--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/trac-users/27222786-05c0-45ef-ac0f-ea40e14fafa5%40gmail.com.

Re: [Trac] Add Option To Estimate Time Of Ticket/Milestones

[Peter Suter]

Hi,

In Trac this is "traditionally" done using custom ticket fields and / or 
plugins: https://trac-hacks.org/tags/estimation


I think it's generally agreed that such features should be completely 
optional.


Cheers,
Peter


On 11 Jul 2022 19:58, Maynard Koch wrote:

Hi all,

While working on ticket #7871 (adding start date for milestones), I 
realized that there is no option to estimate the time of a 
ticket/milestone and save it to the DB.


It could, especially with the start date, help to measure the 
performance of a project.


Example:

We start late on working on milestone X.

I now would like to know how this affects my project schedule: Do I 
perform on time or late? How much longer will it probably take? Etc.



I did not find any plugins or open tickets for this feature.

The effort is probably about the same as ticket #7871.

Is there anyone else who would like to have this feature?

Cheers,

Maynard



--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/trac-users/cd8882a9-2c80-ad98-e8af-0ced06196c03%40gmail.com.

Re: [Trac] WikiAutoCompletePlugin usability issue regarding separator in source: macro

[Peter Suter]

Hello

I agree the usability is not ideal.
I think the reasons for this are described in the following ticket 
comments if I remember correctly:

https://trac-hacks.org/ticket/13390#comment:3
https://trac-hacks.org/ticket/13189#comment:2
https://trac-hacks.org/ticket/12929#comment:10
The "solution" is basically to use the TAB-key to select completions.


On 1 Nov 2021 15:39, Clemens Feige wrote:

Hello

I have a usability issue about the WikiAutoCompletePlugin [1] when 
using it to auto-complete path names in the source: macro.


We like and use this macro very much. The "problem" is the slash (/) 
path separator. When writing and auto-completing a longer path like 
"source:/bla/blo/bli" the plugin does not offer a fluent auto-complete 
unless you manually remove the trailing slash (/) path separator. It 
does not behave like path auto complete feature in a typical shell.


Example:

Assume "/bla/blo/bli" as given path.
Typing "source:/bla" should offer "blo/".
Well, it does, and auto-complete delivers "source:/bla/blo/".
Now it should automatically offer the next level "bli/".
But it does not!
I have to manually remove the trailing slash
"source:/bla/blo" (no slash at end!) to get offered the next 
auto-complete offer.


I am afraid, it is a little difficult to explain.

In fact, this is not a real problem. But auto-completing long path 
names is not as convenient as known from many shell interfaces. Maybe 
it is just a missing trigger or something?
After the user has selected one of the offered options, then the 
plugin should offer the next list of options. So that the user can 
select, select and select in a chain.


Is there anybody who has an opinion on that matter?
Or who can confirm (or better explain) the issue?

Thanks
Clemens


[1]
https://trac-hacks.org/wiki/WikiAutoCompletePlugin



--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/trac-users/54b230f4-e967-34a5-df0d-93801477b9ec%40gmail.com.

Re: [Trac] Re: Unwanted Trac Notifications

[Peter Suter]

SmtpEmailSender connects directly to the configured SMTP server. 
According to your logs that is "Sending notification through SMTP at 
imci-net.mail.protection.outlook.com:25 
". There is no command line.

https://trac.edgewall.org/browser/tags/trac-1.2.3/trac/notification/mail.py?marks=471,476-477,496-497,522#L471

You could switch to SendmailEmailSender to use sendmail instead. The 
command line will then be logged.

https://trac.edgewall.org/browser/tags/trac-1.2.3/trac/notification/mail.py?marks=539,557#L539

But if the email headers and trac.ini and the Trac log do not contain 
your email address anywhere at all, Trac is likely not responsible.
It could be your mail client, your Exchange Online Protection, mail 
server, forward rules, ...

https://docs.microsoft.com/en-us/exchange/troubleshoot/outlook-issues/emails-sent-to-wrong-account-if-has-many-accounts
https://docs.microsoft.com/en-us/exchange/monitoring/trace-an-email-message/run-a-message-trace-and-view-results

On 13/03/2021 00:19, Patty Cottrill wrote:


Thanks for getting back to me.

I have reviewed the sendmail configuration files and there is nothing 
that would explain adding my email address to the notifications.


When I use sendmail outside of trac, I do not have this problem; 
emails are only sent to the email addresses in the recipient fields 
(To, cc).


The other project on this same ubuntu server _also does not_ have this 
problem; emails are only sent to the email addresses in the recipient 
fields (To, cc).


I have also checked our Exchange online configuration; again nothing 
to explain my email address being added.


The problem seems to be with this one specific project only.

I don’t know where else to look in the configuration files for this 
project.


I’m at a loss and getting frustrated with all these emails from Trac 
tickets for which I have nothing to do.


Is there anyway to see the actual command that trac is using to send 
emails?


Both the syslog and mail log show the mail commands for emails going 
outside of trac, but not for the emails from within trac.


The email sender in the trac.ini is set to SmtpEmailSender; if not 
using sendmail, what else would trac be using?


Below are the mail related packages installed on the ubuntu server:

**

*dpkg -l | grep smtp*

ii libnet-smtp-ssl-perl 1.03-1 
all  Perl module providing SSL support to Net::SMTP


*dpkg -l | grep mail*

ii bsd-mailx 8.1.2-0.20160123cvs-2 
 amd64    simple mail user agent


ii libcompfaceg1 1:1.5.2-5  amd64 
Compress/decompress images for mailheaders, libc6 runtime


ii libemail-valid-perl 1.198-1    
all  Perl module for checking the validity of Internet email 
addresses


ii libmailtools-perl 2.13-1 all 
Manipulate email in perl programs


ii  mime-support 3.59ubuntu1    
all  MIME files 'mime.types' & 'mailcap', and support programs


ii procmail 3.22-25ubuntu0.16.04.1 amd64 Versatile 
e-mail processor


ii sendmail 8.15.2-3   all powerful, 
efficient, and scalable Mail Transport Agent (metapackage)


ii sendmail-base 8.15.2-3   all 
powerful, efficient, and scalable Mail Transport Agent (arch 
independent files)


ii sendmail-bin 8.15.2-3   amd64 
powerful, efficient, and scalable Mail Transport Agent


ii sendmail-cf 8.15.2-3   all 
powerful, efficient, and scalable Mail Transport Agent (config macros)


ii sylpheed 3.5.0~rc2-1ubuntu1     amd64 Light 
weight e-mail client with GTK+


ii sylpheed-doc 20140827-1 all Light 
weight e-mail client with GTK+ (documentation)


-- Patty

*From:* trac-users@googlegroups.com  *On 
Behalf Of *RjOllos

*Sent:* Thursday, March 11, 2021 3:16 PM
*To:* Trac Users 
*Subject:* Re: [Trac] Re: Unwanted Trac Notifications

On Wednesday, March 10, 2021 at 10:42:35 AM UTC-8 pcottrill wrote:

We are using Trac 1.2.3.

Here is the screenshot of Preferences/Notifications.

As I mentioned, I’m not owner, reporter, previous updater or
updater on any of these tickets, in fact I have never touched
these tickets.

Below is from the trac.log of the most recent notification on
ticket #9219:

2021-03-10 12:46:26,816 Trac[perm] DEBUG: DefaultPermissionPolicy
allows mfxxx performing TICKET_VIEW on 

2021-03-10 12:46:26,827 Trac[main] DEBUG: Negotiated locale: None
-> en_US

2021-03-10 12:46:26,895 Trac[perm] DEBUG: DefaultPermissionPolicy
allows mfxxx performing TICKET_MODIFY on 

2021-03-10 12:46:26,896 Trac[perm] DEBUG: DefaultPermissionPolicy
allows mfxxx performing TICKET_CHGPROP 

Re: [Trac] Re: Trac 1.0.19 Released

[Peter Suter]

On 08/01/2020 19:33, Roger Oberholtzer wrote:


Is there a guide for the Trac part? Like the obvious things that need
to be changed for Trac 1.4? Something with example uses and not just
the names of the things to change?


The full list of things that need to be changed:
https://trac.edgewall.org/wiki/TracDev/ApiChanges/1.3

But very few plugins will be affected by all these. More typical is one 
or two (or zero!) problems, but not each plugin has the same problems. 
So typically it's much more efficient to just try the plugin and see if 
anything is broken. Then create a ticket and ask / figure out why from 
the error message / looking at the source and comparing the used APIs to 
the list. Usually it's quite obvious. (At least after you've seen a few 
cases.)


The "obvious" exception is Jinja / Genshi: If the plugin contains HTML 
templates these need to be converted.

The guide for that is here:
https://trac.edgewall.org/wiki/TracDev/PortingFromGenshiToJinja
A small example of such a conversion for a macro plugin:
https://trac-hacks.org/changeset/17465

More examples:
https://trac-hacks.org/search?q=jinja=1=on
https://trac-hacks.org/search?q=1.4=1=on

For very old plugins (pre-1.0) of course more things typically need to 
be updated.

https://trac.edgewall.org/wiki/TracDev/ApiChanges
E.g. the most typical problem is probably the deprecated DB APIs: 
https://trac.edgewall.org/wiki/TracDev/DatabaseApi#Trac1.0API




Perhaps the Plugins that only work with Python 2 should be moved to a
depreciated location? That might make it easier to see which plugins
are effected by a move to Python 3.
Since there is no easily testable Python 3 version of Trac yet, I don't 
think any plugins are known to work / not work in Python 3.

It will probably be similar as above: Try it and see if it works etc.

I assume the way to push this forward is for someone to update the 
branch rjollos.git@t12130_python3.1:

https://trac.edgewall.org/ticket/12130#comment:51
Simplify it by dropping "six" / Python 2 support, and make sure all 
tests pass, so it can be considered for applying to trunk, tested and 
released.


Hope this helps,
Peter

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/trac-users/8379ba87-892e-5177-15ad-8311149dc7fb%40gmail.com.

Re: [Trac] Trac 1.2.3 Email Notification Issue

[Peter Suter]

Hi,

On 06.03.2019 04:18, Jun Omae wrote:

Hi,

On Wed, Mar 6, 2019 at 3:48 AM Peter Suter  wrote:

I think this was discussed here: https://trac.edgewall.org/ticket/11002


I don't consider the ticket is related.

In 1.0.x:
  * use_public_cc option and always_notify_reporter option are enabled,
the reporter is listed in To field.
  * use_public_cc option and always_notify_owner option are enabled,
the owner is listed in To field.
  * use_public_cc option and always_notify_updater option are enabled,
the updater is listed in To field.

See:
  * 
https://trac.edgewall.org/browser/tags/trac-1.0.17/trac/ticket/notification.py?marks=126,128,130#L121
  * 
https://trac.edgewall.org/browser/tags/trac-1.0.17/trac/notification.py?marks=512#L509

In 1.2.x:
  * Never use To field even if any configurations.
* 
https://trac.edgewall.org/browser/tags/trac-1.2.3/trac/notification/mail.py?marks=449#L410



Thanks for the summary.
(I think all/most of that was mentioned in comment:3 and comment:5 of 
#11002, no? Either way, feel free to open a new ticket if #11002 is 
insufficient.)



I cannot find the change of the behavior in
https://trac.edgewall.org/wiki/TracDev/ReleaseNotes/1.2. I think Trac
should keep the behavior after upgrading to 1.2.x.

Also, I'm using AnnouncerPlugin on Trac 1.0.x in production
environment and have the same issue. I wrote decorator component to
keep the save behavior.



From my side, I assumed this was a minor detail that nobody would care 
about and was not worth mentioning. Apparently I was wrong. :) I still 
don't understand why one would care or what exactly would be important, 
but nevermind: Great to hear you already have a component written; feel 
free to include it in Trac.


Cheers,
Peter

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Trac 1.2.3 Email Notification Issue

[Peter Suter]

Hi Patty,

Could you elaborate a bit on why and when the current behavior is a 
problem for you?


And what exactly would have to be different? Is it just this?

from  trac.core  import  Component,  implements
from  trac.notification.api  import  IEmailDecorator
from  trac.notification.mail  import  set_header

class  ToFieldEmailDecorator(Component):

implements(IEmailDecorator)

# IEmailDecorator methods

def  decorate_message(self,  event,  message,  charset):

set_header(message,  'To',  message['Cc'],  charset)

Many people seem to have all sorts of different special requirements for 
notifications, so such plugins are the only viable way how such 
individual tweaks can reasonably be supported.


Cheers,
Peter

On 05.03.2019 20:11, Patty Cottrill wrote:


Hi Peter,

Thank you for your response.

As I understand it, this is normal behavior in this new version of Trac.

The only way to change the behavior is to create a plugin; you cannot 
configure it in trac.ini.


This is unfortunate because I really don’t want to hassle with 
creating a plugin.


Really would be nice to be able to configure it in trac.ini, like it 
was in previous versions of Trac.


-- Patty

*From:*trac-users@googlegroups.com  *On 
Behalf Of *Peter Suter

*Sent:* Tuesday, March 5, 2019 1:49 PM
*To:* trac-users@googlegroups.com
*Subject:* Re: [Trac] Trac 1.2.3 Email Notification Issue

Hi,

I think this was discussed here: 
https://trac.edgewall.org/ticket/11002 
<https://trac.edgewall.org/ticket/11002>


If you need to change this, you could maybe try something similar as 
discussed here: https://trac.edgewall.org/wiki/CookBook/Notification/Email


Let us know if that works for you.

Cheers,
Peter

On 05.03.2019 17:51, Patty Cottrill wrote:

Hi Trac Users,

I recently deployed a new Trac 1.2.3 server and I’m having issues
with the email notifications.

The To field is blank, even though I enabled the use_public_cc
<https://trac.edgewall.org/wiki/TracNotification>.

Once I enabled it, the address that should be in the To field is
being displayed in the CC field.

Is this normal?

I did not have this problem with Trac 0.12.

Below is my configuration:

[notification]

admit_domains =

ambiguous_char_width = single

batch_subject_template = $prefix Batch modify: $tickets_descr

email_sender = SmtpEmailSender

ignore_domains =

mime_encoding = none

sendmail_path = sendmail

smtp_always_bcc =

smtp_always_cc =

smtp_default_domain =

smtp_enabled = enabled

smtp_from = myproj...@imci.net <mailto:myproj...@imci.net>

smtp_from_author = disabled

smtp_from_name =

smtp_password =

smtp_port = 25

smtp_replyto = pcottr...@imci.net <mailto:pcottr...@imci.net>

smtp_server = x.imci.net

smtp_subject_prefix = __default__

smtp_user =

ticket_subject_template = $prefix #$ticket.id: $summary

use_public_cc = enabled

use_short_addr = disabled

use_tls = enabled

Thanks in advance.

-- Patty

-- Patty

-- 
You received this message because you are subscribed to the Google

Groups "Trac Users" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to trac-users+unsubscr...@googlegroups.com
<mailto:trac-users+unsubscr...@googlegroups.com>.
To post to this group, send email to trac-users@googlegroups.com
<mailto:trac-users@googlegroups.com>.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google 
Groups "Trac Users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to trac-users+unsubscr...@googlegroups.com 
<mailto:trac-users+unsubscr...@googlegroups.com>.
To post to this group, send email to trac-users@googlegroups.com 
<mailto:trac-users@googlegroups.com>.

Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google 
Groups "Trac Users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to trac-users+unsubscr...@googlegroups.com 
<mailto:trac-users+unsubscr...@googlegroups.com>.
To post to this group, send email to trac-users@googlegroups.com 
<mailto:trac-users@googlegroups.com>.

Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group,

Re: [Trac] Trac 1.2.3 Email Notification Issue

[Peter Suter]

Hi,

I think this was discussed here: https://trac.edgewall.org/ticket/11002

If you need to change this, you could maybe try something similar as 
discussed here: https://trac.edgewall.org/wiki/CookBook/Notification/Email


Let us know if that works for you.

Cheers,
Peter


On 05.03.2019 17:51, Patty Cottrill wrote:

Hi Trac Users,
I recently deployed a new Trac 1.2.3 server and I’m having issues with 
the email notifications.
The To field is blank, even though I enabled the _use_public_cc_ 
.
Once I enabled it, the address that should be in the To field is being 
displayed in the CC field.

Is this normal?
I did not have this problem with Trac 0.12.
Below is my configuration:
[notification]
admit_domains =
ambiguous_char_width = single
batch_subject_template = $prefix Batch modify: $tickets_descr
email_sender = SmtpEmailSender
ignore_domains =
mime_encoding = none
sendmail_path = sendmail
smtp_always_bcc =
smtp_always_cc =
smtp_default_domain =
smtp_enabled = enabled
smtp_from = _myproject@imci.net_ 
smtp_from_author = disabled
smtp_from_name =
smtp_password =
smtp_port = 25
smtp_replyto = _pcottrill@imci.net_ 
smtp_server = x.imci.net
smtp_subject_prefix = __default__
smtp_user =
ticket_subject_template = $prefix #$ticket.id: $summary
use_public_cc = enabled
use_short_addr = disabled
use_tls = enabled
Thanks in advance.
-- Patty
-- Patty
--
You received this message because you are subscribed to the Google 
Groups "Trac Users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to trac-users+unsubscr...@googlegroups.com 
.
To post to this group, send email to trac-users@googlegroups.com 
.

Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] query tickets which are mentioned in the current ticket

[Peter Suter]

On 12.12.2018 16:08, RjOllos wrote:

Two suggestions for anyone taking this further:
1. Search ticket custom fields of type Text with format=wiki
2. Include "issue:" TracLinks in the regex: 
https://trac.edgewall.org/browser/tags/trac-1.2.3/tracopt/ticket/commit_updater.py?marks=140#L139


I put an adjusted version on 
https://trac-hacks.org/wiki/MentionedTicketsPlugin


Cheers!

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] query tickets which are mentioned in the current ticket

[Peter Suter]

Hello

On 11.12.2018 22:22, Clemens Feige wrote:

Hello

How can one display a list of all ticket numbers which are mentioned 
in the current ticket (i.e. in description text, ticket comments, 
ticket fields and ticket custom fields)?


It might be something like the [[TicketQuery]] macro, but it shall 
work only on the current ticket, instead on all tickets.


Background:
Relations between tickets are important. If for example the user views 
ticket X, then he or she may also want to know about related tickets Y 
and Z. The related tickets are mentioned somewhere deep in the long 
description text of the current ticket. Now the user likes to see a 
distilled list of all mentioned tickets.
Once again please note that I am talking about data extraction within 
the same ticket, not globally across all tickets.


I am aware of the PageTicketsMacro:
 "wiki macro that expands to a TicketQuery of tickets mentioned on the 
current wiki page."

 https://trac-hacks.org/wiki/PageTicketsMacro
Unfortunately the PageTicketsMacro does not work on tickets, only on 
wiki pages. Otherwise it is more or less what I want.


Do you have any suggestions?



Maybe something like this:


import re

from trac.core import *
from trac.util.html  import tag
from trac.web.api import IRequestFilter

author = "Lucid"
version = "1.0 ($Rev$)"
license = "BSD"
url = "https://trac-hacks.org/wiki/MentionedTickets;


class MentionedTickets(Component):
    """List all tickets mentioned in the current ticket."""

    implements(IRequestFilter)

    tickets_re = re.compile('(?:#|(?:ticket:|bug:))(\d+)')

    def pre_process_request(self, req, handler):
    return handler

    def post_process_request(self, req, template, data, content_type):
    path = req.path_info
    if path.startswith('/ticket/'):
    if data and 'ticket' in data and 'fields' in data:
    self._append_related_tickets(req, data)
    return template, data, content_type

    def _append_related_tickets(self, req, data):
    rendered = ''
    ticket = data['ticket']
    comments = [c[4] for c in ticket.get_changelog()
 if c[2] == 'comment']
    text_fields = [field['name'] for field in ticket.fields
 if field['type'] == 'textarea']
    values = [ticket[name] for name in text_fields] + comments
    mentions = [int(match) for value in values
   if value is not None
   for match in 
MentionedTickets.tickets_re.findall(value)]

    if mentions:
    ticket.values['Mentioned Tickets'] = True # Activates field
    results = []
    for id in sorted(set(mentions)):
    label = '#%s' % (id,)
    href = req.href.ticket(id)
    link = tag.a(label, href=href)
    results.append(link)
    rendered = tag.span(*[e for pair in zip(results, [' '] * 
len(results)) for e in pair][:-1])

    data['fields'].append({
    'name': 'Mentioned Tickets',
    'rendered': rendered,
    'type': 'textarea', # Full row
    })


(It's not a macro. It just adds the mentioned tickets to the box.)

Cheers!

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] number of tickets is only 10 for WikiAutoCompletePlugin

[Peter Suter]

On 16.11.2018 18:07, Clemens Feige wrote:
Hello 

Hello


I have a question about the WikiAutoCompletePlugin [1], which I like 
very much.


It looks like the plugin limits the count of proposed tickets (which 
appear in the auto-complete pop-up) to a number of 10 tickets.

What is the motivation for this arbitrary limitation?
Are there speed concerns?
I think this was simply the first thing I tried, years ago, and nobody 
bothered to change it yet.
I assume there has to be _some_ limit, as loading the full list of all 
12'000 tickets on trac-hacks wouldn't make much sense.


Jun and Ryan probably know more than me about what kind of limit would 
put a strain on the server resources.


Note that other items like files do not have a limitation. If too many 
are found, then a scroll bar appears. Why not for tickets?


In the plugin source code I can see that the SQL ticket query is 
limited to 10. Are there any concerns to set this to a higher values 
like 100?


I would be willing to submit a patch (an open a ticket on trac-hacks) 
after successfully testing it.


Please do, thanks!


Thanks
Clemens

[1]
https://trac-hacks.org/wiki/WikiAutoCompletePlugin



--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Fwd: Re: [Trac] Notify on any ticket changes

[Peter Suter]

Forwarding direct mail back to the mailing list.

 Forwarded Message 
Subject:Re: [Trac] Notify on any ticket changes
Date:   Tue, 13 Nov 2018 17:25:17 +0100
From:   Michal Seidl 
To: Peter Suter 



Hello,
so may be I finally found the clue. I trigger NotifySystem event from
ITicketChangeListener. This is my single file plugin that trigers
TicketChangeEvent.

Hope can help someone. Michal

from trac.core import Component, implements
from trac.ticket.api import ITicketChangeListener
from trac.ticket.notification import TicketChangeEvent
from trac.notification.api import NotificationSystem
from trac.util.text import exception_to_unicode

class TicketAnyChangeListener(Component):
implements(ITicketChangeListener)

def ticket_created(self, ticket):
pass

def ticket_changed(self, ticket, comment, author, old_values):
self.env.log.info("*** Ticket is %r ***", ticket)
event = TicketChangeEvent('changed', ticket,
ticket.time_changed, author, comment)
try:
NotificationSystem(self.env).notify(event)
except Exception as e:
self.log.error("Failure sending notification ticket changed
#%s: %s",
  ticket.id,exception_to_unicode(e))

def ticket_deleted(self, ticket):
pass

def ticket_comment_modified(self, ticket, cdate, author, comment,
old_comment):
pass

def ticket_change_deleted(self, ticket, cdate, changes):
pass


--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Notify on any ticket changes

[Peter Suter]

On 11.11.2018 22:35, Michal Seidl wrote:

Hello,
how to notify any verified user on any ticket changes by email in 
version 1.2.3?


I have found smpt_always_cc in trac.ini but manually write, edit and 
maintain list of all verified users?


I have also noticed at Preferences -> Notification site "Example: The 
rule *"Never notify: I update a ticket"* should be above *"Notify: Any 
ticket changes"* to get notifications of any ticket changes except when 
you update a ticket."  but there is no *Any ticket changes *in drop down 
menu?


I have also look into mail.py file at *AlwaysEmailSubscriber* class and 
it does not look to support any wild cards or special key word 
like*all_users.*


 
Any sugestion?


Hello,

I suggest you read the following:
https://trac.edgewall.org/wiki/CookBook/Notification/Subscriptions
https://trac.edgewall.org/wiki/TracDev/PluginDevelopment/ExtensionPoints/trac.notification.api.INotificationSubscriber

It sounds like you want a very specific combination of three things:
1) All ticket notifications: 
https://trac.edgewall.org/wiki/CookBook/Notification/Subscriptions#Subscribetoallticketnotifications
2) Default subscriptions: 
https://trac.edgewall.org/wiki/CookBook/Notification/Subscriptions#Subscribeviacustomticketfield

3) All known users: self.env.get_known_users()

The combined plugin might possibly look something like this:

from trac.core import *
from trac.notification.api import INotificationSubscriber, 
NotificationSystem

from trac.notification.model import Subscription

class AllKnownUsersAllTicketNotificationSubscriber(Component):

implements(INotificationSubscriber)

def matches(self, event):
if event.realm != 'ticket':
return

klass = self.__class__.__name__
for i in Subscription.find_by_class(self.env, klass):
yield i.subscription_tuple()

# Default subscription
for sid, name, addr in self.env.get_known_users():
for s in self.default_subscriptions():
yield s[0], s[1], sid, 1, addr, s[2], s[3], s[4]

def description(self):
return "Any ticket changes"

def default_subscriptions(self):
klass = self.__class__.__name__
return NotificationSystem(self.env).default_subscriptions(klass)

def requires_authentication(self):
return True

But you would have to test it yourself. Don't forget to configure it as 
described in "4. A default subscription can be configured in the 
TracIni#notification-subscriber-section:"


[notification-subscriber]
always_notify_all = AllKnownUsersAllTicketNotificationSubscriber


--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] trac-admin hotcopy failing with mysql backend on 1.2.3

[Peter Suter]

On 28.10.2018 02:12, Dan wrote:
After the file copy completes, the database is still locked with the 
statement above, and it starts the mysqldump; building the mysqldump 
command line from the database URL. The initial value is set here:


|
trac/db/mysql_backend.py:243:       args = [self.mysqldump_path, 
'--no-defaults']

|

Note the '--no-defaults' in args[1].
However, when set, it is added to the same constructed mysqldump 
command line started in the code above with the following:


|
trac/db/mysql_backend.py-255-           elif name == 
'read_default_file':  # Must be first
trac/db/mysql_backend.py:256:               args.insert(1, 
'--defaults-file=' + value)

|

This correctly makes '--defaults-file' first, but it pushes the 
original first argument ('--no-defaults') to the second argument. 
These arguments are mutually exclusive with any version of mysqldump I 
could find, resulting in the confusing error:


|
$ mysqldump --defaults-file=trac/conf/my.cnf --no-defaults
mysqldump: unknown option '--no-defaults'
|

I had to apply the following patch to resolve this:

|
--- db/mysql_backend.py.orig    2018-10-27 15:19:15.285092905 -0700
+++ db/mysql_backend.py 2018-10-27 15:11:36.138342337 -0700
@@ -255,3 +255,3 @@
             elif name == 'read_default_file':  # Must be first
- args.insert(1, '--defaults-file=' + value)
+                args[1] = '--defaults-file=' + value
             elif name == 'unix_socket':
|

The first argument should be replaced, not shifted. This patch and 
including 'read_default_file' the database URL resolves the issue.
It seems --no-defaults is relatively new in Trac: 
https://trac.edgewall.org/ticket/12880#comment:4
The interaction with read_default_file / --defaults-file was maybe not 
considered / encountered yet.


--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Upgrade to 1.2.3, broken diffs, fips and md5

[Peter Suter]

On 28.10.2018 02:32, Dan wrote:
I just migrated a customer install to 1.2.3 on Centos 7.5 and when 
trying to view diffs, I was seeing the following error:


|
ValueError:error:060800A3:digital envelope 
routines:EVP_DigestInit_ex:disabled forfips

|

Changing the hash may be more desirable, but this was the Minimum 
Viable Product.


Has anyone else run into this? If so, how was it resolved?

Apparently there was a similar issue with notifications: 
https://trac.edgewall.org/ticket/12562

It's now possible to change the hash in trac.ini:
[notification]
message_id_hash = sha1
https://trac.edgewall.org/wiki/TracIni#notification-message_id_hash-option

But I don't think it applies to your case yet.

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Trac notification reporter

[Peter Suter]

On 12.09.2018 12:33, Harold Alcalde Solarte wrote:
I found TicketReporterSubscriber but I dont know how to use for dont 
send emails to reporter when he creates a ticket.


El miércoles, 12 de septiembre de 2018, 12:29:53 (UTC+2), Harold 
Alcalde Solarte escribió:


 currently use trac 1.2.2 and the following plugins:
TicketImport 0.9.0, TracDynamicFields 2.2.0dev,
TracSubTicketsPlugin 0.5.4dev , TracWorkflowAdmin
0.12.0.4,TracWysiwyg 0.12.0.7,TracXMLRPC 1.1.7dev.


I want that when creating a ticket only the mail arrives to the
user to whom the ticket was assigned. Currently, when I create a
ticket, the email reaches the reporter as well. I have searched
the trac notification documentation but I can not find that function.
[notification-subscriber] always_notify_cc = CarbonCopySubscriber
always_notify_previous_updater = TicketPreviousUpdatersSubscriber
always_notify_updater = TicketUpdaterSubscriber
always_notify_owner = TicketOwnerSubscriber




Have you tried this?

[notification-subscriber] ... never_notify_reporter = 
TicketReporterSubscriber never_notify_reporter.adverb = never 
https://trac.edgewall.org/wiki/TracNotification#SubscriberConfiguration


--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Email notification for custom field

[Peter Suter]

On 04.09.2018 10:03, Yves Pausch wrote:

Tiny change: I had to add a 'field_set = set()'


Still an issue: The person mentioned in 'tester' is now notified
as expected when the ticket changes. But for the case we change
the tester value initially or later on, also the new value has to
be informed. I imagine adding the current value of 'tester' would
do the job, but how to access that value?

Thanks for your help.


Yes, that's working. I changed  the section in matches() the following 
way:


# Harvest previous field values
field_set = set()
if 'fields' in event.changes and self.field_name in 
event.changes['fields']:
field_set.update(to_set(event.changes['fields'][self.field_name]['old'])) 
# collect the new tester(s)
field_set.update(to_set(event.changes['fields'][self.field_name]['new'])) 
# potentially also collect the new tester(s)


I think the user_set was also supposed to be field_set. I adjusted 
https://trac.edgewall.org/wiki/CookBook/Notification/Subscriptions#Subscribeviacustomticketfield


--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Email notification for custom field

[Peter Suter]

On 03.09.2018 14:49, Yves Pausch wrote:
Hi, I added a custom field 'tester' and want this tester to be 
notified in the way a CC is notified, when the ticket changes. Is 
there a way to achieve this using trac 1.2 (+ plugin)?

Thanks, Yves.


Hi,
Yes, try this: 
https://groups.google.com/d/msg/trac-users/xsE0h5VjfLA/F18nUAmKEAAJ
I now also added this to: 
https://trac.edgewall.org/wiki/CookBook/Notification/Subscriptions#Subscribeviacustomticketfield


Hope this helps.

Peter

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Yet another chart plugin: Announcement and request for further ideas

[Peter Suter]

On 08.07.2018 00:49, RjOllos wrote:



On Tuesday, May 15, 2018 at 1:22:30 PM UTC-7, Theodor Norup wrote:

After a good deal of frustration with several of the older
charting plugins, i've rolled a new hack:
https://trac-hacks.org/wiki/TracYetAnotherChartMacro


*Design goals:*
*
*
- Client-side imaging (reduces network load in cases of multiple
images and fewer server-side dependencies)
- Allow multiple charts on a single wiki page
- Must work without any configuration
- Jinja2 templating - ready for Trac 1.4
- No Flash
- Should not expose plotly's internal data format but for very
special use cases
- Long-term stability:

  * do not rely on eg. Google chart API not changing
  * possiblity to maintain support for older chart libraries when
upgrading to newer libraries
  * do not assume that the open internet is accessible

... and maybe even: Allow the older charting plugins to be retired.

*Request for further ideas:*

I expect to invest some more time in the plugin, so good ideas and
suggestions for prioritisation are most welcome.

So far, i have these ideas on my list:
- axis names directly derived from the query
- 2+ data series in the same plot
- configurable standard width/height/colour
- expansion of $TICKET in query text
- better query error reporting
- also use trac's ticket query language
- more plot types. Scatter charts come first to mind
- seek inspiration from MermaidPlugin's trick to avoid the id
parameter
- (speculative!) interaction with other plugins. For instance,
imagine that TimingAndEstimationPlugin's burndown function could
act as a data provider for the present macro - that would on one
hand give a nice separation of concern and on the other hand
result in a more uniform graphical expression.

Finally, a very valuable contribution would be users'
"interesting" (ie. non-trivial) SQL queries - adapted for the most
common databases. A single wiki page collecting these would be
valuable to many rather than the current scatter.

All the best

Theodor


Using Trac's ticket query language and permission restricting 
arbitrary SQL execution is important for making the plugin widely-useful.


- Ryan
I agree, and assume this would be much easier with ITicketQueryRenderer 
from #12156. https://trac.edgewall.org/ticket/12156
The plugin could then simply implement ITicketQueryRenderer as shown in 
the patch there, and users can just use
for example [[TicketQuery(..., format=pie)]] using Trac's ticket query 
language and so on as usual.

Or is there a problem I'm missing with this approach?

Peter

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Notifications - what is current in 1.2.2 vs what is deprecated

[Peter Suter]

On 12.06.2018 13:08, Roger Oberholtzer wrote:

On Tue, Jun 12, 2018 at 9:25 AM, Peter Suter  wrote:


Does that clear things up a bit?

When I understood that that the text like
"my_default_subscriber_rule_to_always_notify_ticket_owners_via_html_email"
has no inherent meaning to Trac, and that one cannot (it seems to me)
make any reference to it, I understood.  I am guessing that there will
be some feature in the future where
"my_default_subscriber_rule_to_always_notify_ticket_owners_via_html_email"
itself (not just what it is set to) is used and can be referenced for
some reason. If that's not the case, then the syntax is strange.
You refer to "my_bla" again in "my_bla.keyword1 = value1", 
"my_bla.keyword2 = value2".
AFAIK that's the only / standard syntax to define such groups of 
keywords/values in INI files.




But no problem. I know what is going on now. And a few people have
reported getting notifications that they previously did not get. How
the INI file settings relate to the things individual users can select
for notification in the Trac GUI is a different question.

The INI file settings define the default rules.
The GUI potentially allows overriding those default rules with per-user 
preferences.


--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Notifications - what is current in 1.2.2 vs what is deprecated

[Peter Suter]

On Tuesday, June 12, 2018 at 7:54:32 AM UTC+2, Roger Oberholtzer wrote:
>
> On Mon, Jun 11, 2018 at 9:32 PM, Peter Suter  > wrote: 
> > On 11.06.2018 13:28, Roger Oberholtzer wrote: 
> >> 
> >> On Mon, Jun 11, 2018 at 12:56 PM, Peter Suter  > wrote: 
> >> 
> >>> And as is mentioned there: "The subscription rule name on the left 
> side 
> >>> of 
> >>> the = can be anything, it has no meaning outside this configuration 
> >>> file." 
> >>> So "the labels that they are typically specified with in trac.ini" are 
> >>> not 
> >>> listed. Maybe that is too confusing? 
> >> 
> >> At least it is inconsistent with everywhere else in the ini file, 
> >> where I think the labels to the left always have meaning. I did not 
> >> get the significance of that statement. So I assumed there was a list 
> >> of expected labels somewhere. 
> > 
> > There are a few other groups that allow the user to chose any name on 
> the 
> > left of the = sign, like: 
> > [ticket-custom] 
> > [ticket-workflow] 
> > [milestone-groups] 
> > [repositories] 
>
> True. But there you are defining something of your own. Like your own 
> variable or repository. And still the tags are only partly your own. 
> Most have an appended .keyword that is defined by Trac. 
>
> Why isn't the parameter for the desired notifications a single list 
> with the notification names as the list items? Isn't that effectively 
> what the current thing does, since the tags have no meaning to Trac? 
>

All the same things also apply to the [notification-subscriber] section.
You define your default notification rule, and for each rule name you can 
append .keyword properties defined by Trac.

Example:

[notification-subscriber]

my_default_subscriber_rule_to_always_notify_ticket_owners_via_html_email = 
TicketOwnerSubscribermy_default_subscriber_rule_to_always_notify_ticket_owners_via_html_email.distributor
 = email
my_default_subscriber_rule_to_always_notify_ticket_owners_via_html_email.format 
= text/html

my_default_subscriber_rule_to_also_always_notify_ticket_owner_via_plain_text_xmpp
 = 
TicketOwnerSubscribermy_default_subscriber_rule_to_also_always_notify_ticket_owner_via_plain_text_xmpp.distributor
 = xmpp
my_default_subscriber_rule_to_also_always_notify_ticket_owner_via_plain_text_xmpp.format
 = text/plain


It's just that so far there's rarely a need / use for this, because Trac does 
not yet include any distributors other than for email, nor any formatters other 
than for text/plain.

For another example with more .keywords see 
https://trac.edgewall.org/wiki/TracNotification#ExampleConfigurationdefaultsubscriptions

Does that clear things up a bit?

-- 
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Notifications - what is current in 1.2.2 vs what is deprecated

[Peter Suter]

On 11.06.2018 13:28, Roger Oberholtzer wrote:

On Mon, Jun 11, 2018 at 12:56 PM, Peter Suter  wrote:


And as is mentioned there: "The subscription rule name on the left side of
the = can be anything, it has no meaning outside this configuration file."
So "the labels that they are typically specified with in trac.ini" are not
listed. Maybe that is too confusing?

At least it is inconsistent with everywhere else in the ini file,
where I think the labels to the left always have meaning. I did not
get the significance of that statement. So I assumed there was a list
of expected labels somewhere.
There are a few other groups that allow the user to chose any name on 
the left of the = sign, like:

[ticket-custom]
[ticket-workflow]
[milestone-groups]
[repositories]

I you know how please change the explanation to be more clear. I suspect 
it's still unclear to many other people as well.





I miss notifications when wiki pages change. But as the Announcer
plugin is no longer compatible, I guess the wiki is not part of this.


There's an old patch for this here:
https://trac.edgewall.org/ticket/1660#comment:25

Is that patch compatible with Trac 1.2.x?
No, it was very outdated. I added an updated v2 patch now, but that one 
requires Trac 1.3.2+ (Jinja templates) / trunk and a fix for #13041.


--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Notifications - what is current in 1.2.2 vs what is deprecated

[Peter Suter]

On Monday, June 11, 2018 at 8:44:47 AM UTC+2, Roger Oberholtzer wrote:
>
> This topic has always confused me as well. It seems that the docs for 
> the current/new notification system are a bit all over the place. One 
> thing I do not see is a simple list that tells both all the Subscriber 
> function names AND the labels that they are typically specified with 
> in trac.ini. I think this is the current complete list of possible 
> notifiers that come as part of trac?: 
>
> [notification-subscriber] 
> always_notify_cc = CarbonCopySubscriber 
> always_notify_previous_updater = TicketPreviousUpdatersSubscriber 
> always_notify_updater = TicketUpdaterSubscriber 
> always_notify_reporter = TicketReporterSubscriber 
> always_notify_owner = TicketOwnerSubscriber 
>   
>
Are there any others? 
>
The full list should be here: 
https://trac.edgewall.org/wiki/TracNotification#SubscriberConfiguration
and here: 
https://trac.edgewall.org/wiki/TracIni#notification-subscriber-section
and they can be also be listed with the SubscriberListMacro: 
https://trac.edgewall.org/wiki/TracDev/ReleaseNotes/1.2#/SubscriberListMacro
And as is mentioned there: "The subscription rule name on the left side of 
the = can be anything, it has no meaning outside this configuration file."
So "the labels that they are typically specified with in trac.ini" are not 
listed. Maybe that is too confusing?

AlwaysEmailSubscriber can not be configured in that section: 
https://trac.edgewall.org/ticket/12036
NewTicketSubscriber was added very recently and can also not be configured 
in that section: https://trac.edgewall.org/ticket/6613

Some more optional ones are listed here: 
https://trac.edgewall.org/wiki/CookBook/Notification/Subscriptions



> I miss notifications when wiki pages change. But as the Announcer 
> plugin is no longer compatible, I guess the wiki is not part of this. 
>
>
There's an old patch for this here: 
https://trac.edgewall.org/ticket/1660#comment:25

-- 
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Numerous problems with Spam Filter plugin (v1.0)

[Peter Suter]

Hello

On 10.06.2018 22:53, Nicolas MARTIN wrote:

Hello Trac community,


I installed the plugin from the last revision of the branch restricted 
to Trac 1.0.x releases.


First I got my usual installation issues with our outdated release 
1.0.1: 'from trac.util.html import tag' => 'from trac.util.html import 
html as tag' (all changes are in the attached file).


Then 2 admin pages crash: 'Monitoring' (/admin/spamfilter/monitor) and 
'Reports' (/admin/spamfilter/report). But the log refers to 
WikiAutoCompletePlugin


2018-06-10 20:57:39,539 Trac[main] ERROR: Internal Server Error:
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/trac/web/main.py", line 497, 
in _dispatch_request

    dispatcher.dispatch(req)
  File "/usr/lib/python2.7/site-packages/trac/web/main.py", line 224, 
in dispatch

    self._post_process_request(req, *resp)
  File "/usr/lib/python2.7/site-packages/trac/web/main.py", line 338, 
in _post_process_request

    resp = f.post_process_request(req, *resp)
  File "build/bdist.linux-x86_64/egg/wikiautocomplete/web_ui.py", line 
60, in post_process_request

    if context_or_page and context_or_page.resource:
AttributeError: 'int' object has no attribute 'resource'

I created https://trac-hacks.org/ticket/13439 for this, thanks.

Finally I tried to delete an unused account from 'Users' with 'Remove' 
button: Trac seems to proceed but ends in a page from the webserver 
outside of our Trac.
If I goes back the account about to be removed is still there, 
AccountManager plugin is in version 0.5.



Regards,
Nicolas


--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: SQL Query - Filter

[Peter Suter]

On 04.04.2018 18:46, RjOllos wrote:

On Wednesday, April 4, 2018 at 2:20:37 AM UTC-7, Andreas wrote:

Hello!

I am using a SQL query because I need some non-standard tables in
my report (from the TracHoursPlugin).
Is there a way to add a filter field to the SQL report?



For simple cases there are dynamic variables like this: WHERE 
priority='$PRIORITY'

https://trac.edgewall.org/report/14?max=100=normal
https://trac.edgewall.org/wiki/TracReports#AdvancedReports:DynamicVariables



Another option would be to add specific fields from the database
to the "Columns" view - is this possible? I guess this would be
harder because there would have to be an SQL-join somewhere in the
background...

Thanks for any hints!

Best regards,
Andreas


Currently there are no extension points for the Query System for 
handling other tables.
IQueryParticipant was proposed in https://trac.edgewall.org/ticket/10983 
though.


--
Peter

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] How to Select a Database for Trac

[Peter Suter]

On 22.11.2017 20:39, ray wrote:
I have reviewed the tickets on the Trac site and the messages in this 
forum to see if there are any reliability or installation issues for a 
new installation.


How might I find out about trade-offs between the DB options?


SQLite:
+Basically the default. So this probably gets tested the most, and the 
most plugins work with this.

+Very simple to set up. (You don't have to do or install anything.)
-Reportedly it gets slow when you have a large number of concurrent 
users, and you might even get lock errors.


PostgreSQL:
-Not the default. So some plugins might not be compatible with this just 
because nobody ever tested it.
-You need to set it up and configure it separately. So this is one more 
thing to learn about.
+Basically the recommended solution if you get performance problems / 
lock errors due to many concurrent users.


MySQL:
More or less the same points apply as with PostgreSQL.
But there seem to be more compatibility problems (due to limited key 
sizes, limited string sizes, unsuitable default encodings, old storage 
engines etc.).
Basically not recommended, unless you have some unrelated reason for 
using it. (E.g. you already use MySQL for other systems and just prefer 
to do everything with MySQL.)


This is just my impression from what I read. SQLite works fine for me. I 
never really used MySQL or PostgreSQL for Trac in production.


--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Change e-mail BCC to TO

[Peter Suter]

On 08.11.2017 17:03, Tim wrote:
When someone submits a ticket or subscribes to get e-mails, They get 
BCCed on any e-mails. Is there a way to switch the BCC list to be on 
the to line instead?
You probably want a small IEmailDecorator. See 
https://trac.edgewall.org/wiki/CookBook/Notification/Email#Addorchangeemailheader

Maybe something like this (untested):

from  trac.core  import  Component,  implements
from  trac.notification.api  import  IEmailDecorator
from  trac.notification.mail  import  set_header

class  ReplaceBccWithToHeaderEmailDecorator(Component):

implements(IEmailDecorator)

# IEmailDecorator methods

def  decorate_message(self,  event,  message,  charset):

if 'Bcc' in message:set_header(message,  'To',  message['Bcc'],  
charset)del message['Bcc']

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Random "Target WSGI script cannot be loaded as Python module" after Python upgrade

[Peter Suter]

On 31.08.2017 17:49, Matt wrote:

Here is stacktrace:

|
mod_wsgi (pid=31659):TargetWSGI script 
'/var/trac/apache/trac.wsgi'cannot be loaded asPythonmodule.
mod_wsgi (pid=31659):Exceptionoccurred processing WSGI script 
'/var/trac/apache/trac.wsgi'.

Traceback(most recent call last):
File"/var/trac/apache/trac.wsgi",line 8,in
importtrac.web.main
File"/usr/local/lib/python2.7/dist-packages/Trac-0.11.7-py2.7.egg/trac/web/main.py",line 
49,in

fromtrac.web.chrome importChrome
File"/usr/local/lib/python2.7/dist-packages/Trac-0.11.7-py2.7.egg/trac/web/chrome.py",line 
53,in

fromtrac.wiki importIWikiSyntaxProvider
File"/usr/local/lib/python2.7/dist-packages/Trac-0.11.7-py2.7.egg/trac/wiki/__init__.py",line 
1,in

fromtrac.wiki.api import*
File"/usr/local/lib/python2.7/dist-packages/Trac-0.11.7-py2.7.egg/trac/wiki/api.py",line 
36,in

fromtrac.wiki.parser importWikiParser
File"/usr/local/lib/python2.7/dist-packages/Trac-0.11.7-py2.7.egg/trac/wiki/parser.py",line 
24,in

fromtrac.notification importEMAIL_LOOKALIKE_PATTERN
File"/usr/local/lib/python2.7/dist-packages/Trac-0.11.7-py2.7.egg/trac/notification.py",line 
17,in

importsmtplib
File"/usr/lib/python2.7/smtplib.py",line 48,in
importhmac
File"/usr/lib/python2.7/hmac.py",line 8,in
fromoperatorimport_compare_digest ascompare_digest
ImportError:cannot importname _compare_digest
|

Search the web for "_compare_digest". It seems you might have an old 
virtualenv or a second old Python installation somewhere or something 
like that. For example: 
https://stackoverflow.com/questions/26535043/python-flask-error-importerror-cannot-import-name-compare-digest




On Thursday, August 31, 2017 at 10:37:42 AM UTC-5, Matt wrote:

0.11.7 - What do you need from the config?

0.11.7 is very, very old. It's unlikely this is the cause of this 
problem, but you should still upgrade.



On Thursday, August 31, 2017 at 10:30:59 AM UTC-5, RjOllos wrote:



On Thu, Aug 31, 2017 at 8:25 AM, Matt 
wrote:

Updated Python from 2.7.6 to 2.7.12 on Ubuntu and as soon
as upgrade finished, I started getting these errors bout
2-3% of link clicks in Trac.


We will probably need to see your Apache configuration file.
Which Trac version are you running?




--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Detect different sources of changes with INotificationSubscriber?

[Peter Suter]

On 29.08.2017 15:34, Tim Ward wrote:
I'm playing with a INotificationSubscriber plugin to generate 
notifications (I'll have quite a complex system to decide which 
notifications go to which people depending an all sorts of things 
about the content of the ticket).


One thing I want to do is be able to tell the difference between when 
a change (typically an added comment) comes in through the XMLRPC 
interface and when it's something the user has done in the browser.


I'm not familiar with XMLRPC. Is there in general a way to detect XMLRPC?

I have thought of doing this by adding another action to the workflow 
that behaves like "leave" but has a different name, the idea being 
that I can then decide what to do in my INotificationSubscriber plugin 
by looking at the action. But I can't find out how my matches() gets 
told what the action is.
I can't see a way either. Maybe the `action` should be an additional 
optional field of `TicketChangeEvent` if this is generally useful, so 
it  could be accessed via `event.action`.

`BatchTicketChangeEvent` already has this.
Would you like to submit a patch for Trac 1.3.3?

https://trac.edgewall.org/browser/trunk/trac/ticket/notification.py?rev=16208=63,66-67,77,80,85#L63
https://trac.edgewall.org/browser/trunk/trac/ticket/web_ui.py?rev=16282=1398#L1383


So:

(1) Does matches() get told what the action is, and if so where/how?

Apparently no.


(2) If not, how else can I tell in the INotificationSubscriber plugin 
where the change came from? (I can, I think, do anything I like to the 
system, including eg adding custom fields.)
As an ugly hack of last resort you could inspect the callstack and look 
for XMLRPC methods? https://docs.python.org/2/library/inspect.html


(3) If it's completely impossible to achieve what I want 
with INotificationSubscriber what else should I be looking at?


[Note: I've had to hack the XMLRPC plugin to make it work at all with 
the new notification system, see Trac Hacks ticket #13263, so there 
might be possibilities around adding an extra field to the event I'm 
creating in the ticket.update() handler, but I'd rather avoid that 
sort of muckiness if I can as that won't survive the XMLRPC plugin 
getting fixed properly.]
Is it common that a plugin would care if an event is from XMLRPC or not? 
I don't understand the implication. If yes, maybe XMLRPC should use a 
`XMLRPCTicketChangeEvent` subclass?


--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Help in development of trac macro building links

[Peter Suter]

On 09.08.2017 00:25, RjOllos wrote:


On Tuesday, August 8, 2017 at 11:14:25 AM UTC-7, Peter Suter wrote:

A slightly simpler version:

return format_to_html(self.env, formatter.context, the_link)


Seems like it would be a good idea to change the example code to use 
format_to_html, as in your example:

https://trac.edgewall.org/wiki/WikiMacros#Macrowitharguments

, unless the example is intended to be illustrative of something.

Using format_to_html is effectively the same after two levels of 
indirection:

https://trac.edgewall.org/browser/tags/trac-1.2.2/trac/wiki/formatter.py?marks=1606#L1601
https://trac.edgewall.org/browser/tags/trac-1.2.2/trac/wiki/formatter.py?marks=1559-1562#L1541

What do you think?


Yes, I thought the same thing, but I also wasn't sure if it was intended 
to illustrate something more general.



Peter

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Help in development of trac macro building links

[Peter Suter]

Hi,

On 08.08.2017 14:19, Riedel, Torge wrote:


Hi,

I’m developing a trac macro to make it easier for wiki editors to add 
links to an external tool.


In Wiki-Markup they can then use a macro:

[[MyLink(my_value)]]

to have a link in trac style on their wiki page to the external tool.

The format of the link is similar to this:

myschema://myserver:1234/this/that/page?param1=value1=value2=my_value=value4



Have you considered using Trac's InterWiki feature?
https://trac.edgewall.org/wiki/InterWiki

For example you could edit own InterMapTxt wiki page, adding something like:

mylinkmyschema://myserver:1234/this/that/page?param1=value1=value2=$1=$2 



and then write

mylink:value3:value4

to get a  link. If that's all you want then no plugin is needed.

My py code (I’m not a python developer, but developing C/C++. Google 
helps me with python) looks like this in the macro file (I modified 
the example from here https://trac.edgewall.org/wiki/0.12/WikiMacros):


from genshi.core import Markup

from trac.wiki.macros import WikiMacroBase

from trac.wiki import Formatter

import StringIO

class MyLinkMacro(WikiMacroBase):

def expand_macro(self, formatter, name, text, args):

the_link = 
'[myschema://myserver:1234/this/that/page?param1=value1=value2=' 
+ text + '=value4 ' + text + ']'


# Convert Wiki markup to HTML, new style

out = StringIO.StringIO()

Formatter(self.env, formatter.context).format(the_link, out)

return Markup(out.getvalue())

My problem is, that the link is rendered but does not work afterwards 
because „&“ is replaced by „“ and without any deeper knowledge of 
python and trac development I’m blocked in progress.


The code above actually seems to work (if "myschema " is replace by a 
known schema like "http").


A slightly simpler version:

from trac.wiki.macros import WikiMacroBase
from trac.wiki.formatter import format_to_html


class MyLinkMacro(WikiMacroBase):
def expand_macro(self, formatter, name, text, args):
the_link = 
'[myschema://myserver:1234/this/that/page?param1=value1=value2=' 
+ text + '=value4 ' + text + ']'


return format_to_html(self.env, formatter.context, the_link)


--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Query macro always opens with filters expanded

[Peter Suter]

Hi

On 02.06.2017 09:43, Mo wrote:
Hi, we like to define complex queries for the users to find their 
tickets as query hyperlinks in the main Wiki.


Before going for SQL reports I try to get that done with [query: ] macros.
Having large [query:?...] macros, the opening /query always has the v 
Filters frame expanded, filling the whole first screen. Silly but 
annoying. Can that be changed?
One crude workaround could be appending #columns to the 
[query:?...#columns] macro to link directly to the result part of the 
screen.


Best regards.

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Ticket View

[Peter Suter]

On 19.05.2017 12:39, toto200891 wrote:

On Friday, May 19, 2017 at 12:28:52 PM UTC+2, toto200891 wrote:

On Friday, May 19, 2017 at 11:16:50 AM UTC+2, Cooke, Mark wrote:

> -Original Message-
> From: trac-...@googlegroups.com
[mailto:trac-...@googlegroups.com] On
> Behalf Of toto200891
>
> Hi,
>
> I was working on ticket view on trac 0.12.7. I had used the
following shown
> plugin to create a permission TICKET_VIEW_STATUS and allow
the user to see
> the tickets with status "test".
>
> # -*- coding: utf-8 -*-
> #
> # Copyright (C) 2017 Edgewall Software
> # All rights reserved.
> #
> # This software is licensed as described in the file
COPYING, which
> # you should have received as part of this distribution. The
terms
> # are also available at
http://trac.edgewall.org/wiki/TracLicense
.
> #
> # This software consists of voluntary contributions made by
many
> # individuals. For the exact contribution history, see the
revision
> # history and logs, available at http://trac.edgewall.org/log/.
>
>
> from trac.core import *
> from trac.perm import IPermissionPolicy, IPermissionRequestor
> from trac.resource import ResourceNotFound
> from trac.ticket.model import Ticket
>
>
>
>
> class StatusDeskPolicy(Component):
> """Provides a permission for restricting ticket actions
to the
> ticket owner.
> """
>
>
> implements(IPermissionPolicy, IPermissionRequestor)
>
>
> # IPermissionRequestor methods
>
>
> def get_permission_actions(self):
> return ['TICKET_VIEW_STATUS']
>
>
> # IPermissionPolicy methods
>
>
> def check_permission(self, action, username, resource,
perm):
> if username != 'anonymous' and \
> action == 'TICKET_VIEW' and \
> 'TICKET_ADMIN' not in perm:
> if 'TICKET_VIEW_STATUS' in perm:
> if resource is None or \
> resource.realm == 'ticket' and \
> resource.id  is None:
> return True
> elif resource.realm == 'ticket' and \
> resource.id  is not None:
> try:
> ticket = Ticket(self.env,
resource.id )
> except ResourceNotFound:
> pass
> else:
> return ticket['status']=='test'
>
>
> Now I would like to add another status to this code like
"Accepted_for_test"
> , for so I just tried changing the last line as follows:
>
>
> return ticket['status']=='test', 'accepted_for_test'

Python allows you to return multiple values, so you have
effectively returned a tuple of a Boolean (the result of the
comparison) and a constant string.

Try something like this:

> return ticket['status'] in ['test', 'accepted_for_test']

~ Mark C

> But by doing the following change, Now the user is able to
view all tickets,
> which I was not expecting. Is there any problem with the
syntax? or I am
> missing something? Kindly guide me in this regard.
>
>
> Regards,
> SF 


Is it also possible to include the following:

return [ticket['status'], 'username'] in ['test', 'accepted_for_test', 
ticket['reporter'], ticket['owner']]


Such that I could allow a user to view tickets, based on status and 
also the tickets he is been assigned to or he reported?


return ticket['status'] in ['test', 'accepted_for_test'] or username in 
[ticket['reporter'], ticket['owner']]


Maybe?

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Ticket query

[Peter Suter]

On 17.05.2017 10:19, toto200891 wrote:



On Tuesday, May 16, 2017 at 5:50:12 PM UTC+2, hasienda wrote:

I found two issues while reading your code and message:

Make sure to have the permission action named as you desire. In
your message you spoke about 'TICKET_VIEW_STATUS' while it was
written as 'TICKET_VIEW_STATUS' in code.

Yes the permission is given to the user


You may have missed the point:
TICKET_VIEW_STATUS
TICKET_STATUS_VIEW
These are NOT the same. Do not mix them.

Regards,
Peter

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Group notifications

[Peter Suter]

On 12.05.2017 05:12, RjOllos wrote:



On Tuesday, May 9, 2017 at 1:51:58 PM UTC-7, Peter Suter wrote:

|||You could test JoinableGroupSubscriber:|
||

|https://trac.edgewall.org/ticket/11870#comment:3
<https://trac.edgewall.org/ticket/11870#comment:3>

https://trac.edgewall.org/browser/psuter.hg/tracopt/notification/joinable_groups.py?rev=10397

<https://trac.edgewall.org/browser/psuter.hg/tracopt/notification/joinable_groups.py?rev=10397>
https://trac.edgewall.org/attachment/ticket/11870/watch-prefs.png
<https://trac.edgewall.org/attachment/ticket/11870/watch-prefs.png>
|

|Regards,
Peter
|



I can also see how it would be desirable to CC a permission group, and 
have all members of the group receive an email. Without accounting for 
overlapping user and group name,s here is a


Yes, that could make a lot of sense.


simple patch to demonstrate (against 1.2-stable):

diff --git a/trac/ticket/notification.py b/trac/ticket/notification.py
index 92957d016..589fdbb41 100644
--- a/trac/ticket/notification.py
+++ b/trac/ticket/notification.py
@@ -29,6 +29,7 @@ from trac.notification.compat import NotifyEmail
 from trac.notification.mail import (RecipientMatcher, create_message_id,
 get_from_author, set_header)
 from trac.notification.model import Subscription
+from trac.perm import PermissionSystem
 from trac.ticket.api import translation_deactivated
 from trac.ticket.model import Ticket
 from trac.util.datefmt import (datetime_now, format_date_or_datetime,
@@ -462,6 +463,13 @@ class CarbonCopySubscriber(Component):
 if 'fields' in event.changes and 'cc' in event.changes['fields']:
cc_set.update(to_set(event.changes['fields']['cc']['old']))

+# Get members of permission groups
+groups = PermissionSystem(self.env).get_groups_dict()
+for cc in cc_set.copy():
+if cc in groups:
+cc_set.remove(cc)
+cc_set.update(groups[cc])
+
 matcher = RecipientMatcher(self.env)
 klass = self.__class__.__name__
 sids = set()
If we don't want this to be the default behavior, we could use similar 
logic to create a CarbonCopyGroupSubscriber. In the case of a group 
that has the same name as an sid, we'd have to decide which takes 
precedent, and should log a warning. As far as I'm concerned, 
CarbonCopyGroupSubscriber could just go in trac.ticket.notification 
rather than tracopt.notification, since it wouldn't be enabled by 
default anyway.


The JoinableGroupSubscriber linked above inherited one more "trick" from 
Announcer[1]:
> Add the group name preceded by @ (such as @security for the security 
group) to the CC field of a ticket to notify all group members
Maybe this helps with the ambiguity / precedence question of overlapping 
user / group names.
(But I can imagine requireing @group reduces "discoverability" / 
"rememberability" of the feature.
Unless the groups are known to a auto-completion suggestion dropdown 
feature.)


I don't really know the benefits / disadvantages of using tracopt or 
not. I don't mind either way. Do many users know to look for optional 
components in tracopt / trac?


Also, from a user perspective, I wonder if it would then make sense to 
move "Group Membership" into its own admin panel.

At the moment these groups are really "Permission Groups".
But with this feature they kind of seem to become more general "User 
Groups" instead.
A normal user probably wouldn't know that "User Groups" are implemented 
as permissions and can be found in the "Permissions" admin panel.


If "Permission Groups" are implemented, does it make sense to also 
implement "Joinable Groups", or would the former replace the latter?

Advantages:
* Users without PERMISSION_GRANT/_REVOKE can join and leave them freely.
* You can organize permissions independently from notifications.
Disadvantage:
* There are now confusingly two quite similar user group notification 
systems.
* You have to organize the permission groups AND the notification 
groups. Maybe these group structures are often identical?


Peter

[1] 
https://trac-hacks.org/browser/announcerplugin/trunk/announcer/opt/subscribers.py#L132


--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Group notifications

[Peter Suter]

On 09.05.2017 22:13, toto200891 wrote:

Hi

Could anybody suggest some ideas about group notification? what I mean is like 
if there are 3 groups A, B and C and every group have different members with 
different mail id's. And now if I have to notify a particular group, say for 
example Group A? How could I do it?

For now I am entering email id of each member manually. Is there any other way 
to send an email to every member of that group by writing a single mail id? I 
have also tried creating a gmail group and tried sending it to that group. But 
as you know the mail get delivered to the group and not to the inbox of the 
members?

So could you please suggest some ideas to achieve the following objective.

Regards
SF


|Hi
|

|You could test JoinableGroupSubscriber:
https://trac.edgewall.org/ticket/11870#comment:3
https://trac.edgewall.org/browser/psuter.hg/tracopt/notification/joinable_groups.py?rev=10397
https://trac.edgewall.org/attachment/ticket/11870/watch-prefs.png
|

|Regards,
Peter
|

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] TracStatsPlugin usage

[Peter Suter]

On 05.05.2017 09:10, Roger Oberholtzer wrote:

I am trying to get the TracStatsPlugin to work in Trac 1.2.1. I get
the expected information about the Trac itself. But I do not get
anything about the code activity. I have a number of Subversion
repositories. Activity in these repos is shown in the Timeline. So I
know Trac has access to this information.

There is a setting for the plugin:

  [stats]
  root = path/to/projects

I have tried setting this to the Trac directory (as used with
trac-admin), as well as to one of the repos. I have STATS_VIEW
permission. But I still get nothing for Code.

There is nothing listed in the Trac log.

I am guessing this plugin works with only one repository?


The plugin seems to only look at the repository cache in the DB, not 
directly at the repository.

It does seem to support multiple repositories.
The "root" setting is used to filter out entries in the 
"node_change.path" DB table.column.
I guess it's a relative sub-path and you should set it to "/" to see 
everything in the repository.

If your repository is in
/path/to/repository/
but  only
/path/to/repository/relevant/subpath/to/project/
is contains anything relevant to your Trac project, then you would set 
root to

/relevant/subpath/to/project/

If you use an uncached repository the plugin won't see anything.

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Need help disabling Trac email notifications

[Peter Suter]

On 27.04.2017 18:18, SBBH wrote:
I want to disable notifications when I create or update a ticket that 
I own.

The "that you own" part is surprising / unclear to me.
What about when you create or update a ticket that you do not own?
What about when someone else creates or updates a ticket that you own?

  I'm still getting notifications when I create a ticket that is 
assigned to myself
Here again you mention the case where your are both the ticket owner and 
the ticket creator at the same time.


and when a ticket that's assigned to me is updated and this is getting 
very annoying.
Here you only mention that it's assigned to you, but not who is doing 
the updating.



My current rules:

  * Never notify: I update a ticket
  * Notify: Ticket that I reported is modified
  * Notify: Ticket that I'm listed in the CC field is modified

I have also configured "Never notify: I update a ticket" in my own 
account preferences.
These rules only block notifications if you are the updater, not if you 
are the ticket owner.


If you want to block all notifications for tickets you own (no matter 
who creates or updates them) then add another rule "Never notify: Ticket 
that I own is created or modified".
Make sure the blocking "Never notify" rules are above other rules that 
they should block.


Do you have other rules in you own account preferences? By "current 
rules" do you mean default rules?


If I misunderstood, please clarify and post excerpts from your log file.

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Readonly Ticket for all except Owner

[Peter Suter]

On 17.03.2017 19:32, Peter Suter wrote:

Hello

On 17.03.2017 16:31, Florian Schricker wrote:

Hello everybody,


I recently got a request whether it is possible to setup the 
permissions in a ticket workflow that when somebody issues an action 
"edit" on a ticket it is changed into a state "editing" where only 
the current owner can actually edit the ticket description.


Is this at all possible - maybe with the help of ReadonlyTickets hack 
as a basis?


It reminds me of this: 
https://trac.edgewall.org/wiki/CookBook/Configuration/SignedTickets

(I only now saw that this was you, too.)


(Is that what you meant by ReadonlyTickets hack?)
It sounds like it should be possible to adjust that here and there to 
get what you describe:

[ticket-workflow]
edit  =  new,assigned,accepted,reopened -> editing
sign.operations  =  set_owner_to_self

I meant: edit.operations = set_owner_to_self



# -*- coding: utf-8 -*-

from  trac.core  import  *
from  trac.perm  import  IPermissionPolicy
from  trac.ticket.model  import  Ticket


class  ReadonlyEditingTickets(Component):

 implements(IPermissionPolicy)

 allowed_actions  =  ('TICKET_VIEW',)

 def  check_permission(self,  action,  username,  resource,  perm):
 if  resource  is  None  or  resource.realm  !=  'ticket'  or  \
 resource.id  is  None  or  \
 action  in  self.allowed_actions:
 return  None

 t  =  Ticket(self.env,  resource.id)
 if  t['status']  ==  'editing'and t['owner'] != username:
 return  False
[trac]
permission_policies  =  ReadonlyEditingTickets, ...
Regards,
Peter



--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Trac 1.2 notifications, duplicate emails

[Peter Suter]

On 09.03.2017 08:43, Mo wrote:

Am Mittwoch, 8. März 2017 21:32:45 UTC+1 schrieb Peter Suter:

Do you have more than one active INotificationDistributorthat
supports transport email?


TracQuiet-1.2.0.dev0-py2.7.egg


Did you follow these instructions: 
https://trac-hacks.org/wiki/QuietPlugin#Installation

> disable EmailDistributor in your trac.ini file:
>[components]
>trac.notification.mail.EmailDistributor = disabled

If not and you still have both Trac's own EmailDistributorand 
TracQuiet's QuietEmailDistributorenabled, that would explain it.


Peter

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Permission to edit your own (submitted and assigned) tickets

[Peter Suter]

Hi,

On 09.03.2017 10:16, Mojca Miklavec wrote:

Hi,

At MacPorts we have a concept of "maintainers". These are people
without commit access to our repositories and without any elevated
permissions. These are volunteers who are responsible for maintaining
individual packages (providing patches etc.), but all their changes
need to be approved and committed by "senior" members who do some
quality control first. This is meant to lower the barrier to entry,
allowing anyone to volunteer to do the work even if they don't have
sufficient experience yet.

The problem is that these users get tickets assigned to them, but they
cannot do anything about them other than leaving further comments and
adding attachments. They cannot change title, edit description, add
keywords, CC any further developer to ask for help, ...

Another problem is that people who open a new ticket have no way to
make any further change to the ticket once they click a submit button.

Is there any way to give more permissions to owners of tickets and to
those who open the ticket?

There are some ancient potentially relevant tickets, but I suspect
that they were forgotten after so many years:

https://trac.edgewall.org/ticket/7438
https://trac.edgewall.org/ticket/10175

The request came from one of our users:
https://trac.macports.org/ticket/53755

Mojca



Can you try this cook book recipe?
https://trac.edgewall.org/wiki/CookBook/PermissionPolicies#GrantapermissiontotheTicketOwner

Peter

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Trac 1.2 notifications, duplicate emails

[Peter Suter]

On 08.03.2017 11:09, Mo wrote:

We get duplicate emails from the notification system.
What plugins do you use? Can you reproduce with all plugins disabled? Do 
you have more than one active INotificationDistributorthat supports 
transport email?


Even if 2 rules should apply like being Creator and Cc, the email 
notification should only be sent once.
Rules that result in the same notification over the same transport 
(email) to the same user are already de-duplicated.



|
[notification]
admit_domains =localdomain
email_sender =SendmailEmailSender
smtp_enabled =enabled
smtp_from =noreply@project-pp
smtp_from_name =Trac(project-pp)
smtp_replyto =
use_public_cc =enabled
use_short_addr =enabled

[notification-subscriber]
always_notify_author =AuthorCustomFieldSubscriber
always_notify_cc =CarbonCopySubscriber
always_notify_developer =DeveloperCustomFieldSubscriber
always_notify_integrator =IntegratorCustomFieldSubscriber
always_notify_owner =TicketOwnerSubscriber
always_notify_previous_updater =TicketPreviousUpdatersSubscriber
always_notify_reporter =TicketReporterSubscriber
always_notify_reviewer =ReviewerCustomFieldSubscriber
always_notify_tester =TesterCustomFieldSubscriber
never_notify_updater =TicketUpdaterSubscriber
never_notify_updater.adverb =never

|

From the logs:
|
2017-03-0810:38:54,076Trac[api]DEBUG:Adding(AK [1])for'always'on rule 
(TicketOwnerSubscriber)for(email)
2017-03-0810:38:54,076Trac[api]DEBUG:Adding(HS [1])for'always'on rule 
(TicketPreviousUpdatersSubscriber)for(email)
2017-03-0810:38:54,076Trac[mail]DEBUG:EmailDistributorhas found the 
following formats capable of handling 'email'of 
'ticket':text/html,text/plain
2017-03-0810:38:54,077Trac[mail]DEBUG:EmailDistributorfound the 
address 'a.k@localdomain'for'AK (authenticated)'via SessionEmailResolver
2017-03-0810:38:54,083Trac[default_workflow]DEBUG:render_ticket_action_control:action 
"leave"
2017-03-0810:38:54,083Trac[default_workflow]DEBUG:render_ticket_action_control:action 
"reopen"
2017-03-0810:38:54,146Trac[mail]DEBUG:EmailDistributorissending 
eventas'text/plain'to:h.s@localdomain
2017-03-0810:38:54,152Trac[mail]INFO:Sendingnotification through 
sendmail at sendmail to ['h.s@localdomain']
2017-03-0810:38:54,152Trac[mail]DEBUG:Sendmailcommand 
line:[u'sendmail','-i','-f','noreply@project-pp','h.s@localdomain']
2017-03-0810:38:55,348Trac[mail]DEBUG:EmailDistributorissending 
eventas'text/html'to:a.k@localdomain
2017-03-0810:38:55,359Trac[mail]INFO:Sendingnotification through 
sendmail at sendmail to ['a.k@localdomain']
2017-03-0810:38:55,360Trac[mail]DEBUG:Sendmailcommand 
line:[u'sendmail','-i','-f','noreply@project-pp','a.k@localdomain']
2017-03-0810:38:56,628Trac[mail]DEBUG:EmailDistributorhas found the 
following formats capable of handling 'email'of 
'ticket':text/html,text/plain
2017-03-0810:38:56,628Trac[mail]DEBUG:EmailDistributorfound the 
address 'a.k@localdomain'for'AK (authenticated)'via SessionEmailResolver
2017-03-0810:38:56,635Trac[default_workflow]DEBUG:render_ticket_action_control:action 
"leave"
2017-03-0810:38:56,636Trac[default_workflow]DEBUG:render_ticket_action_control:action 
"reopen"
2017-03-0810:38:56,699Trac[mail]DEBUG:EmailDistributorissending 
eventas'text/plain'to:h.s@localdomain
2017-03-0810:38:56,705Trac[mail]INFO:Sendingnotification through 
sendmail at sendmail to ['h.s@localdomain']
2017-03-0810:38:56,706Trac[mail]DEBUG:Sendmailcommand 
line:[u'sendmail','-i','-f','noreply@project-pp','h.s@localdomain']
2017-03-0810:38:57,910Trac[mail]DEBUG:EmailDistributorissending 
eventas'text/html'to:a.k@localdomain
2017-03-0810:38:57,922Trac[mail]INFO:Sendingnotification through 
sendmail at sendmail to ['a.k@localdomain']
2017-03-0810:38:57,922Trac[mail]DEBUG:Sendmailcommand 
line:[u'sendmail','-i','-f','noreply@project-pp','a.k@localdomain']

|

In /prefs/notification we need to duplicate some rule for some 
accounts as there is the bug that text/html is not saved if there is 
not a single custom rule. But even with duplicate rules, a 
notification should always be sent only once.


There is another bug, adding a rule in /prefs/notification this rule 
is added twice. Deleting the duplicate custom rule, saving, there are 
2 rules again. Deleting both, both are deleted. But adding another one 
it is added twice again.
I have no idea how that could happen. Can you reproduce with all plugins 
disabled?




Isn't the whole notification system still in a ~testing stage? Will 
1.2 get updates as it is a LTS version I was told?

best gegards,
Mo


Best regards,
Peter

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Notification in Trac 1.2

[Peter Suter]

On 23.02.2017 21:54, ivanelson wrote:

I put it in [notification]. After this came the error:

You should put them in the [notification-subscriber] section.

[notification-subscriber]
always_notify_owner =TicketOwnerSubscriber
always_notify_owner.format = text/html
always_notify_cc =CarbonCopySubscriber
always_notify_cc.format = text/html
always_notify_previous_updater =TicketPreviousUpdatersSubscriber
always_notify_previous_updater.format = text/html
always_notify_updater =TicketUpdaterSubscriber
always_notify_updater.format = text/html

2017-02-23 17:48:43,067 Trac[mail] DEBUG: EmailDistributor has found 
the following formats capable of handling 'email' of 'ticket': 
text/html, tex

t/plain
2017-02-23 17:48:43,068 Trac[web_ui] ERROR: Failure sending 
notification on change to ticket #14377: ConfigurationError: Cannot 
find implementatio
n(s) of the IEmailAddressResolver interface named 
DefaultDomainEmailResolver, 
SpecifiedEmailResolver. Pleas
e check that the Component is enabled or update the option 
[notification] email_address_resolvers in trac.ini.


Here it is:

[notification]
email_address_resolvers 
=SpecifiedEmailResolver,SessionEmailResolver,DefaultDomainEmailResolver

These  don't exist in Trac. You should just have this:
email_address_resolvers =SessionEmailResolver



email_enabled =enabled
email_from =siste...@xxx.com.br
email_from_name =xx - Depto de TI .:: Ger. de Desenvolvimento ::.
email_replyto =
email_subject_prefix =__default__
email_to =undisclosed-recipients:
mime_encoding =base64
smtp_port =25
smtp_enabled =enabled
smtp_password =xxx
smtp_server =xx
smtp_user =x...@xxxa.com.br
use_public_cc =disabled
use_tls =enabled
always_notify_cc.format =text/html
always_notify_previous_updater.format =text/html
always_notify_updater.format =text/html

[notification-subscriber]
always_notify_owner =TicketOwnerSubscriber
always_notify_cc =CarbonCopySubscriber
always_notify_previous_updater =TicketPreviousUpdatersSubscriber
always_notify_updater =TicketUpdaterSubscriber


Em quinta-feira, 23 de fevereiro de 2017 16:51:49 UTC-3, Peter Suter 
escreveu:


On 23.02.2017 19:41, ivanelson wrote:
> The documentation is not clear.
>
> I am currently like this:
>
> [notification]
> ...
> default_format =text/html
This option does not exist. You can delete this line.
https://trac.edgewall.org/wiki/TracIni#notification-section
<https://trac.edgewall.org/wiki/TracIni#notification-section>

> [notification-subscriber]
> always_notify_cc =CarbonCopySubscriber
> always_notify_previous_updater =TicketPreviousUpdatersSubscriber
> always_notify_updater =TicketUpdaterSubscriber
This section configures the default subscriptions.
If you have TracHtmlNotificationPlugin installed, you can add the
following lines here:
always_notify_cc.format = text/html
always_notify_previous_updater.format = text/html
always_notify_updater.format = text/html

This format will then be used for these default subscriptions.
If a user has custom rules defined that override default
subscriptions,
then the user's saved format preference will be used for emails
triggered by that rule.

Peter

--
You received this message because you are subscribed to the Google 
Groups "Trac Users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to trac-users+unsubscr...@googlegroups.com 
<mailto:trac-users+unsubscr...@googlegroups.com>.
To post to this group, send email to trac-users@googlegroups.com 
<mailto:trac-users@googlegroups.com>.

Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.



--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Notification in Trac 1.2

[Peter Suter]

On 23.02.2017 19:41, ivanelson wrote:

The documentation is not clear.

I am currently like this:

[notification]
...
default_format =text/html

This option does not exist. You can delete this line.
https://trac.edgewall.org/wiki/TracIni#notification-section


[notification-subscriber]
always_notify_cc =CarbonCopySubscriber
always_notify_previous_updater =TicketPreviousUpdatersSubscriber
always_notify_updater =TicketUpdaterSubscriber

This section configures the default subscriptions.
If you have TracHtmlNotificationPlugin installed, you can add the 
following lines here:

always_notify_cc.format = text/html
always_notify_previous_updater.format = text/html
always_notify_updater.format = text/html

This format will then be used for these default subscriptions.
If a user has custom rules defined that override default subscriptions, 
then the user's saved format preference will be used for emails 
triggered by that rule.


Peter

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Notification in Trac 1.2

[Peter Suter]

On 22.02.2017 21:08, ivanelson wrote:

Hi

Does the notification system already support sending emails in html?


Yes, with this plugin: 
https://trac-hacks.org/wiki/TracHtmlNotificationPlugin


--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

[Trac] Re: TicketQuery: filter by one keywords, exclude other keyword

[Peter Suter]

Hi

On Tuesday, February 21, 2017 at 8:40:30 AM UTC+1, Florian Schricker wrote:
>
>
> I do not know whether this is possible at all but I dare asking: Is it 
> possible to setup a TicketQuery macro to include tickets with a specific 
> keyword (keywords~=word1) but excluding all tickets which contain another 
> specific keywords (keywords!=word2)?
>

Yes, it is possible and easy, but not at all obvious from the 
documentation. The trick (mentioned in 
https://trac.edgewall.org/ticket/10152 only?) is to use a - (dash, minus 
sign) for the excluded word2 in the same keywords clause:
[[TicketQuery(keywords~=word1 -word2)]]

Regards,
Peter

-- 
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] trac-hacks.org upgraded to Trac 1.2

[Peter Suter]

On 13.02.2017 00:11, RjOllos wrote:

Please reply here if you spot any issues with the site that may be
related to the upgrade.

Known issues are listed in the description of #11949:
https://trac-hacks.org/ticket/11949

- Ryan


Nice, thanks!

Attachments seem to be missing / inaccessible: I get a 404 for 
attachments of the https://trac-hacks.org/wiki/WikiAutoCompletePlugin 
wiki page for example.


Peter

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Customizing the e-mail content of notifications

[Peter Suter]

On 09.02.2017 12:18, Mo wrote:

Am Freitag, 27. Januar 2017 11:50:11 UTC+1 schrieb RjOllos:


Have you looked at TracHtmlNotificationPlugin?

(3) https://trac-hacks.org/wiki/TracHtmlNotificationPlugin



I have installed that and it works for me. Reloading the preference 
page, the text/plain settings is there again, it does not seem to 
reflect my current setting, but it works, I get html mails.
However I can't get it working for other users. Do they need some 
permissions?


Where is the setting stored for the user so I can analyse if the 
setting is stored? The users save the text/html setting but still get 
plain mails. This is Trac-1.2.


See https://trac.edgewall.org/ticket/11928

When users have no subscription saving the format doesn't work.
For default subscriptions you can now pre-configure the format in 
trac.ini [notification-subscriber] section by setting format = 
text/html I think.


--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] How can I write nestable tables?

[Peter Suter]

On 06.02.2017 13:59, Mingxing Tian wrote:
When I use the following methods, can not complete the requirements, 
they can not achieve the form of nesting.


|||=xx=||=xx=||
|| || |||

|
{{{#table
}}}
|

I hope to achieve the final results, what programs can make the 
following table?


No. 	Module 	Sub-module 	Functional operation 	Functional 
characteristics 	Hours 	Owne

1   xx  xx  xxx Functional characteristics  Hours   Owne
4   all
xxx 1   allen
xxx 2   kitten
xxx 1   apple
2   xx  xx  xxx Functional characteristics  Hours   Owne
8   allen
xxx 3   allen
xxx 5   allen



You can use {{{!td }}} for the outer table cell and || for the inner table:

||= No. =||= Module =||= Sub-module =||= Functional operation =||= 
Functional characteristics =||= Hours =||= Owner =||

{{{#!td
1
}}}
{{{#!td
xx
}}}
{{{#!td
xx
}}}
{{{#!td
xxx
}}}
{{{#!td
||= Functional characteristics =||= Hours =||= Owner =||
|| xxx || 1 || allen ||
|| xxx || 2 || kitten ||
|| xxx || 1 || apple ||
}}}
|| 4 || all ||
|---
{{{#!td
2
}}}
{{{#!td
xx
}}}
{{{#!td
xx
}}}
{{{#!td
xxx
}}}
{{{#!td
||= Functional characteristics =||= Hours =||= Owner =||
|| xxx || 3 || allen ||
|| xxx || 5 || allen ||
}}}
|| 8 || allen ||
|---

Or alternatively you can use colspan / rowspan in one single 9*8 table:

{{{#!td
No.
}}}
{{{#!td
Module
}}}
{{{#!td
Sub-module
}}}
{{{#!td
Functional operation
}}}
{{{#!td colspan=3
 Functional characteristics
}}}
||= Hours =||= Owner =||
|---
{{{#!td rowspan=4
1
}}}
{{{#!td rowspan=4
xx
}}}
{{{#!td rowspan=4
xx
}}}
{{{#!td rowspan=4
xxx
}}}
{{{#!td
Functional characteristics
}}}
{{{#!td
Hours
}}}
{{{#!td
Owner
}}}
{{{#!td rowspan=4
4
}}}
{{{#!td rowspan=4
all
}}}
|---
|| xxx || 1 || allen ||
|| xxx || 2 || kitten ||
|| xxx || 1 || apple ||
|---
{{{#!td rowspan=3
2
}}}
{{{#!td rowspan=3
xx
}}}
{{{#!td rowspan=3
xx
}}}
{{{#!td rowspan=3
xxx
}}}
{{{#!td
Functional characteristics
}}}
{{{#!td
Hours
}}}
{{{#!td
Owner
}}}
{{{#!td rowspan=3
8
}}}
{{{#!td rowspan=3
all
}}}
|---
|| xxx || 3 || allen ||
|| xxx || 5 || allen ||

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: failed attempts to use a custom EmailResolver

[Peter Suter]

Sorry, I just noticed some of your mails ended up in my spam folder for 
some reason.


On 18.01.2017 09:43, Sandro Santilli wrote:

On Tue, Jan 17, 2017 at 07:34:34PM +0100, Peter Suter wrote:

I think the problem is that we can't really know if these are actually
usernames, and at the moment the only thing we can reasonably do is check
against the known usernames.

What else could they be ?
The RecipientMatcher class is not documented so it is not clear
what the expected input is.
The input is some string found in a ticket field. It could be an email 
address, a username or just a plain name, or even something (anything) else.
RecipientMatcher is trying to find matching known usernames or valid 
email addresses that could be used as recipients.
The reason that RecipientMatcher does exactly that is mainly backward 
compatibility. Those are the things that have been supported 
historically, so they should continue to work.

As a last (and not very satisfying) resort, you could also replace all the
INotificationSubscribers with your own implementations that work like you
want I guess. :/

This would be no different than applying the patch above, right ?

It would only be different in that you don't have to patch the source.

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Reorder component list?

[Peter Suter]

On 20.01.2017 13:08, Florian Berger wrote:

Hi,

On 19.01.2017 23:30, RjOllos wrote:

The component list is sorted alphabetically. You can see this in the code,
and on trac.edgewall.org/demo-1.0

Well, look at the screenshot.

http://0x6c2.de/images/2017-trac-components.png

Let me guess:

- Capital ASCII letters in alphabetical order first

- followed by lowercase letters in alphabetical order

- followed by non-ASCII characters.

That would explain it.

As a naive user, my eyes would expect to find "n" between "M" and "P",
i.e. non-case sensitive ordering.

And as a German, I would expect to find "Ö" right after "O" and before
"P", and "Ü" right after "U" and before "V", which is the common
alphabetical ordering for German umlauts.


As this seems to be a matter of taste and I18N - and not necessarily a
bug - is there a way to fix the search order for my requirements,
without hacking into the trac internals?

Or would I need to write a plugin?

In this case the sorting seems to be performed by the SQL database.
Maybe you can configure the SQL database collation?
How to do this depends on the database used.
However I think Trac doesn't support localized collations on MySQL. 
https://trac.edgewall.org/ticket/10993
And SQLite might not really support configuring a collation easily 
either, I'm not sure.


Best regards,
Peter

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Notification in Trac 1.2

[Peter Suter]

On 23.01.2017 11:53, Mo wrote:

Am Donnerstag, 19. Januar 2017 19:24:52 UTC+1 schrieb Peter Suter:

On 19.01.2017 14:38, Mo wrote:

Additionally I skip notifications if the change was done by
myself. For all existing Subscribers in Trac I created
alternative copies doing the same while dropping my own changes.

Why don't you simply add a rule "Never notify: I update a ticket"?


Peter, can I make that system-default by adding

|
never_notify_updater =TicketUpdaterSubscriber
never_notify_updater.adverb =never
|

|Yes, that's correct.

Best regards,
Peter
|

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Notification in Trac 1.2

[Peter Suter]

On 23.01.2017 13:23, Mo wrote:

Am Donnerstag, 19. Januar 2017 19:24:52 UTC+1 schrieb Peter Suter:


no notification for any other changes on the ticket.

Does this work?

|if'fields'inevent.changes andnot all(self.field_name == key for
key inevent.changes['fields']):
return|


What does that do exactly?
It ignores events where the change to the custom field are not the only 
ticket changes.


I like to get notifications if my name is listed in field 'developer' 
AND any of the fields 'developer' OR 'developer-status' has changed.


More like this?

|if'fields'inevent.changes andnot all(key in ['developer', 
'developer-status']for key inevent.changes['fields']):

return

Best regards,
Peter

|

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: trac 1.2 and ticket comment editing

[Peter Suter]

On 20.01.2017 10:40, Roger Oberholtzer wrote:

On Fri, Jan 20, 2017 at 8:56 AM, RjOllos  wrote:


On Thursday, January 19, 2017 at 11:47:47 PM UTC-8, Roger Oberholtzer wrote:

On Thu, Jan 19, 2017 at 11:01 PM, RjOllos  wrote:


Another common reason for similar issue is not refreshing the static
resources when upgrading Trac:
https://trac.edgewall.org/wiki/TracUpgrade#a5.Refreshstaticresources

I have never done this deploy thing. I have no /deploy/path. Or at
least not one that I have made. Is there a default one if I have never
used the deploy option?


Depends on how your web server is configured:
https://trac.edgewall.org/wiki/TracInstall#MappingStaticResources

I suggest you view the page source for a page such as WikiStart on a
computer that exhibits the issue, and follow the link to a static resource
such as trac.css or trac.js. Compare to the repository version to determine
if you are serving the latest,
https://trac.edgewall.org/browser/tags/trac-1.2/trac/htdocs/js/trac.js
https://trac.edgewall.org/browser/tags/trac-1.2/trac/htdocs/css/trac.css

What I see in the browser matches exactly what I see in the css file
on the server. In the case of the comment buttons at least.

For example, the file ./Trac-1.2-py2.7.egg/trac/htdocs/css/ticket.css contains:

/*  - Change controls */
.trac-ticket-buttons {
  clear: right;
  visibility: hidden;
  float: right;
}

And I see exactly that in the browser. If I remove  "visibility:
hidden;" in the browser, the buttons show up. And, if I remove the
same text in the css file, the buttons also show up.

The questions is: why is "visibilty: hidden;" set in the css file? I
am guessing that is the default. How does it get set to something
else? Where would I see that in the browser?


The buttons are not shown by default anymore, only when the mouse hovers 
over a comment.
(Or when both checkboxes "[ ] Show comments [ ] Show property changes" 
are unchecked.)

https://trac.edgewall.org/browser/tags/trac-1.2/trac/htdocs/js/threaded_comments.js?marks=50-76#L50
https://trac.edgewall.org/ticket/11835

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Notification in Trac 1.2

[Peter Suter]

On 19.01.2017 14:38, Mo wrote:
Additionally I skip notifications if the change was done by myself. 
For all existing Subscribers in Trac I created alternative copies 
doing the same while dropping my own changes.

Why don't you simply add a rule "Never notify: I update a ticket"?



no notification for any other changes on the ticket.

Does this work?

|if'fields'inevent.changes andnot all(self.field_name == key for key 
inevent.changes['fields']):

return
|

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Trac 1.2 notifications

[Peter Suter]

On 19.01.2017 17:59, Jun Omae wrote:

AllTicketSubscriber is mentioned in
https://trac.edgewall.org/ticket/11870#comment:7 but is not
implemented yet. I'll post proposed changes for "Any ticket is created
or modified" and "Any ticket is created". 

Just in case it helps, old implementation proposal is here:
https://trac.edgewall.org/ticket/11870#comment:3
https://trac.edgewall.org/log/psuter.hg/?rev=T11870_optional_subscribers
https://trac.edgewall.org/changeset/35ddfce6242383f9276932bf8f04630be83f1068/psuter.hg/
I didn't want to commit features of so far zero apparent interest.

Peter

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Notifications on custom fields

[Peter Suter]

On 16.01.2017 16:25, Mo wrote:

Am Montag, 16. Januar 2017 16:10:21 UTC+1 schrieb Mo:


I did not set email_address_resolvers, so having the default it
should be set to SessionEmailResolver, according

https://trac.edgewall.org/wiki/TracIni#notification-email_address_resolvers-option

.
There is no other option.
When I was using AnnouncerPlugin on Trac 1.0.9 I had
email_address_resolvers =
SpecifiedEmailResolver,SessionEmailResolver,DefaultDomainEmailResolver.


Sorry, the old setting was still enabled when I copy-pasted from old 
[announcer] to [notification]. I deleted that line, and it's working now.
Still the question, which resolvers are there and how are email 
adresses determined without AccountManagerPlugin and basic auth via 
webserver only.


Sorry, I don't fully understand your question.

SessionEmailResolver is the only one by default. AccountManagerPlugin is 
not involved in this I think.


Possibly your problem is related to https://trac.edgewall.org/ticket/12660?
All active IEmailAddressResolver components are always used in Trac 1.2, 
even if not listed in email_address_resolvers. (This will be fixed in 
Trac 1.2.1.)


--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Notifications on custom fields

[Peter Suter]

On 16.01.2017 15:51, Mo wrote:

Am Mittwoch, 4. Januar 2017 19:51:59 UTC+1 schrieb Peter Suter:


def description(self):
return "Ticket that I'm listed in as %s is modified" %
self.field_name


Learning Python and INotificationSubscriber...
How would I replace that field_name by the real label text configured 
in trac.ini?


Try:

from trac.ticket.api import TicketSystem

def description(self):
ticket_system = TicketSystem(self.env)
ticket_field_labels = ticket_system.get_ticket_field_labels()
field_label = ticket_field_labels[self.field_name]
return "Ticket that I'm listed in as %s is modified" % field_label

(Untested)

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: failed attempts to use a custom EmailResolver

[Peter Suter]

On 11.01.2017 22:32, Sandro Santilli wrote:

2017-01-11 22:26:17,280 Trac[web_ui] ERROR: Failure sending notification on 
change to ticket #777: TypeError: get_address_for_session() takes exactly 2 
arguments (3 given)


The LdapEmailAddressResolverexample was missing the self parameter:
https://trac.edgewall.org/wiki/TracDev/PluginDevelopment/ExtensionPoints/trac.notification.api.IEmailAddressResolver?action=diff=6

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

[Trac] Re: failed attempts to use a custom EmailResolver

[Peter Suter]

On Wednesday, January 11, 2017 at 4:42:56 PM UTC+1, Sandro Santilli wrote:
>
> I've been trying all day to make the LdalEmailAddressResolver 
> work for my setup but failed miserably. 
>
> The example: 
>
> https://trac.edgewall.org/wiki/TracDev/PluginDevelopment/ExtensionPoints/trac.notification.api.IEmailAddressResolver#Examples
>  
>
> My setup is Apache taking care of the authentication so that trac 
> only has usernames to work with, and no emails at all. 
>
> Adding debugging code brought me to understand that the "distribute" 
> method of the INotificationDistributor implementation is not even 
> entered unless the RecipientMatcher provides it with an address, 
> which is not the case when the domain is unknown. Code block I'm 
> looking at is notification/mail.py:235: 
>
> elif not is_email(address) and self.nodomaddr_re.match(address): 
> if self.env.config.getbool('notification', 'use_short_addr'): 
> return (None, 0, address) 
> domain = self.env.config.get('notification', 
>  'smtp_default_domain') 
> if domain: 
> address = "%s@%s" % (address, domain) 
> else: 
> self.env.log.info("Email address w/o domain: %s", 
> address) 
> return None 
>
> There we usually plug our custom code, looking up email from LDAP 
> instead o complaining "Email address w/out domain". I was hoping this 
> would be done automatically but there's clearly no code doing that 
> in that method. Is it a bug or a design choice for some reason ? 
>


It might be a bug (or a scenario not supported so far).
Could you try replacing that last "return None" with "return address, 1, 
None"?

Announcer uses "(sid, 1, None)" when an email address is not recognized:
https://trac-hacks.org/browser/announcerplugin/trunk/announcer/subscribers.py#L151

We should maybe use "(sid, 1, None)" if RecipientMatcher returns None.

 

>
> I've been logging some of my findings in the ticket but then was asked 
> to continue here: https://trac.edgewall.org/ticket/3162#comment:16 
>
> Background information about our customization can be found here: 
> https://trac.osgeo.org/osgeo/ticket/39 
>
> Thanks in advance for any info you may give me to help with dropping the 
> custom modification and finally be upgrade-happy again. 
>
> --strk; 
>


Thanks,
Peter 

-- 
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Workflow: Disable modifying ticket description only

[Peter Suter]

Hi

On 10.01.2017 13:51, Florian Schricker wrote:

Hi,


I have a follow-up question on the "readonly tickets" plugin:

Trac now only allows commenting a ticket when the ticket type matches 
the list of tickets in the plugin. But the ticket workflow has an 
action "change" defined which would move the ticket to state "new". Is 
it possible to detect this with the plugin and allow such an action?


Maybe you could define an extra permission, configure the workflow 
action "change" to require (only) that permission, and add that 
permission to the "allowed_actions" of the readonly plugin?

It seems this is similar to what's described here:
https://trac.edgewall.org/wiki/CookBook/Configuration/SignedTickets#TICKET_SIGNpermission
https://trac.edgewall.org/wiki/CookBook/Configuration/SignedTickets#Signworkflowstep

Best regards,
Peter

(By the way, I think the "mutual recursion" flaw has now been improved 
in Trac: https://trac.edgewall.org/ticket/12597)


--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Notifications on custom fields

[Peter Suter]

On 05.01.2017 11:17, Mo wrote:


Any major migration issues with 1.0 to 1.2? I'll test on a snapshot 
anyway.


Not really, but it maybe depends on what you consider major. Make sure 
to check:

https://trac.edgewall.org/wiki/TracUpgrade
https://trac.edgewall.org/wiki/TracUpgrade#to1.2
https://trac.edgewall.org/wiki/TracUpgrade#KnownIssues

And especially check all your Plugins! A lot of old plugins from the 
Trac 0.x days had / have yet to be updated:

https://trac-hacks.org/query?release=1.2=status=id=summary=owner=type=status=priority=component=priority


That could look something like this (untested):

...

Is that code already something that would work as a single-file 
plugin.py in ./plugins already?
Yes, except I made a small mistake: Replace `user_set` by `field_set`. 
Then it should work.


Beside from that, a rule framework configurable on the user 
preferences would be preferable.

Could you explain a bit more what kind of flexibility you're looking for?
The single-file plugin subscriber actually adds a rule that can be 
configured in the user preferences (and / or by the site admin as 
overridable default).

The basics rules available by default look something like this:
https://trac.edgewall.org/attachment/wiki/TracDev/Proposals/AdvancedNotification/notification-subscription-prefs.png

But you can add more subscribers like above to get more rules in the 
Trac 1.2 framework.

Adding some that are similar to those in Announcer you would get this:
https://trac.edgewall.org/attachment/ticket/11870/watch-prefs.png


https://www.trac-hacks.org/wiki/MailPlugin
I'm not familiar with that plugin, but it's likely it won't work 
unchanged with Trac 1.2.


Best regards,
Peter

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Notifications on custom fields

[Peter Suter]

On 04.01.2017 16:38, Mo wrote:

I managed to add custom fields for User roles
Might be nice to write up your solution as a cookbook similar to 
https://trac.edgewall.org/wiki/CookBook/Configuration/SignedTickets


But most important we would need notifications based on Roles. That 
would mean a tester gets a notification if he was added to a Tester role.


I looked at AnnouncerPlugin which only has a very small set of static 
rules and does not support any custom fields. Then I looked at 
XMailPlugin (or called MailPlugin), that could create any SQL filter 
for mail notifications, but only SQL based. That could work, any other 
idea to have custom filter rules for mail notifications, user based 
and global ones by the administrator?


Trac 1.2's new notification system  would allow you to write a small 
single-file plugin implementing INotificationSubscriber.

https://trac.edgewall.org/wiki/TracDev/Proposals/AdvancedNotification
https://trac.edgewall.org/wiki/TracDev/PluginDevelopment#Singlefileplugins
https://trac.edgewall.org/wiki/TracDev/PluginDevelopment/ExtensionPoints/trac.notification.api.INotificationSubscriber#Examples

If I understand you correctly you want notification subscriptions 
exactly like the CC field provides, but for a custom field.
So I think you could basically copy the component that implements the CC 
field notifications (CarbonCopySubscriber) and replace 'cc' by your 
custom field name.

https://trac.edgewall.org/browser/trunk/trac/ticket/notification.py?rev=15148=712-759#L711

That could look something like this (untested):

from trac.core import Component, implements
from trac.notification.api import INotificationSubscriber, 
NotificationSystem

from trac.notification.mail import RecipientMatcher
from trac.notification.model import Subscription
from trac.web.chrome import Chrome

class TesterCustomFieldSubscriber(Component):
"""Subscriber for custom ticket field."""

implements(INotificationSubscriber)

field_name = 'tester'

def matches(self, event):
if event.realm != 'ticket':
return
if event.category not in ('created', 'changed', 'attachment added',
  'attachment deleted'):
return

# Custom field with comma-separated string. Parse to set.
chrome = Chrome(self.env)
to_set = lambda field: set(chrome.cc_list(field))
user_set = to_set(event.target[self.field_name] or '')

# Harvest previous field values
if 'fields' in event.changes and self.field_name in 
event.changes['fields']:

field_set.update(to_set(event.changes['fields'][self.field_name]['old']))

matcher = RecipientMatcher(self.env)
klass = self.__class__.__name__
sids = set()
for field in field_set:
recipient = matcher.match_recipient(field)
if not recipient:
continue
sid, auth, addr = recipient

# Default subscription
for s in self.default_subscriptions():
yield s[0], s[1], sid, auth, addr, s[2], s[3], s[4]
if sid:
sids.add((sid, auth))

for s in Subscription.find_by_sids_and_class(self.env, sids, 
klass):

yield s.subscription_tuple()

def description(self):
return "Ticket that I'm listed in as %s is modified" % 
self.field_name


def default_subscriptions(self):
klass = self.__class__.__name__
return NotificationSystem(self.env).default_subscriptions(klass)

def requires_authentication(self):
return True

-
If you want to stick with Trac 1.0 and Announcer, you could try 
something similar with Announcer's equivalent: IAnnouncementSubscriber

/ CarbonCopySubscriber.
https://trac-hacks.org/browser/announcerplugin/trunk/announcer/subscribers.py#L55

Actually the Announcer branch 0.11 already had a 
TicketCustomFieldSubscriberthat did something similar. I don't know why 
it doesn't exist in the 1.0 branch.

https://trac-hacks.org/browser/announcerplugin/branches/0.11/announcerplugin/subscribers/ticket_custom.py

Best regards,
Peter

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Batch modify and timeout

[Peter Suter]

There's a detailed overview of the (not) integrated functionality here:
https://trac.edgewall.org/wiki/TracDev/Proposals/AdvancedNotification

Individual configuration per user is there.

Cheers,
Peter

On 23.12.2016 11:31, Mo wrote:

Yes, Announcer send an email for every ticket.

Interesting. The individual configuration of email notifications for 
every user is a requirement for us, like this is possible in Bugzilla.
Our current version of AnnouncerPlugin is still not very flexible to 
create custom rules, only some sets of notifications are selectable.
Thanks for your efforts for a new version. Good to hear that parts of 
it are integrated into Trac core. What is the mail reason for the 
Plugin on Trac 1.2, which main parts are not integrated yet?


Best regards,
Mo

Am Donnerstag, 22. Dezember 2016 17:54:33 UTC+1 schrieb RjOllos:



Do you receive an email notification for every ticket that is
changed? Batch modify will only send one email notification for
all tickets that are changed, however Announcer may send a
notification for each ticket that is changed. If so, that's a
problem with Announcer.

As for dealing with the problem, much of AnnouncerPlugin has been
added to Trac in release 1.2. I'm working on a Trac 1.2-compatible
version of AnnouncerPlugin. When that is ready you could upgrade
to Trac 1.2.

- Ryan

--
You received this message because you are subscribed to the Google 
Groups "Trac Users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to trac-users+unsubscr...@googlegroups.com 
.
To post to this group, send email to trac-users@googlegroups.com 
.

Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.



--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Workflow: Disable modifying ticket description only

[Peter Suter]

On 22.09.2016 09:27, Florian Schricker wrote:


So I am wondering if "patching" PrivateTicketsPolicy/check_permission 
would do the trick: By adding "TICKET_ADMIN" to the list of "ignore 
permissions / actions" the "mutual recursion" would stop, wouldn't it?



Yes, or at least it sounds plausible to me that this might work.
Is it acceptable to you that anyone with TICKET_ADMIN permission will 
not be restricted by the private tickets policy?
Normally the PrivateTicketsPlugin requires TRAC_ADMIN permission to see 
all private tickets.


Please let us know if you test this.

Peter

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Workflow: Disable modifying ticket description only

[Peter Suter]

On 22.09.2016 07:17, RjOllos wrote:

Based on what you said, I considered if we could detect re-entrancy by
passing the policy to the permission cache when doing a
PermissionCache.has_permission check inside of
PermissionCache.check_permission:
https://trac.edgewall.org/ticket/12597



Replied in ticket.


I also posted modifications to SignedTickets, but I don't expect they
will fix this "interaction" issue:
https://trac.edgewall.org/wiki/CookBook/Configuration/SignedTickets?version=9


>>> -  'TICKET_ADMIN' in perm:
>>> +  any(a in perm for a in self.admin_actions):

This change seems unnecessary and maybe even more problematic than before.
Unnecessary because TRAC_ADMIN implies TICKET_ADMIN anyway, so there's 
no need to check for TRAC_ADMIN explicitly. (But there may be more 
subtle details I'm missing.)
Problematic because checking more permissions leads to more potentially 
problematic interactions (and possible mutual recursion) with other 
policies.




Peter

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Workflow: Disable modifying ticket description only

[Peter Suter]

On 21.09.2016 09:06, Florian Schricker wrote:

Unfortunately it still fails.

This time I am attaching a more or less complete log from tracd-start 
until "recursion error" and the source file of the plugin I am using.


I hope that helps - I am more than willing in testing anything while 
providing any information I can collect. Any config files or other 
files of interest? Just let me know.


regards,
Florian

Am Freitag, 16. September 2016 03:16:17 UTC+2 schrieb RjOllos:

On Tuesday, August 30, 2016 at 12:25:26 AM UTC-7, Florian
Schricker wrote:

While this now fixes the Timeline function, modifying tickets
now fails with the same recursion error. I have not yet
checked the logs.

For a better understanding let me ask the following question:

From my research I was not expecting the policies to
"interact" with each other recursively at all. I was thinking
that all configured policies are asked in sequence until some
policy returns True or False, with returning None just meaning
"ask the next policy". Where is the recursion? Is it a bug
in TracPrivateTickets?



It's "mutual recursion". Unfortunately that means it's not a simple bug 
you can necessarily fix in one plugin alone. It's an unfortunate 
interaction between the two plugins.
The idea was, exactly as you say, to ask each policy in turn. But each 
plugin basically says: "Hang on, before I answer, let me ask you this 
first: Is this other thing allowed?"
And again each policy is asked in turn about this new question, and so 
on forever...


Each policy is protected against its own such recursive questions:


Am Freitag, 16. September 2016 03:16:17 UTC+2 schrieb RjOllos:

There shouldn't be recursion in ReadonlySignedTickets because of
the check "action == 'TICKET_ADMIN' or 'TICKET_ADMIN' in perm".
"'TICKET_ADMIN' in perm" will cause a recursive permission check
for the action TICKET_ADMIN, but when ReadonlySignedTickets is
called again it will return None due to the "action ==
'TICKET_ADMIN'" conditional.

But neither policy can detect re-entrancy in general. It only shortcuts 
its own kind of followup question.
Since the other policy asks about a different kind of permission, this 
is not detected.


It's basically again the same problem as before.

Detailed step-by-step description of events:
1. The initial question is from web_ui.py about TICKET_VIEW.
2. The Permission System asks each policy about this in turn.
3. First it asks the privatetickets policy, which interjects 
(recursively calls):
   "To answer that, I first need to know if TICKET_VIEW_REPORTER is 
available."
4. The Permission System again poses this new question to each policy in 
turn.
5. First it asks the privatetickets policy, which expected this and 
replies "None".

(This is not visible in the stack trace.)
6. Then it asks ReadonlyTicketsPlugin, which interjects:
   "To answer that, I first need to know if TICKET_ADMIN is available."
7. The Permission System again poses this new question to each policy in 
turn.
8. First it asks the privatetickets policy, which interjects 
(recursively calls):
   "To answer that I first need to know if TICKET_VIEW_REPORTER is 
available".


And since 8. is exactly the same situation as 3. it continues in the 
same way forever.




The dangerous thing is calling perm.has_permission(action2) inside 
check_permission(...action1...).
But it's only a problem if a second policy calls 
perm.has_permission(action1) inside check_permission(...action2...).

(Or some similar more complex variations.)

How can this be avoided?
One way is that by convention all policies must make sure not to "go 
back to an earlier question".
For example if all permission actions are ordered somehow (for example 
TRAC_ADMIN>TICKET_ADMIN>TICKET_VIEW>...) ,
then inside check_permission(...action1...) only use 
perm.has_permission(action2) if action2>action1.

But the PrivateTickets policy does not follow such a convention.

I think it's an inherent problem with the design that was not foreseen.
You can sometimes add workarounds for specific situations, as in the 
first case.
In this case it might be easier to add the workaround to the 
PrivateTickets policy.



Peter

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Sign an outgoing email from Trac?

[Peter Suter]

On 10.06.2016 21:00, RjOllos wrote:

On Friday, June 10, 2016 at 7:36:27 AM UTC-7, Aikido Guy wrote:

I searched trac-hacks and google and tried to find out if it is
possible to sign (e.g.
https://www.gnupg.org/gph/en/manual/x135.html

)
an outgoing email from Trac. Not much luck.

I'm not aware of a plugin that implements the feature, but you might 
be able to create one in the forthcoming Trac 1.2, which has extension 
points in the notification system. I'm not sure which extension point 
you need to implement for signing, but you might start by looking at:

https://trac.edgewall.org/wiki/TracDev/PluginDevelopment/ExtensionPoints/trac.notification.api.INotificationDistributor
https://trac.edgewall.org/wiki/TracDev/PluginDevelopment/ExtensionPoints/trac.notification.api.IEmailDecorator


The (somewhat stale) development branch of AnnouncerPlugin might 
implement this:

https://trac-hacks.org/wiki/AnnouncerPlugin#DevelopmentVersion
https://trac-hacks.org/browser/announcerplugin/trunk/announcer/util/mail_crypto.py#L47
https://trac-hacks.org/browser/announcerplugin/trunk/announcer/distributors/mail.py#L165

(GnuPG encryption (not signing) was also once worked on here:
https://trac.edgewall.org/ticket/8294
But that's probably very outdated and unusable.)

But I agree that a Trac 1.2 plugin (preferably using IEmailDecorator) 
would be my preferred way to go.


Peter

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Levels or Wikis or Subwikis

[Peter Suter]

Hi

On 01.02.2016 12:05, Mo wrote:
Then what I wonder is that the installed wikis like 
*TracAccessibility*, *TracAdmin* etc. make a generic tree view in the 
*TitleIndex* page. But if I name my wikis like *TestFoo* and *TestBar* 
I don't get that tree structure in the index.
More curious the specific subwiki approach with *Test/Foo **Test/Bar 
*does'nt show a tree structure either but only the path names in a 
plain list. What's wrong?
The TitleIndex page usually contains the macro 
[[TitleIndex(format=group,min=4)]] so it only starts a group when at 
least four pages share the same structure.


http://trac.edgewall.org/browser/trunk/trac/wiki/default-pages/TitleIndex?format=txt

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] How does trac interact with a version control system?

[Peter Suter]

Hi
Trac never modifies any files of or in Mercurial (or any other VCS).
Generally Trac does not interact with the VCS that much except for 1. 
browsing and 2. updating tickets via commit messages:


1. Browsing files and viewing changesets etc. stored in the VCS. In my 
opinion Trac is great at this. But if you disagree, this is entirely 
optional. You can use Trac for tickets and not connect it to a VCS at 
all if you want.

http://trac.edgewall.org/wiki/TracBrowser
http://trac.edgewall.org/wiki/TracChangeset
http://trac.edgewall.org/wiki/TracRevisionLog

Some of Trac's VCS backends support storing cached VCS data in the Trac DB.
That can require resyncing the cache when the repository changes.
The Mercurial backend does not yet support this, so resyncing is not 
required there as far as I know.

http://trac.edgewall.org/wiki/TracRepositoryAdmin#Repositorycaching
http://trac.edgewall.org/wiki/TracMercurial#Tocacheornottocache
http://trac.edgewall.org/ticket/8417

2. Optionally Trac can be configured to react to new changesets that 
contain certain keywords like "see #123" in the commit message for example.
That would add a comment to the Trac ticket #123. "fix #123" would 
additionally mark that ticket as fixed.

http://trac.edgewall.org/wiki/CommitTicketUpdater


What exactly do you mean by "reversing a commit"? hg backout, hg strip?
Trac generally does not have a concept of changing repositories, except 
for adding new changesets and resyncing cached data as described above.
So Trac would generally not react at all to "reversing a commit", except 
as described above.

It certainly would not delete a bug report.
The closest I can think of would be this scenario:
* Someone commits Mercurial changeset  which introduces a bug.
* Someone creates a Trac ticket #123 that describes this bug.
* Someone commits Mercurial changeset  by backing out the 
changes of , to fix this bug.

* The commit message of  contains "fix #123".
* Trac detecs thits and automatically closes ticket #123 and adds a 
ticket comment that references changeset . (As described 
above in point 2. this is optional, and must be enabled / configured.)


If you mean something like "hg strip" you would have to close the ticket 
manually. (And resync the cache, but as mentioned in the case of 
Mercurial there is no cache anyway.)


Is there anything else you would like Trac to do with the VCS?
There may be a plugin, for example this one allows users to add / delete 
entire Mercurial repositories in Trac:

https://trac-hacks.org/wiki/HgDirManagerPlugin
(I use this a lot. It's great for my usecase.)

Or if you have advanced / special requirements it may be possible to 
write one:

http://trac.edgewall.org/wiki/TracDev/PluginDevelopment/ExtensionPoints/trac.versioncontrol.api.IRepositoryChangeListener#Examples

Hope this helps


On 09.01.2016 13:52, xqbt wrote:

Hey guys, I am new to trac, so bear with me.
Suppose I use Mercurial as my version control system.
So, a couple of questions that are on my mind:
1) Does trac modify any of mercurial's files?
2) If I reverse a couple of commits back in Mercurial, how does trac 
react? Will a bug reported in the very new version go away (since we 
reverted to some previous state)?
3) Are there any caveats to know of when trac and Mercerial (or favourite VCS>) work together?

Thanks!
--
You received this message because you are subscribed to the Google 
Groups "Trac Users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to trac-users+unsubscr...@googlegroups.com 
.
To post to this group, send email to trac-users@googlegroups.com 
.

Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] gmail smtp Sign-in attempt prevented

[Peter Suter]

On 04.09.2015 23:24, Aaron Laws wrote:

We strongly recommend that you use a secure app, like Gmail, to access
your account. All apps made by Google meet these security standards.
Using a less secure app, on the other hand, could leave your account
vulnerable.


Is this new gmail behaviour? Did I miss something in my settings? Thanks!


Yes, it's (relatively) new gmail behavior. Apparently they want to push 
OAuth based logins, and refer to all non-OAuth apps as "less secure".


See 
http://security.stackexchange.com/questions/66025/what-are-the-dangers-of-allowing-less-secure-apps-to-access-my-google-account
and 
http://www.ghacks.net/2014/07/21/gmail-starts-block-less-secure-apps-enable-access/


--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: extend layout of /newticket

[Peter Suter]

On 07.08.2015 16:05, Mo wrote:


http://trac.edgewall.org/wiki/TracInterfaceCustomization#SiteAppearance
http://trac.edgewall.org/wiki/TracInterfaceCustomization#SiteAppearance



Sorry, I'm not versed in CSS. I created a style.css with this code in 
/htdocs in the project folder but it does not change the sizing.


Check that link again, you also need the site.html (that references the 
style.css) in the /template folder.


Hope that helps,
Peter

--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Installing docrenderplugin on Windows

[Peter Suter]

Do not update to Trac's Python to 3.x. That will definitely break things.
Or do you mean to update to 2.7.10? That might be less of a problem, but 
you might still need to recreate eggs etc. I'm not sure.


Peter

On 06.07.2015 10:51, Ita wrote:

Thanks, Peter.
I'm a little further along now. I started LibreOffice from the command 
line in the way you suggested - thanks! So simple. It's there but the 
plugin still isn't working. Looking back at the documentation I 
realised I'd forgotten about the ooextract.py script, which must be 
located on the path. I dropped in the script and it runs but can't 
import 'uno'.
'uno' seems to be a tool that allows you to interact with Libreoffice. 
Clearly, I will need it.
It looks like I'll have to update my python version before I install 
'uno' (I'm at 2.7.6). At least my version of LibreOffice seems acceptable.
If I update my python version I'm afraid I might break Trac, which 
everyone else in the office depends on. What's the conventional wisdom 
here? Should I be afraid, very afraid, or will it probably just work?

Cheers, Ita

On Saturday, 4 July 2015 06:34:15 UTC+1, Peter Suter wrote:

On 03.07.2015 11:33, Ita wrote:
 My problem came with running init-script as it's not a Windows
script.

I have not used docrenderplugin. From looking at the script it
seems you
can just start LibreOffice directly instead of using the script:

C:\Program Files (x86)\LibreOffice 4\program\soffice.exe --headless
--nologo --nofirststartwizard --nodefault
--accept=socket,host=localhost,port=8100;urp;StarOffice.ComponentContext


This starts a LibreOffice in the background. I think that should be
enough to get the plugin working.

 After peering at it for a while I decided that I could achieve
the same
 thing by running LibreOffice as a Windows Service. Unfortunately, I
 haven't been able to discover a way of doing this, even with the
help of
 Google.
 Since it looks like LibreOffice can be run as a service on Unix
I can't
 see why it wouldn't be possible on Windows, but I'm in new
territory
 here and would love some help from anyone who's done this or who
knows
 how to go about it. Maybe my approach is totally wrong and I
should be
 going about it another way?

But the above is not as a real Windows Service. If you need
that,  you
can apparently just wrap the above command in a generic Windows
Service
wrapper like srvany.exe from the Windows Server 2003 Resource Kit:


http://www.tonido.com/support/display/cloud/Running+Openoffice+as+a+service+in+Windows

http://www.tonido.com/support/display/cloud/Running+Openoffice+as+a+service+in+Windows


(This page uses OpenOffice but I assume the same also works for
LibreOffice.)

You could maybe also try nssm (instead of srvany.exe):

http://nssm.cc/

--
You received this message because you are subscribed to the Google 
Groups Trac Users group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to trac-users+unsubscr...@googlegroups.com 
mailto:trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com 
mailto:trac-users@googlegroups.com.

Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Installing docrenderplugin on Windows

[Peter Suter]

On 03.07.2015 11:33, Ita wrote:

My problem came with running init-script as it's not a Windows script.


I have not used docrenderplugin. From looking at the script it seems you 
can just start LibreOffice directly instead of using the script:


C:\Program Files (x86)\LibreOffice 4\program\soffice.exe --headless 
--nologo --nofirststartwizard --nodefault 
--accept=socket,host=localhost,port=8100;urp;StarOffice.ComponentContext


This starts a LibreOffice in the background. I think that should be 
enough to get the plugin working.



After peering at it for a while I decided that I could achieve the same
thing by running LibreOffice as a Windows Service. Unfortunately, I
haven't been able to discover a way of doing this, even with the help of
Google.
Since it looks like LibreOffice can be run as a service on Unix I can't
see why it wouldn't be possible on Windows, but I'm in new territory
here and would love some help from anyone who's done this or who knows
how to go about it. Maybe my approach is totally wrong and I should be
going about it another way?


But the above is not as a real Windows Service. If you need that,  you 
can apparently just wrap the above command in a generic Windows Service 
wrapper like srvany.exe from the Windows Server 2003 Resource Kit:


http://www.tonido.com/support/display/cloud/Running+Openoffice+as+a+service+in+Windows

(This page uses OpenOffice but I assume the same also works for 
LibreOffice.)


You could maybe also try nssm (instead of srvany.exe):

http://nssm.cc/

--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Trac 1.0.2 query to ticket_custom wrong SQL costing 15seconds vs left outer join would cost 0.05seconds

[Peter Suter]

Hello,
I'm assuming this is a ticket query. Looking at the source control 
history it looks like this changed in #11140

http://trac.edgewall.org/ticket/11140
for 12.6, 1.0.2 and 1.1.2 because MySQL and SQLite limit in the number 
of joins, and queries require too many.


If this is a common performance regression, maybe Trac could use joins 
again if there are only a few custom fields.


Just out of curiosity, can you tell us what  DB you are running? How 
many tickets are there in total? How many matching this query?


On 24.06.2015 18:11, Lukasz Szybalski wrote:

Hello,
Can you tell me why trac 1.0.2 uses select from ticket_custom instead 
of inner or left outer join?
This is a major performance hit. The query runs in 15seconds vs 
0.05second with left outer join?


How can I change that?



  SELECT t.id http://t.id AS id,t.summary AS summary,t.version AS 
version,t.status AS status,t.priority AS priority,t.component AS 
component,t.keywords AS keywords,t.time AS time,t.changetime AS 
changetime,t.milestone AS milestone,
*(SELECT c.value FROM ticket_custom c WHERE c.ticket=t.id 
http://t.id AND c.name http://c.name='contract_number') AS 
`contract_number`*

  FROM ticket AS t
  LEFT OUTER JOIN ticket_custom c2
on c2.ticket=t.id http://t.id
and c2.name http://c2.name='contract_number'
  LEFT OUTER JOIN enum AS priority ON (priority.type='priority' AND 
priority.name http://priority.name=priority)
WHERE (t.status IN ('new','reopened') AND t.version NOT IN 
('ILC','INC') AND (t.milestone='Endorsement'))




  SELECT t.id http://t.id AS id,t.summary AS summary,t.version AS 
version,t.status AS status,t.priority AS priority,t.component AS 
component,t.keywords AS keywords,t.time AS time,t.changetime AS 
changetime,t.milestone AS milestone, c2.value as contract_number

AS `contract_number`
  FROM ticket AS t
*  LEFT OUTER JOIN ticket_custom c2
on c2.ticket=t.id http://t.id
and c2.name http://c2.name='contract_number'
*  LEFT OUTER JOIN enum AS priority ON (priority.type='priority' AND 
priority.name http://priority.name=priority)
WHERE (t.status IN ('new','reopened') AND t.version NOT IN 
('ILC','INC') AND (t.milestone='Endorsement'))

--
You received this message because you are subscribed to the Google 
Groups Trac Users group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to trac-users+unsubscr...@googlegroups.com 
mailto:trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com 
mailto:trac-users@googlegroups.com.

Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] On-the-fly ticket title and content search during typing title of new ticket

[Peter Suter]

On 20.03.2015 16:25, Karl-Philipp Richter wrote:

Hi,
I'd like to know if there's function of `trac` (including official and
unofficial add-ons if such thing exists) yet to display search results
for possible duplicate tickets during typing the title of new ticket
which is about to be created by searching the titles and contents of
existing tickets with keywords of the new title which is about to be
typed (or something more sophisticated) and displaying them in a
dropdown menu (e.g. like stackoverflow.com  Co, some bugzilla instances
(e.g. bugzilla.mozilla.org) do).

I don't seem to find anything in google.com and duckduckgo.com and have
never seen a trac instance with that feature. If it doesn't exist, have
there ever been plans about such a feature.

-Kalle



Hi

Sounds like DuplicateTicketSearchPlugin.
https://trac-hacks.org/wiki/DuplicateTicketSearchPlugin

Peter

--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Subversion problem after upgrading to Trac 1.0.4

[Peter Suter]

Hi

On 20.03.2015 13:32, Peter Santner wrote:

Hi,
I have upgraded my trac from 1.0.2 to 1.0.4
After the upgrade I have the following error in my log/trac.log:
|
HTTPInternalError:500Tracerror (Unableto instantiate component 
class'tracopt.versioncontrol.svn.svn_fs.SubversionConnector'(svn_pool_create()takes 
exactly 2arguments (0given)))

|
and the Browse source component isn't available any more!

any help would be appreciate, thanks!


Searching for |svn_pool_create()takes exactly 2arguments (0given) I 
see the same discussed on the subversion list recently:

http://mail-archives.apache.org/mod_mbox/subversion-dev/201501.mbox/%3c87vbjpocet@ntlworld.com%3E

|Did you build SVN bindings yourself? Did you change SWIG version?  What 
SWIG version are you using?  Have you tried SWIG 2 instead of SWIG 3?


Hope this helps.

--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Register new user not working with AccountManager and Announcer

[Peter Suter]

On 16.03.2015 11:04, Mo wrote:

I've seen
http://trac-hacks.org/wiki/AnnouncerPlugin/PluginSupport/AccountManagerPlugin

but where do I get the plugin? Looking at the changes it seems to be 
integrated in announcerplugin/trunk 
http://trac-hacks.org/browser/announcerplugin/trunk?rev=13984, but 
how to enable?


Did you enable the components in announcer.opt.acct_mgr.announce?

http://trac-hacks.org/browser/announcerplugin/trunk/announcer/opt/acct_mgr/announce.py

--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Mapping static resources

[Peter Suter]

Hi

On 19.02.2015 17:52, Emmanuel BOUAZIZ wrote:

There are two primary URL paths for static resources - |/chrome/common|
and |/chrome/site|. Plugins can add their own resources, usually
accessible by |/chrome/plugin| path, so its important to override only
known paths and not try to make universal |/chrome| alias for everything.

* I suppose that if a plugin creates its own resource directory, it
should be mapped too. A plugin like wikiextras creates 7 of these
directories which makes a lot of aliases


Ideally, yes.



* I don't understand why its important to override only known paths and
not try to make universal |/chrome| alias for everything, unless you
suspect a rogue user could create more directories in `htdocs`


I think it just means that not necessarily all paths can be mapped the 
same way, e.g. because plugins will be installed later (but not mapped 
in htdocs), or maybe some plugins are installed globally and mapped to 
some shared path etc.


There's also /chrome/shared defined by the htdocs_dir option in the 
inherit section of the TracIni.


http://trac.edgewall.org/wiki/TracDev/TracURLs

--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] How do I rename a wiki hierarchy entry?

[Peter Suter]

On 06.11.2014 01:45, mham...@sandia.gov wrote:
I've searched the archive for old posts relating to rename, and 
checked the wiki on the edgewall site, and all seem to indicate that 
the rename capability was added in version 0.12. What am I doing 
wrong? How do I get Trac to change 'Tools' in the wiki hierarchy to 
'NewName'?
Unfortunately hierarchical renaming isn't implemented yet. The relevant 
ticket is #4412.


http://trac.edgewall.org/ticket/4412

--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] SubWiki page syntax

[Peter Suter]

On 27.08.2014 21:51, Steffen Hoffmann wrote:
Unluckily that one is modular, but not exposed for re-use by plugins, 
so we would need to copy it. 


Actually it is a bit exposed now, since it is reused in TitleIndexMacro 
[1]. (At least the requested, and IMO most useful part.)


I think it would be something like this:

if page_name and formatter.resource and 
formatter.resource.realm == 'wiki':
page_name = formatter.wiki.resolve_relative_name(page_name, 
formatter.resource.id)


Added just before retrieving the WikiPage [2].

[1] http://trac.edgewall.org/ticket/11455
[2] 
http://trac-hacks.org/browser/includemacro/trunk/includemacro/macros.py#L84


--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Problem with Git and CommitTicketUpdater (old commit message interpreted again)

[Peter Suter]

Hi,

On 13.08.2014 17:17, W. Martin Borgert wrote:

I'm using Trac with Git and the nice CommitTicketUpdater.

Problem: When a ticket is closed via a commit message in a branch,
later the ticket is re-opened, and then the branch gets merged and
pushed, the ticket gets closed again.

In theory, a commit message, that has been seen and interpreted by
Trac should not be interpreted again, when only a merge is done,
right?

Or better(?), closes/fixes should be interpreted as refs only.

Any solution for this?


What hook script are you using to call trac-admin changeset added?
I think the solution is not to send such changesets to Trac more than once.
Maybe try the one proposed here:
http://trac.edgewall.org/ticket/10730#comment:8

Cheers

--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Problem with Git and timeline filter done by

[Peter Suter]

Hi,

On 13.08.2014 17:29, W. Martin Borgert wrote:

Hi,

I have a number of users in my Trac, e.g. ab with name Abe Blue 
and email
address a...@foobar.com. The Git commits are done be Abe Blue 
a...@foobar.com

which is, of course, the same person.

When I filter for done by: ab, I do get all actions by that user in 
Trac, but

not the Git commits, nor ticket updates initiated by Git commit messages.

Neither done by: Abe Blue a...@foobar.com nor done by: Abe Blue 
filter the

Git commits, however - I don't get any results at all.

Do I have to configure something in either Git or Trac, to make the 
timeline

filter work as expected?

TIA and Cheers



Unfortunately Trac has no such mapping feature I think.
There is a ticket about this:
http://trac.edgewall.org/ticket/10640

It even has a patch attached that you could test.

Cheers

--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Problem with Git and timeline filter done by

[Peter Suter]

On 13.08.2014 19:38, Peter Suter wrote:

Hi,

On 13.08.2014 17:29, W. Martin Borgert wrote:

Hi,

I have a number of users in my Trac, e.g. ab with name Abe Blue 
and email
address a...@foobar.com. The Git commits are done be Abe Blue 
a...@foobar.com

which is, of course, the same person.

When I filter for done by: ab, I do get all actions by that user in 
Trac, but
not the Git commits, nor ticket updates initiated by Git commit 
messages.


Neither done by: Abe Blue a...@foobar.com nor done by: Abe Blue 
filter the

Git commits, however - I don't get any results at all.

Do I have to configure something in either Git or Trac, to make the 
timeline

filter work as expected?

TIA and Cheers



Unfortunately Trac has no such mapping feature I think.
There is a ticket about this:
http://trac.edgewall.org/ticket/10640

It even has a patch attached that you could test.

Cheers

Actually there is one feature already in TracGit (also mentioned in that 
ticket):

[git]
trac_user_rlookup = true

This maps Abe Blue a...@foobar.com to ab if the ab Trac user has 
set his Trac email address to a...@foobar.com.


(Apparently this is slow if you have many users)

http://trac.edgewall.org/wiki/TracIni#git-section

--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Setuptools 5.4 performance

[Peter Suter]

On 09.08.2014 15:23, Jun Omae wrote:

I think that is a setuptools issue in 5.4. It seems the issue has been
introduced in [10cc90d9b828] and [2d13c675f84c] of setuptools.

After setuptools 5.4, the zipinfo property of ZipProvider class reads
egg file each time. Before 5.3, __init__ method of ZipProvider class
reads egg file and the result will be stored in its zipinfo instance
variable.

The following patch would fix it.

--- pkg_resources.py.orig 2014-08-09 22:06:34.877375000 +0900
+++ pkg_resources.py  2014-08-09 22:06:37.533625000 +0900
@@ -1636,7 +1636,11 @@

  @property
  def zipinfo(self):
-return self._zip_manifests.load(self.loader.archive)
+try:
+return self._zipinfo
+except AttributeError:
+self._zipinfo = self._zip_manifests.load(self.loader.archive)
+return self._zipinfo

  def get_resource_filename(self, manager, resource_name):
  if not self.egg_name:



Thank you for investigating! Have you sent the patch to setuptools 
developers?


--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

[Trac] Setuptools 5.4 performance

[Peter Suter]

When I upgraded setuptools to 5.4.x, Trac became completely unresponsive 
(loading a simple page takes 30 seconds instead of less than 1).
(On Windows, Python 2.6 or 2.7, Trac trunk tracd. The problem only 
manifested itself when Trac was installed as an egg, not in setup.py 
develop mode.)


Downgrading setuptools (to 5.3 or below) fixed the problem.

[1] points to [2] and mentionsthe PKG_RESOURCES_CACHE_ZIP_MANIFESTS 
environment variable. Setting that environment variable with 5.4 also 
enables reasonable performance. Although it sounds like this enables a 
new experimental feature. So why is it required to get back performance 
similar to 5.3?


Am I missing something? (Should we report a bug? Warn users against this 
version?)


[1] https://pypi.python.org/pypi/setuptools#id3
[2] https://bitbucket.org/pypa/setuptools/issue/154

--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] field labels [Was: owner or developer]

[Peter Suter]

On 06.08.2014 07:56, Mike Dewhirst wrote:

I have not found access to trac.ini values without deliberately finding
the file and reading it. I'm sure there must be an object in ticket.api
with the necessary data or which could be persuaded to get it. If you
can help I would appreciate it. And that would let me clean it all up
and offer a patch.


Any Trac Component has the entire trac.ini Configuration available in 
self.config.


Specific options are often declared and hence available as `Option` 
attributes on some Component e.g. `TicketSystem.default_version` 
corresponds to trac.ini [ticket] default_version=...


Similarly, `TicketSystem.ticket_custom_section` corresponds to the 
entire trac.ini [ticket-custom] section.


So to allow relabelling any standard ticket field via trac.ini:
[ticket-custom]
cc.label=Stakeholders
owner.label=Developer

I had something like this patch in mind:
{{{

diff -r 47a8451d3eab trac/ticket/api.py
--- a/trac/ticket/api.pyWed Aug 06 10:46:49 2014 +
+++ b/trac/ticket/api.pyWed Aug 06 20:49:52 2014 +0200
@@ -373,6 +373,11 @@
 fields.append({'name': 'changetime', 'type': 'time',
'format': 'relative', 'label': N_('Modified')})

+for field in fields:
+key = field['name'] + '.label'
+if key in self.ticket_custom_section:
+field['label'] = self.ticket_custom_section.get(key)
+
 for field in self.custom_fields:
 if field['name'] in [f['name'] for f in fields]:
 self.log.warning('Duplicate field name %s (ignoring)',

}}}


Other issues/work of concern include:

1. Translations of new labels
2. Documentation
3. Work required in site.html  (I could offer a new site.html.sample
with the necessary items in there but commented out. Might be
independently useful anyway.)


Yes, unfortunately I now realize that this simple patch only does part 
of the job, and a general solution might have too many complications for 
translations etc.




[5]
http://trac.edgewall.org/browser/trunk/trac/ticket/api.py?version=12992marks=291-310,316-391#L291


--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: owner or developer

[Peter Suter]

Hi

On 03.08.2014 11:15, Mike Dewhirst wrote:
The next problem is a hint generated by default_workflow.py. It 
contains the dreaded words The owner will be changed in four places 
and in each and is added the userid(s) of the owner(s) concerned.


I have had a look at XPath and there is py:replace but it wants to 
replace an entire string. It doesn't seem to permit what I want.


Maybe I should write a tool to patch the source so at least I can run 
it each time I update trac.


Is there another way?


One other solution that was previously proposed for similar problems is 
creating a custom translation.

I don't know how much work that is though.

[1] Rename ticket to incident: 
http://thread.gmane.org/gmane.comp.version-control.subversion.trac.general/21378/focus=21406
[2] Renaming severity: 
http://thread.gmane.org/gmane.comp.version-control.subversion.trac.general/32856/focus=32901

[3] http://trac.edgewall.org/wiki/TracL10N

--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: owner or developer

[Peter Suter]

On 04.08.2014 00:53, Mike Dewhirst wrote:

I'll look at forking Trac for a while with a view to parameterising so
the owner can be replaced with developer in trac.ini

It seems my problem isn't unique so it might be useful in the longer
term (no pun intended).


Similar existing features are relabelling the navigation menu[1][2]:

[mainnav]
wiki.label = Home

And labelling the custom ticket fields[3][4]:

[ticket-custom]
relnotes = textarea
relnotes.label = Release notes

Also the labels for standard ticket fields are already nicely 
centralized in TicketSystem.fields / get_ticket_field_labels() [5].
So if you can nicely extend that to a similar simple reconfiguration of 
all standard ticket fields, I could imagine that such a patch would be 
gladly accepted.


[1] http://trac.edgewall.org/wiki/TracNavigation
[2] 
http://trac.edgewall.org/browser/trunk/trac/web/chrome.py?version=12992marks=737#L730

[3] http://trac.edgewall.org/wiki/TracTicketsCustomFields
[4] 
http://trac.edgewall.org/browser/trunk/trac/ticket/api.py?version=12992marks=412#L400
[5] 
http://trac.edgewall.org/browser/trunk/trac/ticket/api.py?version=12992marks=291-310,316-391#L291


--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Read only ticket according to custom resolution type

[Peter Suter]

Hi

On 30.07.2014 16:14, Jared Bownds wrote:

Thanks for your help so far.  I now have the plugin loading, however
even users with TICKET_VIEW permissions are now unable to view tickets
resolved as Signed.  Any idea why this may be happening?


Probably because you switched the allowed action from
action == 'TICKET_VIEW'
to
action == 'TICKET_APPEND'

If you want to allow both, you could instead try e.g.
action in ['TICKET_VIEW', 'TICKET_APPEND']

--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Read only ticket according to custom resolution type

[Peter Suter]

On 28.07.2014 08:55, RjOllos wrote:

I'm encountering the dreaded issue: RuntimeError: maximum recursion
depth exceeded while calling a Python object

The issue seems to be with the check: 'TRAC_ADMIN' in perm.


Oops, right. I think adding `action == 'TRAC_ADMIN'` to the check 
(before the `'TRAC_ADMIN' in perm` recursion) should be both sufficient 
to stop the recursion and correct in the non-recursive case:


{{{
from trac.core import *
from trac.perm import IPermissionPolicy
from trac.ticket.model import Ticket

class ReadonlySignedTickets(Component):
implements(IPermissionPolicy)

def check_permission(self, action, username, resource, perm):
if resource is None or resource.realm != 'ticket' or \
   resource.id is None or action == 'TICKET_VIEW' or \
   action == 'TRAC_ADMIN' or 'TRAC_ADMIN' in perm:
return None

t = Ticket(self.env, resource.id)
return False
}}}




I tried reworking the conditional checks in various ways, such as making
it look as close as possible to SecurityTicketsPolicy:
http://trac.edgewall.org/browser/trunk/sample-plugins/permissions/vulnerability_tickets.py

Btw, in vulnerable_tickets.py, should the check be changed?:
if 'VULNERABILITY_VIEW' not in perm:
-

if 'VULNERABILITY_VIEW' not in perm(resource):


Hm, subtle.

Usually in IPermissionPolicy `perm` should already be specific to the 
checked resource, so `perm` is the same as `perm(resource)`.


But in SecurityTicketsPolicy resource might be changed to the parent 
resource (i.e. the ticket) if it was initially a child resource (e.g. an 
attachment). So here changing `perm` to `perm(resource)` would change 
the logic: Instead of the current behaviour where VULNERABILITY_VIEW is 
required on the child resource (attachment), it would be required on the 
parent resource (ticket).


I guess for attachments (assuming the usual LegacyDelegate is used to 
forward the check to the parent anyway) it makes no difference.


To me it sounds slightly better the way it is (require 
VULNERABILITY_VIEW on the child resource), but I've not used 
fine-grained permissions much.


Or am I on the wrong track? :)

--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Read only ticket according to custom resolution type

[Peter Suter]

Oops, and now I dropped the `if t['resolution'] == 'Signed':` test by 
mistake..


{{{
from trac.core import *
from trac.perm import IPermissionPolicy
from trac.ticket.model import Ticket

class ReadonlySignedTickets(Component):
 implements(IPermissionPolicy)

 def check_permission(self, action, username, resource, perm):
 if resource is None or resource.realm != 'ticket' or \
resource.id is None or action == 'TICKET_VIEW' or \
action == 'TRAC_ADMIN' or 'TRAC_ADMIN' in perm:
 return None

 t = Ticket(self.env, resource.id)
 if t['resolution'] == 'Signed':
return False
}}}

--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Read only ticket according to custom resolution type

[Peter Suter]

Hi

On 27.07.2014 01:33, Jared Bownds wrote:

  * Once a ticket is resolved as 'Signed', the ticket is now read only
except to TRAC_ADMIN


Custom code for that part might look something like this:

{{{
from trac.core import *
from trac.perm import IPermissionPolicy
from trac.ticket.model import Ticket

class ReadonlySignedTickets(Component):
implements(IPermissionPolicy)

def check_permission(self, action, username, resource, perm):
if resource is None or resource.realm != 'ticket' or \
   resource.id is None or action == 'TICKET_VIEW' or \
   'TRAC_ADMIN' in perm:
return None

t = Ticket(self.env, resource.id)
if t['resolution'] == 'Signed':
return False
}}}


See 
http://trac.edgewall.org/wiki/TracDev/PluginDevelopment/ExtensionPoints/trac.perm.IPermissionPolicy


--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Read only ticket according to custom resolution type

[Peter Suter]

On 28.07.2014 01:01, Jared Bownds wrote:

Thanks for the feedback, i'm now confident ReadonlySignedTickets.py is
enabled as a plugin.

I've run a few tests on the code below.  I created a user called temp1
that does not have TRAC_ADMIN privileges.  Also, I created a request
(#1968) and resolved it as signed.  While the permissions feedback
provided by the trac log indicates the user does not have the necessary
permissions to comment on the ticket, I am still able to modify the
request as user temp1.  I would appreciate feedback on
ReadonlySignedTickets.py to try and identify why the desired behavior is
not functioning.


Permission policy plugins also need to be listed in the trac.ini config 
file under [trac] permission_policies. For example if you previously 
only had the current default policies, add ReadonlySignedTickets to the 
front of the list:


[trac]
permission_policies = ReadonlySignedTickets, ReadonlyWikiPolicy, 
DefaultPermissionPolicy, LegacyAttachmentPolicy


(Note that the order can be important!)

Hope this helps.

[1] 
http://trac.edgewall.org/wiki/TracDev/PluginDevelopment/ExtensionPoints/trac.perm.IPermissionPolicy#Usage
[2] 
http://trac.edgewall.org/wiki/TracFineGrainedPermissions#PermissionPolicies


--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Feature-Request: Link milestone and version

[Peter Suter]

Hi

On 11.06.2014 10:12, Riedel, Torge wrote:

in our company we use milestones to plan our versions. After all tickets
of a version are fixed, the milestone is closed and the version is
released by creating a new version in the trac-admin-panel.

1.

What we like to have is an option when closing a milestone, that you can
select a check-box Create version. This creates a  version with the
same name like the milestone (maybe it's modifyable) and the closing
date/time of the milestone will be the date/time of the version.



There's a tiny plugin at:
http://trac.edgewall.org/browser/trunk/sample-plugins/milestone_to_version.py

It automatically creates a version when closing a milestone, if that 
milestone's name contains a number (and matches a configurable pattern). 
It also sets the versions date/time to the closing date/time of the 
milestone.


There's no checkbox so it's not _exactly_ what you want, but it comes 
fairly close it seems.



One extension that should be quite simple would be to automatically 
append some wiki text (including links, queries etc.)  to the 
milestone/version description texts or to some wiki page.



Best regards,
Peter

--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] 900K tickets - move to next ticket in queue when I do resolved as fixed?

[Peter Suter]

Hello

On 27.03.2014 14:53, Lukasz Szybalski wrote:

*Plugin 1. When you resolve the ticket as fixed or invalid...etc, trac
will take me to next ticket in queue.


I don't know about existing plugins. Possibly a custom 
ITicketActionController [1][2] could help. But writing a custom action 
controller is not trivial. Check [3] maybe.


I think this code would redirect you to the next ticket:

links = req.chrome.get('links', {})
current = req.href.ticket(ticket.id)
next = links['next']['href'] if 'next' in links else current
req.redirect(next)

You could maybe execute this code in apply_action_side_effects() of a 
custom controller after it behaves like the default set_resolution 
action otherwise.




Plugin 2. When ticket is closed, I would like to copy data to another
system, are there examples on how at resolved as fixed status, I can
call some function or code, that I can modify to my needs?


That could maybe be done similar to plugin 1 above. Or maybe a 
ITickerChangeListener [4] would be simpler here:


...
def ticket_changed(self, ticket, comment, author, old_values):
if old_values['status'] != 'closed' and ticket['status'] == 
'closed' and ticket['resolution'] == 'fixed':

call_your_function()
...



Plugin 3: Are there any plugins where when I query tickets for owner:me
it will display attachments in the query section,,I'm most interested if
there is a readable preview of every attachment, that I can browse by
either moving the cursor or arrow down. This would help search for
item that I'm looking for.


I don't know about plugins or the query section, but I have used some 
reports [5] for similar problems. Here are two variations of reports 
that should list all attachments of the current user's open tickets:


SELECT t.id as id,
   t.summary as summary,
   group_concat(a.description,, ) as file descriptions,
   group_concat(a.filename,, ) as files
FROM attachment a
INNER JOIN ticket t
ON a.id == t.id
WHERE a.type==ticket AND t.owner = $USER AND t.status IN ('new', 
'assigned', 'reopened')

GROUP BY t.id


SELECT a.filename AS id, attachment AS _realm,
   ticket AS _parent_realm, t.id AS _parent_id,
   a.description as description,
   a.size as size,
   # || t.id ||   || t.summary as  __group__,
   '../ticket/' || t.id as __grouplink__
FROM attachment a
INNER JOIN ticket t
ON a.id == t.id
WHERE a.type==ticket AND t.owner = $USER AND t.status IN ('new', 
'assigned', 'reopened')



[1] 
http://www.edgewall.org/docs/trac-trunk/epydoc/trac.ticket.api.ITicketActionController-class.html

[2] http://trac.edgewall.org/browser/trunk/sample-plugins/workflow
[3] http://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin
[4] 
http://www.edgewall.org/docs/trac-trunk/epydoc/trac.ticket.api.ITicketChangeListener-class.html

[5] http://trac.edgewall.org/wiki/TracReports

--
Peter

--
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.