[Trac] Re: Trac[web_ui] ERROR: Failure sending notification on change to ticket AttributeError: 'TicketNotifyEmail' object has no attribute 'db'

2016-02-01 Thread RjOllos 


On Monday, February 1, 2016 at 9:16:02 AM UTC-8, Avijit Pathania wrote:
>
> Looking for some help troubleshooting this error message. Even with debug 
> enabled, this is the only message being printed in the logs.
>
> We upgraded from 0.12 to 1.0.9. This message is seen when making 
> updates/closing a ticket. There are no traceback's.
> Tickets are created via email2trac and web frontend. There are no entries 
> in the maillog to show connections being made on ticket creation. 
>
> There are two issues that are probably related:
> 1. Trac not sending any emails when ticket gets created
> 2. The error message - Trac[web_ui] ERROR: Failure sending notification on 
> change to ticket #: AttributeError: 'TicketNotifyEmail' object has no 
> attribute 'db'
>

In Trac 1.0.9 the TicketNotifyEmail class doesn't utilize a db attribute.

http://trac.edgewall.org/browser/tags/trac-1.0.9/trac/ticket/notification.py#L147

A possibility is that a plugin is monkey-patching Trac to replace the 
TicketNotifyEmail class, but I don't see any issues with the plugins you 
are using. Despite that, I suggest disabling all plugins and verifying that 
you can reproduce the issue without plugins.

In Trac 0.12 the TicketNotifyEmail class utilized the db attribute:
http://trac.edgewall.org/browser/tags/trac-0.12/trac/ticket/notification.py?marks=96#L55

It's possible that you have a bad installation and the TicketNotifyEmail 
class from Trac 0.12 is still being called. Did you upgrade in-place, i.e. 
without doing a full reinstall or moving to a new server?

I suggest removing all traces of Trac from the system site-packages 
directory, and reinstalling Trac. If you are using a virtual environment, I 
suggest deleting and virtualenv and reinstalling all packages. If you 
aren't using a virtualenv, you might consider creating a virtualenv for 
your installation. As long as you use --no-site-packages option when 
creating the new virtualenv, you don't need to worry about removing the 
packages installed in your system site packages directory. In recent 
versions of the virtualenv package you don't need to worry about using 
--no-site-packages, but if you are unsure just specify the option.

  --no-site-packagesDEPRECATED. Retained only for backward 
compatibility.

Not having access to global site-packages is now the

default behavior.

If you are running with a webserver, make sure to redeploy static assets 
and restart the web server. See TracUpgrade for more information:
http://trac.edgewall.org/wiki/TracUpgrade

- 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.

Re: [Trac] Re: Trac[web_ui] ERROR: Failure sending notification on change to ticket AttributeError: 'TicketNotifyEmail' object has no attribute 'db'

2016-02-01 Thread Ryan Ollos 
On Mon, Feb 1, 2016 at 11:37 AM, Avijit Pathania 
wrote:

>
>
> On Monday, February 1, 2016 at 2:06:06 PM UTC-5, RjOllos wrote:
>>
>>
>>
>> On Monday, February 1, 2016 at 9:16:02 AM UTC-8, Avijit Pathania wrote:
>>>
>>> Looking for some help troubleshooting this error message. Even with
>>> debug enabled, this is the only message being printed in the logs.
>>>
>>> We upgraded from 0.12 to 1.0.9. This message is seen when making
>>> updates/closing a ticket. There are no traceback's.
>>> Tickets are created via email2trac and web frontend. There are no
>>> entries in the maillog to show connections being made on ticket creation.
>>>
>>> There are two issues that are probably related:
>>> 1. Trac not sending any emails when ticket gets created
>>> 2. The error message - Trac[web_ui] ERROR: Failure sending notification
>>> on change to ticket #: AttributeError: 'TicketNotifyEmail' object has
>>> no attribute 'db'
>>>
>>
>> In Trac 1.0.9 the TicketNotifyEmail class doesn't utilize a db attribute.
>>
>>
>> http://trac.edgewall.org/browser/tags/trac-1.0.9/trac/ticket/notification.py#L147
>>
>> A possibility is that a plugin is monkey-patching Trac to replace the
>> TicketNotifyEmail class, but I don't see any issues with the plugins you
>> are using. Despite that, I suggest disabling all plugins and verifying that
>> you can reproduce the issue without plugins.
>>
>> In Trac 0.12 the TicketNotifyEmail class utilized the db attribute:
>>
>> http://trac.edgewall.org/browser/tags/trac-0.12/trac/ticket/notification.py?marks=96#L55
>>
>> It's possible that you have a bad installation and the TicketNotifyEmail
>> class from Trac 0.12 is still being called. Did you upgrade in-place, i.e.
>> without doing a full reinstall or moving to a new server?
>>
>> I suggest removing all traces of Trac from the system site-packages
>> directory, and reinstalling Trac. If you are using a virtual environment, I
>> suggest deleting and virtualenv and reinstalling all packages. If you
>> aren't using a virtualenv, you might consider creating a virtualenv for
>> your installation. As long as you use --no-site-packages option when
>> creating the new virtualenv, you don't need to worry about removing the
>> packages installed in your system site packages directory. In recent
>> versions of the virtualenv package you don't need to worry about using
>> --no-site-packages, but if you are unsure just specify the option.
>>
>>   --no-site-packagesDEPRECATED. Retained only for backward
>> compatibility.
>>
>> Not having access to global site-packages is now
>> the
>>
>> default behavior.
>>
>> If you are running with a webserver, make sure to redeploy static assets
>> and restart the web server. See TracUpgrade for more information:
>> http://trac.edgewall.org/wiki/TracUpgrade
>>
>> - Ryan
>>
>>
>>
>> It was a fresh upgrade on a new server. The mysql database was upgraded
> by doing trac-admin upgrade, then wiki upgrade, and then finally the deploy
> step.
>
> Will remove the Trac file from site-packages folder and reinstall. Also,
> not sure if it matters, but it was installed from source.
> The mysql database is all that was carried over from the old installation.
>

