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 <[email protected]> >> 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 #nnnn: 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-packages DEPRECATED. 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 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 -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