In that case I wouldn't bother with the uninstall/reinstall.

Hopefully the Trac environment was carried over as well. Is it possible
that your Python egg cache was copied over in the Environment directory?

-- 
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[web_ui] ERROR: Failure sending notification on change to ticket AttributeError: 'TicketNotifyEmail' object has no attribute 'db'

2016-02-01 Thread Avijit Pathania 


On Monday, February 1, 2016 at 3:19:09 PM UTC-5, RjOllos wrote:
>
>
>
> On Monday, February 1, 2016 at 12:12:53 PM UTC-8, Avijit Pathania wrote:
>>
>>
>>
>> On Monday, February 1, 2016 at 2:40:51 PM UTC-5, RjOllos wrote:
>>>
>>>
>>>
>>> On Mon, Feb 1, 2016 at 11:37 AM, Avijit Pathania  
>>> wrote:
>>>


 On Monday, February 1, 2016 at 2:06:06 PM UTC-5, RjOllos wrote:
>
>
>
> On Monday, February 1, 2016 at 9:16:02 AM UTC-8, Avijit Pathania wrote:
>>
>> Looking for some help troubleshooting this error message. Even with 
>> debug enabled, this is the only message being printed in the logs.
>>
>> We upgraded from 0.12 to 1.0.9. This message is seen when making 
>> updates/closing a ticket. There are no traceback's.
>> Tickets are created via email2trac and web frontend. There are no 
>> entries in the maillog to show connections being made on ticket 
>> creation. 
>>
>> There are two issues that are probably related:
>> 1. Trac not sending any emails when ticket gets created
>> 2. The error message - Trac[web_ui] ERROR: Failure sending 
>> notification on change to ticket #: AttributeError: 
>> 'TicketNotifyEmail' 
>> object has no attribute 'db'
>>
>
> In Trac 1.0.9 the TicketNotifyEmail class doesn't utilize a db 
> attribute.
>
>
> http://trac.edgewall.org/browser/tags/trac-1.0.9/trac/ticket/notification.py#L147
>
> A possibility is that a plugin is monkey-patching Trac to replace the 
> TicketNotifyEmail class, but I don't see any issues with the plugins you 
> are using. Despite that, I suggest disabling all plugins and verifying 
> that 
> you can reproduce the issue without plugins.
>
> In Trac 0.12 the TicketNotifyEmail class utilized the db attribute:
>
> http://trac.edgewall.org/browser/tags/trac-0.12/trac/ticket/notification.py?marks=96#L55
>
> It's possible that you have a bad installation and the 
> TicketNotifyEmail class from Trac 0.12 is still being called. Did you 
> upgrade in-place, i.e. without doing a full reinstall or moving to a new 
> server?
>
> I suggest removing all traces of Trac from the system site-packages 
> directory, and reinstalling Trac. If you are using a virtual environment, 
> I 
> suggest deleting and virtualenv and reinstalling all packages. If you 
> aren't using a virtualenv, you might consider creating a virtualenv for 
> your installation. As long as you use --no-site-packages option when 
> creating the new virtualenv, you don't need to worry about removing the 
> packages installed in your system site packages directory. In recent 
> versions of the virtualenv package you don't need to worry about using 
> --no-site-packages, but if you are unsure just specify the option.
>
>   --no-site-packagesDEPRECATED. Retained only for backward 
> compatibility.
>
> Not having access to global site-packages is 
> now the
>
> default behavior.
>
> If you are running with a webserver, make sure to redeploy static 
> assets and restart the web server. See TracUpgrade for more information:
> http://trac.edgewall.org/wiki/TracUpgrade
>
> - Ryan
>
>
>
> It was a fresh upgrade on a new server. The mysql database was 
 upgraded by doing trac-admin upgrade, then wiki upgrade, and then finally 
 the deploy step.

 Will remove the Trac file from site-packages folder and reinstall. 
 Also, not sure if it matters, but it was installed from source.
 The mysql database is all that was carried over from the old 
 installation.

>>>
>>> In that case I wouldn't bother with the uninstall/reinstall.
>>>
>>> Hopefully the Trac environment was carried over as well. Is it possible 
>>> that your Python egg cache was copied over in the Environment directory?
>>>
>>>
>>>
>> Yes to the trac environment getting migrated. In the plugins folder 
>> within the environment there is script that makes references to 
>> self.db.cursor function. And this seems to be the root cause. 
>>  
>> Here is the snippet of code for reference:
>> from trac.ticket.api import ITicketActionController, TicketSystem
>> from trac.ticket.default_workflow import ConfigurableTicketWorkflow
>> import trac.ticket.notification as note
>>
>> def notify(self, ticket, newticket=True, modtime=None):
>> cursor = self.db.cursor()
>> #self.env.log.critical(ticket.id)
>>
>> Seems I inherited an undocumented feature at our installation.
>>
>> Appreciate you looking into this issue for me. Hopefully I should be all 
>> set by updating this code.
>>
>> Thanks
>> Avi
>>
>
> Good find. That wasn't obvious from the [components] section of your 
> trac.ini because Components in the environment "plugins" directory are 
> enabled unless

Re: [Trac] Re: Trac[web_ui] ERROR: Failure sending notification on change to ticket AttributeError: 'TicketNotifyEmail' object has no attribute 'db'

2016-02-01 Thread RjOllos 


On Monday, February 1, 2016 at 12:12:53 PM UTC-8, Avijit Pathania wrote:
>
>
>
> On Monday, February 1, 2016 at 2:40:51 PM UTC-5, RjOllos wrote:
>>
>>
>>
>> On Mon, Feb 1, 2016 at 11:37 AM, Avijit Pathania  
>> wrote:
>>
>>>
>>>
>>> On Monday, February 1, 2016 at 2:06:06 PM UTC-5, RjOllos wrote:



 On Monday, February 1, 2016 at 9:16:02 AM UTC-8, Avijit Pathania wrote:
>
> Looking for some help troubleshooting this error message. Even with 
> debug enabled, this is the only message being printed in the logs.
>
> We upgraded from 0.12 to 1.0.9. This message is seen when making 
> updates/closing a ticket. There are no traceback's.
> Tickets are created via email2trac and web frontend. There are no 
> entries in the maillog to show connections being made on ticket creation. 
>
> There are two issues that are probably related:
> 1. Trac not sending any emails when ticket gets created
> 2. The error message - Trac[web_ui] ERROR: Failure sending 
> notification on change to ticket #: AttributeError: 
> 'TicketNotifyEmail' 
> object has no attribute 'db'
>

 In Trac 1.0.9 the TicketNotifyEmail class doesn't utilize a db 
 attribute.


 http://trac.edgewall.org/browser/tags/trac-1.0.9/trac/ticket/notification.py#L147

 A possibility is that a plugin is monkey-patching Trac to replace the 
 TicketNotifyEmail class, but I don't see any issues with the plugins you 
 are using. Despite that, I suggest disabling all plugins and verifying 
 that 
 you can reproduce the issue without plugins.

 In Trac 0.12 the TicketNotifyEmail class utilized the db attribute:

 http://trac.edgewall.org/browser/tags/trac-0.12/trac/ticket/notification.py?marks=96#L55

 It's possible that you have a bad installation and the 
 TicketNotifyEmail class from Trac 0.12 is still being called. Did you 
 upgrade in-place, i.e. without doing a full reinstall or moving to a new 
 server?

 I suggest removing all traces of Trac from the system site-packages 
 directory, and reinstalling Trac. If you are using a virtual environment, 
 I 
 suggest deleting and virtualenv and reinstalling all packages. If you 
 aren't using a virtualenv, you might consider creating a virtualenv for 
 your installation. As long as you use --no-site-packages option when 
 creating the new virtualenv, you don't need to worry about removing the 
 packages installed in your system site packages directory. In recent 
 versions of the virtualenv package you don't need to worry about using 
 --no-site-packages, but if you are unsure just specify the option.

   --no-site-packagesDEPRECATED. Retained only for backward 
 compatibility.

 Not having access to global site-packages is 
 now the

 default behavior.

 If you are running with a webserver, make sure to redeploy static 
 assets and restart the web server. See TracUpgrade for more information:
 http://trac.edgewall.org/wiki/TracUpgrade

 - Ryan



 It was a fresh upgrade on a new server. The mysql database was upgraded 
>>> by doing trac-admin upgrade, then wiki upgrade, and then finally the deploy 
>>> step.
>>>
>>> Will remove the Trac file from site-packages folder and reinstall. Also, 
>>> not sure if it matters, but it was installed from source.
>>> The mysql database is all that was carried over from the old 
>>> installation.
>>>
>>
>> In that case I wouldn't bother with the uninstall/reinstall.
>>
>> Hopefully the Trac environment was carried over as well. Is it possible 
>> that your Python egg cache was copied over in the Environment directory?
>>
>>
>>
> Yes to the trac environment getting migrated. In the plugins folder within 
> the environment there is script that makes references to self.db.cursor 
> function. And this seems to be the root cause. 
>  
> Here is the snippet of code for reference:
> from trac.ticket.api import ITicketActionController, TicketSystem
> from trac.ticket.default_workflow import ConfigurableTicketWorkflow
> import trac.ticket.notification as note
>
> def notify(self, ticket, newticket=True, modtime=None):
> cursor = self.db.cursor()
> #self.env.log.critical(ticket.id)
>
> Seems I inherited an undocumented feature at our installation.
>
> Appreciate you looking into this issue for me. Hopefully I should be all 
> set by updating this code.
>
> Thanks
> Avi
>

Good find. That wasn't obvious from the [components] section of your 
trac.ini because Components in the environment "plugins" directory are 
enabled unless explicitly disabled in the [components] section. This is the 
opposite of plugin in your site-packages directory, which are disabled 
unless explicitly enabled in the [components] section of trac.ini. I've

Re: [Trac] Re: Trac[web_ui] ERROR: Failure sending notification on change to ticket AttributeError: 'TicketNotifyEmail' object has no attribute 'db'

2016-02-01 Thread Avijit Pathania 


On Monday, February 1, 2016 at 2:40:51 PM UTC-5, RjOllos wrote:
>
>
>
> On Mon, Feb 1, 2016 at 11:37 AM, Avijit Pathania  > wrote:
>
>>
>>
>> On Monday, February 1, 2016 at 2:06:06 PM UTC-5, RjOllos wrote:
>>>
>>>
>>>
>>> On Monday, February 1, 2016 at 9:16:02 AM UTC-8, Avijit Pathania wrote:

 Looking for some help troubleshooting this error message. Even with 
 debug enabled, this is the only message being printed in the logs.

 We upgraded from 0.12 to 1.0.9. This message is seen when making 
 updates/closing a ticket. There are no traceback's.
 Tickets are created via email2trac and web frontend. There are no 
 entries in the maillog to show connections being made on ticket creation. 

 There are two issues that are probably related:
 1. Trac not sending any emails when ticket gets created
 2. The error message - Trac[web_ui] ERROR: Failure sending notification 
 on change to ticket #: AttributeError: 'TicketNotifyEmail' object has 
 no attribute 'db'

>>>
>>> In Trac 1.0.9 the TicketNotifyEmail class doesn't utilize a db attribute.
>>>
>>>
>>> http://trac.edgewall.org/browser/tags/trac-1.0.9/trac/ticket/notification.py#L147
>>>
>>> A possibility is that a plugin is monkey-patching Trac to replace the 
>>> TicketNotifyEmail class, but I don't see any issues with the plugins you 
>>> are using. Despite that, I suggest disabling all plugins and verifying that 
>>> you can reproduce the issue without plugins.
>>>
>>> In Trac 0.12 the TicketNotifyEmail class utilized the db attribute:
>>>
>>> http://trac.edgewall.org/browser/tags/trac-0.12/trac/ticket/notification.py?marks=96#L55
>>>
>>> It's possible that you have a bad installation and the TicketNotifyEmail 
>>> class from Trac 0.12 is still being called. Did you upgrade in-place, i.e. 
>>> without doing a full reinstall or moving to a new server?
>>>
>>> I suggest removing all traces of Trac from the system site-packages 
>>> directory, and reinstalling Trac. If you are using a virtual environment, I 
>>> suggest deleting and virtualenv and reinstalling all packages. If you 
>>> aren't using a virtualenv, you might consider creating a virtualenv for 
>>> your installation. As long as you use --no-site-packages option when 
>>> creating the new virtualenv, you don't need to worry about removing the 
>>> packages installed in your system site packages directory. In recent 
>>> versions of the virtualenv package you don't need to worry about using 
>>> --no-site-packages, but if you are unsure just specify the option.
>>>
>>>   --no-site-packagesDEPRECATED. Retained only for backward 
>>> compatibility.
>>>
>>> Not having access to global site-packages is now 
>>> the
>>>
>>> default behavior.
>>>
>>> If you are running with a webserver, make sure to redeploy static assets 
>>> and restart the web server. See TracUpgrade for more information:
>>> http://trac.edgewall.org/wiki/TracUpgrade
>>>
>>> - Ryan
>>>
>>>
>>>
>>> It was a fresh upgrade on a new server. The mysql database was upgraded 
>> by doing trac-admin upgrade, then wiki upgrade, and then finally the deploy 
>> step.
>>
>> Will remove the Trac file from site-packages folder and reinstall. Also, 
>> not sure if it matters, but it was installed from source.
>> The mysql database is all that was carried over from the old installation.
>>
>
> In that case I wouldn't bother with the uninstall/reinstall.
>
> Hopefully the Trac environment was carried over as well. Is it possible 
> that your Python egg cache was copied over in the Environment directory?
>
>
>
Yes to the trac environment getting migrated. In the plugins folder within 
the environment there is script that makes references to self.db.cursor 
function. And this seems to be the root cause. 
 
Here is the snippet of code for reference:
from trac.ticket.api import ITicketActionController, TicketSystem
from trac.ticket.default_workflow import ConfigurableTicketWorkflow
import trac.ticket.notification as note

def notify(self, ticket, newticket=True, modtime=None):
cursor = self.db.cursor()
#self.env.log.critical(ticket.id)

Seems I inherited an undocumented feature at our installation.

Appreciate you looking into this issue for me. Hopefully I should be all 
set by updating this code.

Thanks
Avi

-- 
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: Trac[web_ui] ERROR: Failure sending notification on change to ticket AttributeError: 'TicketNotifyEmail' object has no attribute 'db'

2016-02-01 Thread Avijit Pathania 


On Monday, February 1, 2016 at 2:06:06 PM UTC-5, RjOllos wrote:
>
>
>
> On Monday, February 1, 2016 at 9:16:02 AM UTC-8, Avijit Pathania wrote:
>>
>> Looking for some help troubleshooting this error message. Even with debug 
>> enabled, this is the only message being printed in the logs.
>>
>> We upgraded from 0.12 to 1.0.9. This message is seen when making 
>> updates/closing a ticket. There are no traceback's.
>> Tickets are created via email2trac and web frontend. There are no entries 
>> in the maillog to show connections being made on ticket creation. 
>>
>> There are two issues that are probably related:
>> 1. Trac not sending any emails when ticket gets created
>> 2. The error message - Trac[web_ui] ERROR: Failure sending notification 
>> on change to ticket #: AttributeError: 'TicketNotifyEmail' object has 
>> no attribute 'db'
>>
>
> In Trac 1.0.9 the TicketNotifyEmail class doesn't utilize a db attribute.
>
>
> http://trac.edgewall.org/browser/tags/trac-1.0.9/trac/ticket/notification.py#L147
>
> A possibility is that a plugin is monkey-patching Trac to replace the 
> TicketNotifyEmail class, but I don't see any issues with the plugins you 
> are using. Despite that, I suggest disabling all plugins and verifying that 
> you can reproduce the issue without plugins.
>
> In Trac 0.12 the TicketNotifyEmail class utilized the db attribute:
>
> http://trac.edgewall.org/browser/tags/trac-0.12/trac/ticket/notification.py?marks=96#L55
>
> It's possible that you have a bad installation and the TicketNotifyEmail 
> class from Trac 0.12 is still being called. Did you upgrade in-place, i.e. 
> without doing a full reinstall or moving to a new server?
>
> I suggest removing all traces of Trac from the system site-packages 
> directory, and reinstalling Trac. If you are using a virtual environment, I 
> suggest deleting and virtualenv and reinstalling all packages. If you 
> aren't using a virtualenv, you might consider creating a virtualenv for 
> your installation. As long as you use --no-site-packages option when 
> creating the new virtualenv, you don't need to worry about removing the 
> packages installed in your system site packages directory. In recent 
> versions of the virtualenv package you don't need to worry about using 
> --no-site-packages, but if you are unsure just specify the option.
>
>   --no-site-packagesDEPRECATED. Retained only for backward 
> compatibility.
>
> Not having access to global site-packages is now 
> the
>
> default behavior.
>
> If you are running with a webserver, make sure to redeploy static assets 
> and restart the web server. See TracUpgrade for more information:
> http://trac.edgewall.org/wiki/TracUpgrade
>
> - Ryan
>
>
>
> It was a fresh upgrade on a new server. The mysql database was upgraded by 
doing trac-admin upgrade, then wiki upgrade, and then finally the deploy 
step.

Will remove the Trac file from site-packages folder and reinstall. Also, 
not sure if it matters, but it was installed from source.
The mysql database is all that was carried over from the old installation.

Avi

-- 
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[web_ui] ERROR: Failure sending notification on change to ticket AttributeError: 'TicketNotifyEmail' object has no attribute 'db'

2016-02-01 Thread RjOllos 


On Monday, February 1, 2016 at 12:29:28 PM UTC-8, Avijit Pathania wrote:
>
>
>
> On Monday, February 1, 2016 at 3:19:09 PM UTC-5, RjOllos wrote:
>>
>>
>> Good find. That wasn't obvious from the [components] section of your 
>> trac.ini because Components in the environment "plugins" directory are 
>> enabled unless explicitly disabled in the [components] section. This is the 
>> opposite of plugin in your site-packages directory, which are disabled 
>> unless explicitly enabled in the [components] section of trac.ini. I've 
>> considered the behavior to be confusing and thought about suggesting a 
>> change.
>>
>> Is that the entire plugin, or just a snippet of the plugin code? If 
>> that's the entire plugin, then it does nothing and you can just remove it. 
>> If there's more code, I'd need to see the entire plugin to suggest 
>> modifications, but in short you need to adapt to the new database API. An 
>> outline of database API changes can be found here:
>> http://trac.edgewall.org/wiki/TracDev/DatabaseApi#Trac1.0API
>>
>
>  That was a snippet. Here is the entire code with my edits for version 
> 1.0. Have not had a chance to test it though.
> from trac.ticket.api import ITicketActionController, TicketSystem
> from trac.ticket.default_workflow import ConfigurableTicketWorkflow
> from trac.env import Environment
> import trac.ticket.notification as note
>
> def notify(self, ticket, newticket=True, modtime=None):
>   env = Environment('/mnt/trac/it') <---
>   with env.db_query as db:   <---
> cursor = db.cursor() <---
> #self.env.log.critical(ticket.id)
> cursor.execute("SELECT cc,reporter,owner,status FROM ticket WHERE 
> id=%s", (t
> icket.id))
> row = cursor.fetchone()
> if row:
> self.reporter = row[1]
> self.owner = row[2]
> self.status = row[3]
>
> if (self.status == 'new'):
> #self.env.log.critical("sending email")
> self._notify(ticket, newticket, modtime)
> #else:
> #self.env.log.critical("not sending email")
>
> note.TicketNotifyEmail.notify = notify
>

Makes sense now, the single-file plugin is monkey-patching the notification 
module. Looks like you only want the notifications sent when ticket status 
is "new". You can drastically simplify your plugin. Here are untested 
changes:

def notify(self, ticket, newticket=True, modtime=None):
if ticket['status'] == 'new':
self._notify(ticket, newticket, modtime)

note.TicketNotifyEmail.notify = notify


At the very least, use "self.env" rather than instantiating an Environment 
object.

Your plugin shouldn't be needed in Trac 1.2 and later due to the new 
notification subscriber capabilities. In fact, your plugin almost certainly 
won't work in Trac 1.2, so you'll want to be sure to remove it when 
upgrading.

- 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.

[Trac] Re: How to switch from htpasswd based users over to session based.

2016-02-01 Thread RjOllos 


On Wednesday, January 27, 2016 at 4:21:03 PM UTC-8, Dan Mahoney wrote:
>
> So then, my question: what's the best way to switch over to the session 
> schema?  I don't even see a users table defined in my database.
>

I overlooked this question. Users are stored in the session table, and user 
attributes are stored in the session_attribute table.
http://trac.edgewall.org/wiki/TracDev/DatabaseSchema#DatabaseSchemaTrac0.12

AccountManager stores the passwords in the session attribute table, as 
shown in the code I pointed to earlier:
https://trac-hacks.org/browser/accountmanagerplugin/trunk/acct_mgr/db.py?marks=86-90#L58
 

-- 
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] Levels or Wikis or Subwikis

2016-02-01 Thread Mo 
Hi,

This is trac-1.0.9. Now that we are populating our wiki I try to get some 
organization and levelling into the structure.

Afaik there are 2 ways for levelling, that is using CamelCase only like
*TestFoo*
*TestBar*

And the Subwikis like Mediawiki:
*Test/Foo*
*Test/Bar*

What is the difference?
As far as I see the Subwikis would create a generic *Test* wiki that has 
all Subwikis as index. Overwriting a *Test* wiki would drop that generic 
page. The CamelCase ordering doesn't create that generic *Test* level.

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?

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] Levels or Wikis or Subwikis

2016-02-01 Thread 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] Enabling Trac Behind Nginx

2016-02-01 Thread Mo 
Am Freitag, 22. Januar 2016 06:42:45 UTC+1 schrieb RjOllos:
>
>
> If we could eventually assemble a solid page describing how to setup Nginx 
> it could be moved into the pages that are distributed with Trac.
>

I definitely agree with that. At the beginning when I was installing Trac 
with Nginx I was trying hard to get more information. While I still have 
some uncertainties and questions regarding how to serve static content 
faster (as I'm no Nginx expert) I would like to share my working setup here 
with Nginx+uWSGI+Trac which in my opinion is a fast and modern combination 
for serving Python. I would like to see an official Nginx-Guide on our 
install wikis soon...

Setup for 2 trac instances (pro and test) with SSL and plain http access:

/etc/nginx/nginx.conf
user nginx nginx;
worker_processes auto;

error_log syslog:server=unix:/dev/log error;

events {
worker_connections 1024;
use epoll;
}

http {
include /etc/nginx/mime.types;
default_type application/octet-stream;

log_format main
'$remote_addr - $remote_user [$time_local] '
'"$request" $status $bytes_sent '
'"$http_referer" "$http_user_agent" '
'"$gzip_ratio"';

client_header_timeout 10m;
client_body_timeout 10m;
send_timeout 10m;

connection_pool_size 256;
client_header_buffer_size 1k;
large_client_header_buffers 4 2k;
request_pool_size 4k;

gzip on;
gzip_min_length 1100;
gzip_buffers 4 8k;
gzip_types text/plain;

output_buffers 1 32k;
postpone_output 1460;

sendfile on;
tcp_nopush on;
tcp_nodelay on;

keepalive_timeout 75 20;

ignore_invalid_headers on;

server {
listen  80;
server_name project;
# Rewrite to force SSL:
#location / {
#rewrite ^/(.*)$ https://project/$1 redirect;
#}
location / {
root /mnt/data/trac/start;
}
location /trac-pro {
include uwsgi_params;
uwsgi_pass unix:/run/uwsgi/trac-pro.sock;
uwsgi_param SCRIPT_NAME /trac-pro;
uwsgi_modifier1 30;
}
location /trac-test {
include uwsgi_params;
uwsgi_pass unix:/run/uwsgi/trac-test.sock;
uwsgi_param SCRIPT_NAME /trac-test;
uwsgi_modifier1 30;
}
}
server {
listen  443;
server_name project;
root/mnt/data/trac;
ssl  on;
ssl_certificate  /etc/ssl/nginx/nginx.crt;
ssl_certificate_key  /etc/ssl/nginx/nginx.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-
SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-
AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-
SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA
:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:
ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-
AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:
AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:
AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK;
ssl_dhparam /etc/ssl/nginx/nginx.dh4096.pem;
keepalive_timeout70;
add_header   Front-End-Httpson;
location / {
root /mnt/data/trac/start;
}
location /trac-pro {
include uwsgi_params;
uwsgi_pass unix:/run/uwsgi/trac-pro.sock;
uwsgi_param SCRIPT_NAME /trac-pro;
uwsgi_modifier1 30;
}
location /trac-test {
include uwsgi_params;
uwsgi_pass unix:/run/uwsgi/trac-test.sock;
uwsgi_param SCRIPT_NAME /trac-test;
uwsgi_modifier1 30;
}

# different approaches for serving static content by nginx directly:
#location ~ /(.*?)/chrome/site/ {
#rewrite /(.*?)/chrome/site/(.*) /$1/htdocs/$2 break;
#root/mnt/data/trac/projects;
#}
#location ~ /(.*?)/chrome/common/ {
#rewrite /(.*?)/chrome/common/(.*) /$1/htdocs/$2 break;
#root/mnt/data/trac/projects;
#}

#location /mnt/data/trac/projects/trac-pro/htdocs {
#internal;
#alias /mnt/data/trac/projects/trac-pro/htdocs;
#}
#location /mnt/data/trac/projects/trac-pro/files {
#internal;
#alias /mnt/data/trac/projects/trac-pro/files;
#}


#location /*/chrome/common {
#alias /usr/lib64/python2.7/site-packages/trac/htdocs;
#}
#location ~ /(?.+)/chrome/site {
#alias /mnt/data/trac/projects/$project/htdocs/;
#}
#ocation /trac/files {
#

[Trac] Trac[web_ui] ERROR: Failure sending notification on change to ticket AttributeError: 'TicketNotifyEmail' object has no attribute 'db'

2016-02-01 Thread Avijit Pathania 
Looking for some help troubleshooting this error message. Even with debug 
enabled, this is the only message being printed in the logs.

We upgraded from 0.12 to 1.0.9. This message is seen when making 
updates/closing a ticket. There are no traceback's.
Tickets are created via email2trac and web frontend. There are no entries 
in the maillog to show connections being made on ticket creation. 

There are two issues that are probably related:
1. Trac not sending any emails when ticket gets created
2. The error message - Trac[web_ui] ERROR: Failure sending notification on 
change to ticket #: AttributeError: 'TicketNotifyEmail' object has no 
attribute 'db'

Here is the trac.ini.

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

[components]
acct_mgr = enabled
acct_mgr.admin.accountmanageradminpage = disabled
acct_mgr.api.accountmanager = disabled
acct_mgr.db.sessionstore = disabled
acct_mgr.htfile.abstractpasswordfilestore = disabled
acct_mgr.htfile.htdigeststore = disabled
acct_mgr.htfile.htpasswdstore = disabled
acct_mgr.http.httpauthstore = disabled
acct_mgr.pwhash.htdigesthashmethod = disabled
acct_mgr.pwhash.htpasswdhashmethod = disabled
acct_mgr.web_ui.accountmodule = disabled
acct_mgr.web_ui.loginmodule = disabled
acct_mgr.web_ui.registrationmodule = disabled
autocomplete.* = enabled
timingandestimationplugin.* = enabled
timingandestimationplugin.api.timetrackingsetupparticipant = disabled
timingandestimationplugin.ticket_daemon.timetrackingticketobserver = 
disabled
timingandestimationplugin.ticket_webui.ticketwebuiaddon = disabled
timingandestimationplugin.webui.timingestimationandbillingpage = disabled
tracext.git.* = disabled
tracopt.mimeview.enscript.enscriptrenderer = enabled
tracopt.ticket.commit_updater.committicketreferencemacro = enabled
tracopt.ticket.commit_updater.committicketupdater = enabled
tracopt.versioncontrol.svn.svn_fs.subversionconnector = enabled
tracopt.versioncontrol.svn.svn_prop.subversionmergepropertydiffrenderer = 
enabled
tracopt.versioncontrol.svn.svn_prop.subversionmergepropertyrenderer = 
enabled
tracopt.versioncontrol.svn.svn_prop.subversionpropertyrenderer = enabled
#trac.ticket.notification.TicketAttachmentNotifier = disabled

[logging]
#log_level = ERROR
log_level = DEBUG
log_type = syslog

[notification]
always_notify_owner = false
always_notify_reporter = false
always_notify_updater = false
mime_encoding = base64
smtp_always_bcc = 
smtp_always_cc = m...@domain.com
smtp_default_domain = domain.com
smtp_enabled = true
smtp_from = m...@domain.com
smtp_password = 
smtp_port = 25
smtp_replyto = m...@domain.com
smtp_server = localhost
smtp_subject_prefix = __default__
smtp_user = 
use_public_cc = false
use_short_addr = false
use_tls = false
email_sender = SmtpEmailSender

[ticket]
default_component = General
default_milestone = 
default_priority = standard
default_type = todo
default_version = n/a
restrict_owner = false
max_summary_size = 50
max_description_size = 200
restrict_owner = true

[ticket-workflow]
accept = new -> assigned
accept.operations = set_owner_to_self
accept.permissions = TICKET_MODIFY
leave = * -> *
leave.default = 1
leave.operations = leave_status
reassign = new,assigned,reopened -> new
reassign.operations = set_owner
reassign.permissions = TICKET_MODIFY
reopen = closed -> reopened
reopen.operations = del_resolution
reopen.permissions = TICKET_CREATE
resolve = new,assigned,reopened -> closed
resolve.operations = set_resolution
resolve.permissions = TICKET_MODIFY

[timeline]
changeset_long_messages = false
changeset_show_files = 0
default_daysback = 30
ticket_show_details = false

[trac]
authz_file = 
authz_module_name = 
base_url = https://trac/
cached_repository = false
check_auth_ip = true
database = mysql://root:password@ip
default_charset = iso-8859-15
default_handler = WikiModule
htdocs_location = 
ignore_auth_case = false
mainnav = wiki,timeline,browser,tickets,newticket,search
metanav = login,logout,settings,help,about
permission_store = DefaultPermissionStore
#permission_policies = DefaultPermissionPolicy
persistent_cache = false
repository_type = svn
timeout = 20

Appreciate any insight.

-- 
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] Link to attachments containing a '#' in the filename is not possible

2016-02-01 Thread RjOllos 


On Monday, February 1, 2016 at 6:48:50 AM UTC-8, Riedel, Torge wrote:
>
> Hi list,
>
>  
>
> I added a PDF-document as an attachment to a milestone (milestone name is 
> “1.0.0”). The filename of the document contains a ‘#’ char (let’s say: 
> “MySpec_Version_#2.pdf”). If I now want to add a link from a ticket to this 
> document, I write the following markup:
>
>  
>
> [[attachment:MySpec_Version_#2.pdf:milestone:1.0.0|Specification]]
>
>  
>
> But this does not generate a link, just grayed text. If I rename the 
> attached file to remove the ‘#’ char and attach it again, I can write 
> following markup:
>
>  
>
> [[attachment:MySpec_Version_2.pdf:milestone:1.0.0|Specification]]
>
>  
>
> And it generates a link to the document.
>
>  
>
> Is this a bug or do a miss a trick how to do this?
>
>  
>
> Thanks and regards
>
> Torge
>

It's an open defect: http://trac.edgewall.org/ticket/11304

 

-- 
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] Link to attachments containing a '#' in the filename is not possible

2016-02-01 Thread Riedel, Torge 
Hi list,

I added a PDF-document as an attachment to a milestone (milestone name is 
"1.0.0"). The filename of the document contains a '#' char (let's say: 
"MySpec_Version_#2.pdf"). If I now want to add a link from a ticket to this 
document, I write the following markup:

[[attachment:MySpec_Version_#2.pdf:milestone:1.0.0|Specification]]

But this does not generate a link, just grayed text. If I rename the attached 
file to remove the '#' char and attach it again, I can write following markup:

[[attachment:MySpec_Version_2.pdf:milestone:1.0.0|Specification]]

And it generates a link to the document.

Is this a bug or do a miss a trick how to do this?

Thanks and regards
Torge

CENIT AG, Industriestrasse 52-54, 70565 Stuttgart, Tel.: +49 711 7825-30, Fax: 
+49 711 7825-4000, Internet: www.cenit.com
Geschaeftsstellen: Berlin, Frankfurt, Hamburg, Hannover, Muenchen, Oelsnitz, 
Ratingen, Saarbruecken
Vorstandsmitglieder: Kurt Bengel, Matthias Schmidt
Aufsichtsratsmitglieder: Andreas Schmidt (Vorsitzender des Aufsichtsrats), 
Hubert Leypoldt, Andreas Karrer
Bankverbindungen:
Deutsche Bank (BLZ 600 700 70) Kto. 1661 040 IBAN : DE85 6007 0070 0166 1040 00 
SWIFT-CODE : DEUTDESS,
Commerzbank (BLZ 600 400 71) Kto. 532 015 500 IBAN : DE83 6004 0071 0532 0155 
00 SWIFT-Code : COBADEFF600,
Registergericht: Amtsgericht Stuttgart
Handelsregister: HRB Nr. 19117
Umsatzsteuer: ID-Nr. DE 147 862 777

-- 
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.