Real Issue Tracker

There is a way. By default the issuetracker sorts by creation date but you can change this to be by modification date. The modification date of an issue is always the same as the creation date of the latest followup within it.

The drawback is that changing this changes the whole issuetracker you're using.

If it's broken you should get some errors in the event log if the product (from svn) can't be installed. It's important that the name is "IssueTrackerProduct" no matter where it comes from (SVN or .tgz). Any other name with break it.

Look for errors and deal with those. It could be permission related if you've got a complex setup.

If you don't get any errors in the event.log, try clicking on IssueTrackerProduct in /Control_Panel/Products/manage_main

I tried a fresh svn checkout on a dev system with the same specs. This is what the event log says.

2008-04-14T01:09:09 ERROR Application Could not import Products.IssueTrackerProduct
Traceback (most recent call last):
File "/usr/lib/zope2.10/lib/python/OFS/Application.py", line 703, in import_product
product=__import__(pname, global_dict, global_dict, silly)
File "/var/lib/zope2.10/instance/sandbox/Products/IssueTrackerProduct/__init__.py", line 13, in ?
import IssueTracker
File "/var/lib/zope2.10/instance/sandbox/Products/IssueTrackerProduct/IssueTracker.py", line 133, in ?
from TemplateAdder import addTemplates2Class, CTP
File "/var/lib/zope2.10/instance/sandbox/Products/IssueTrackerProduct/TemplateAdder.py", line 123, in ?
from Constants import DISABLE_CHECKOUTABLE_TEMPLATES
File "/var/lib/zope2.10/instance/sandbox/Products/IssueTrackerProduct/Constants.py", line 222
'sxi':'sxi.png', 'sxw':'sxw.png' 'rar':'rar.png',
^
SyntaxError: invalid syntax
------
2008-04-14T01:09:10 WARNING OFS.Uninstalled Could not import class 'IssueTracker' from module 'Products.IssueTrackerProduct.IssueTracker'
------
2008-04-14T01:09:13 ERROR Application Couldn't install IssueTrackerProduct
Traceback (most recent call last):
File "/usr/lib/zope2.10/lib/python/OFS/Application.py", line 752, in install_product
global_dict, global_dict, silly)
File "/var/lib/zope2.10/instance/sandbox/Products/IssueTrackerProduct/__init__.py", line 13, in ?
import IssueTracker
File "/var/lib/zope2.10/instance/sandbox/Products/IssueTrackerProduct/IssueTracker.py", line 133, in ?
from TemplateAdder import addTemplates2Class, CTP
File "/var/lib/zope2.10/instance/sandbox/Products/IssueTrackerProduct/TemplateAdder.py", line 123, in ?
from Constants import DISABLE_CHECKOUTABLE_TEMPLATES
File "/var/lib/zope2.10/instance/sandbox/Products/IssueTrackerProduct/Constants.py", line 222
'sxi':'sxi.png', 'sxw':'sxw.png' 'rar':'rar.png',
^
SyntaxError: invalid syntax
------
2008-04-14T01:09:13 INFO Zope Ready to handle requests


I know the date is off, that is a separate issue, but the 8.3 tar file works and is the same

Here are the system settings.

Zope Version

(Zope 2.10.3-final, python 2.4.4, linux2)
Python Version

2.4.4 (#0002, Mar 7 2008, 04:45:43) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)]
System Platform

linux2
SOFTWARE_HOME

/usr/lib/zope2.10/lib/python
ZOPE_HOME

/usr/lib/zope2.10
INSTANCE_HOME

/var/lib/zope2.10/instance/sandbox
CLIENT_HOME

/var/lib/zope2.10/instance/sandbox/var
Network Services

ZServer.HTTPServer.zhttp_server (Port: 8028)
Process Id

2926 (-1262044272)

Argh!! It was an accident. I managed to check in a python file that had a Syntax error in it. :( Just do a SVN update and try again. I really ought to combine the checkins with running of unit tests.

No comment.

Updated to build 198, but the menu is broken. Notice the copy and paste of the menu below, there is a duplicate for each menu item overlapping it.

* Home Home
* Add Issue Add Issue
* Quick Add Issue Quick Add Issue
* List Issues List Issues
* Complete List Complete List
* User admin

Also attached is a screenshot.

On the bright side, pop3 retrieval did work. Though it is not formatting the html emails from outlook properly.

Look for any errors in the event log. There's something wrong, perhaps, about how images are installed.

No comment.

No it's not I'm afraid. It's best to create the IssueTrackerProduct instance outside Plone due to some outstanding bugs regarding logins being mixed up with Plone's logins.

I have done this in the past except for integration with user assignment. Instead I used "Sections" to also assign the Issue - by using a group notifyable of the same name as the "Section" and adding a few lines of custom code.

Sorry... previous submission was from me

I see, it's because it can't find some images files. I've got Zope running (with VHM) behind Apache and some mod_rewrite rules; I'm going to have to take a look at everything.

I'm accessing the site as:

/zope2/issues.foo.com

The image URLs that IssueTracker is trying to use look like:

/misc_/IssueTrackerProduct/home.gif

I'm not sure if this makes sense. For example, the image URLs that Zope uses look like this:

/zope2/p_/ControlPanel_icon

That is, they include the appropriate directory prefix.

The image URLs are generated in Constants.py, which doesn't import any of the Zope modules. I think you need to call absolute_url() in order to generate these URLs correctly.

I've modified displayMenuItem to fix this problem. I've modified the return statement so that section of code looks like:

            if imgdata.has_key(identifier):
                d = imgdata[identifier]
                d['src'] = '%s%s' % (aq_parent(self).absolute_url(), d['src'])
                return tmpl%d + ' ' + show_title

This causes the URLs in <img> tags to use the correct path.

Okay, that wasn't quite right. But you get the idea.

I'll try to have a look later this week.

Zope 2.9.7. I'll take a look.

I just tested it in Zope 2.9.7 and it works fine. /misc_ is still there as expected.

You've probably got your modrewrite wrong. Use the Zope mailing list for advice if you're stuck. I read that list too and looking forward to see your apache config to help you figure out what's wrong with the /misc and /p_ specials.

PS. If you can, I advice that you use ProxyPass instead of mod_rewrite. Much simpler and harder to get wrong.

I'm reasonably certain that this is, in fact, a problem with IssueTracker. mod_rewrite and mod_proxy don't enter into this discussion -- the fact is that you're using absolute, static URLs for the nav images rather than trying to acquire the appropriate root URL. You can't expect '/misc_/' to point into a Zope instance; you might be located several components down a hierarchy (so the appropriate URL is /org/dept/misc_ or something).

I've resolved the problem on my local copy like this:

* In Constants.py:

if not data['src'].startswith('/'):
data['src'] = 'PORTAL_ROOT/misc_/IssueTrackerProduct/%s'%data['src']

* In IssueTracker.py:

if imgdata.has_key(identifier):
d = dict(imgdata[identifier])
d['src'] = d['src'].replace('PORTAL_ROOT',aq_parent(aq_inner(self)).absolute_url())
return tmpl % d + '&nbsp;' + show_title

This appears to correctly acquire the root URL, and works regardless of whether the IssueTracker instance is at the root of a request or if there are several other path components before it.

A cleaner solution would be to move the URL initialization out of Constants.py (because they aren't really constants), but this at least demonstrates a working solution.

I have to say that you're the first Zope user I've heard who's had problems with /misc_ not being in the Zope root.

Out of curiousity, if you bypass apache and go straight to the Zope on :8080 (or whatevery you have) does /misc_/IssueTrackerProduct/home.gif still work?

Here's how I do my apache proxypassing (for example):

 <VirtualHost 80.68.212.7>
  ServerAdmin mail~AT~peterbe_dot_com
  ServerName peterbe.mobi

  ProxyPass / http://localhost:9080/VirtualHostBase/http...i:80/www/VirtualHostRoot/
  ProxyPassReverse / http://localhost:9080/VirtualHostBase/http...i:80/www/VirtualHostRoot/
  ProxyPass /misc_ http://localhost:9080/misc_
  ProxyPass /p_ http://localhost:9080/p_

  ErrorLog /var/log/apache2/peterbe.mobi.error_log
  CustomLog /var/log/apache2/peterbe.mobi.access_log combined

 </VirtualHost> 

Thanks for that example, Peter. Put it somewhere where its easy to see, helps more people, and yourself from bothering with this again :)

Ah but after reading more on this I'm not sure if Lars maybe has a point here. I think some other zope-products (like zwiki which I've tried briefly) does what he proposes. But they've surely discussed it a lot .. see http://zwiki.org/VirtualHostingSummary

I've used ProxyPass until today but new requirements forces me to use mod_rewrite and serve zope from a subdirectory. I agree that this info should be put in the documentation somewhere. Here are my mod_rewrite rules that I use for serving a "zope subfolder" through apache:

  # zope special folders
  RewriteRule ^/p_$        http://127.0.0.1:9673/p_ [L,P]
  RewriteRule ^/p_/(.*)    http://127.0.0.1:9673/p_/$1 [L,P]
  RewriteRule ^/misc_$     http://127.0.0.1:9673/misc_ [L,P]
  RewriteRule ^/misc_/(.*) http://127.0.0.1:9673/misc_/$1 [L,P]
  # zope root folder
  RewriteRule ^/mysubfolder$ \
  http://127.0.0.1:9673/VirtualHostBase/http/%{SERVER_NAME}:80/VirtualHostRoot/_vh_mysubfolder [L,P]
  RewriteRule ^/mysubfolder/(.*) \
  http://127.0.0.1:9673/VirtualHostBase/http/%{SERVER_NAME}:80/VirtualHostRoot/_vh_mysubfolder/$1 [L,P] 

see the image attached, the text is goign out of the box for message

i observed that if \r (enter/return) is not given after the url then its not formatted as url after submission

http://www.yahoo.com

i tried in real product tracker if the url get formatted as link if no enter/return is added after it before save button is pressed.
In this tracker it did format it as url but in our trakers using the 0.7.2 version its not working.

i think this is some either settings problem on lcient side or browser compatibility issue.

as it happens in 50% of the client PC in our office whereas many others can post normally.

I did some reasearch and found that this is related to default display format setting

in ZMI interface for tracker, in properties >> advanced there is setting
called dafault display format and you can select it to be structuredtext or plaintext

if this is structured text then this formatting problem come.

problem is this that even if i change it to plain text this problem continues because the tracker continue to create the new issues and folloups in structuredtext itself, even though this setting is change to plaintext.

i changed default display format to plaintext,
I then went to the individual issue tracker issue and check it properties, it was structured text instead of plain text.
I then changed the property manually to plaintext and saved issue properties.

and then viewed the issue, now the problem was gone , formatting was proper .


Hence there seems to be 2 bugs

1. In structured text the formatting is not happening properly

2. even if the default display format is changed to plain text, the issues and followups continue to be created with structuredtext format



Please help .. I cannot change format of every issues and folloup to plain text.

Ok I found some more info

I observed that if default display status in any tracker is structuredtext, and you go to that browser and submit followup or add issue, then in your broser cookie the structured text becomes default format for all postings in all trackers.

hence even if you go to tracker where plaintext is default format, your posting will be structured text.

in the same way with you delete the cookie and go to the tracker where plaintext is default display format and you post the folloup or issue then in your browser cookie the default format is plaintext for all trackers.

this cookie create problems

in plaintext you can post folloups that are formatted properly

but structured text formatting by tracker is not correct and has errors.

hence always use plain text as default display format in tracker properties, and if u find format problem delete you cookie and try again

normally if different users have different settings in their trackers then you will find that in same issue some postings are in plain text and some are in structured text

will fix. Any idea what version you have?

After I make this fix you might have to upgrade to the latest CVS version. Do you know how to do that? 

It's really hard to reproduce the error. I've been looking at the code and haven't yet found much reason for the recursion.

Can you tell me what your zope structure looks like. The container to which you added the issuetracker, what kind of container is it? What other types of objects are there inside that? A simple screenshot(s) would probably give me a lot of information. If you don't want to upload such a screenshot(s) you can send them to me personally.  

This happens even after creating the Issue Tracker object and selecting "Add" instead of "Add and go to Wizard" and then selecting Properties. Attached the Zope status before adding the IT object (001.png) and the IT object itself (004.png)

hmm. plone again :(
always a troublemaker.

If you create a plain folder  first and add an issuetracker inside it I bet you won't get the recursion error.

I tried to create an issuetracker next to several plone instances I had on one of my older zopes and it was no problem. What kind of unusual objects do you have inside the plone sites? 

Many

Archetypes 1.3.2-final
AttachmentField 1.3RC5
MimetypesRegistry 1.3.3-final
PloneExFile 3.02
PortalTransforms 1.3.3-final
TextIndexNG2 2.2.0 b2 (28.02.2005)

Ok, Creating the folder to host the IT object works.

If you need other infos about my Plone site just ask, it contains nothing secret. But I can not give you access to it (internal network).

I've really really tried to find out what might be wrong but am not having any luck.

The recursive pattern that I use is a straight forward simple ZODB pattern that should work. Clearly there's something buggy in your Plone instances which is Plone's fault. However, I would like to know more so that I can help innocent people like you.

In your zope object root can you create a Python Script with ID recursive_finder2 and upload the attached file to it and see what results you get when you run it.  

I'm not sure of what I did: I clicked on the script and selected the "Test" tab; then clicked on "Run Script". What I get is in the attached screenshot.

Oops. Sorry. You won't have the method LOG. Remove the line:

 context.LOG(inobject)

and try again. 

Ok, works: the output is quite long. Happy reading :)

It works!?! If that script works, why doesn't the loop in the issuetracker work? Very very odd.
I've made some minor touches to the recursive loop that might give us a slighter bigger chance of not getting stuck.

Upgraded to 0.7.2? Still experiencing this problem?

Sorry for the delayed answer: I didn't upgraded it because it is not yet available for Gentoo, I'll ask the maintainer as soon as possible and give you a feedback.

Upgraded to 0.7.3 and it works perfectly; no problem with Plone (2.5.2) even if creating an IssueTracker object in the same Zope folder. Thank you very much.

no problemo.

How are you logging in? Into a regular Zope ACL user folder or an IssueTracker User Folder?

What version are you using? If CVS, can you upload the CHANGES.txt file here. There have been changes surrounding the catching of names and emails somewhat recently I think. I'm keen to help you help me solve this one.

Does this only happen on issues and not on followups? 

well thanks for the quick reply.

1. We don't have any specific login mechanism. we disabled annonymous access to Issue Tracker And allowed only people who log into plone.

2. Issue tracker version is the latest,IssueTrackerProduct-0.7.1.
Plone version: 2.1.2. Zope version: 2.8.5-final.

3. Iam not maintaining any zope acl-users. Its only users created in plone would be accessing apps like issuetracker.

4.We are not maintaining any CVS server.

5. "No name or email" is occuring for both issues and their followups.

Hope this would be clear.

I am experiencing the same issue. I am using Zope 2.9.2 and IssueTracker 0.7.1. I have this issue when a logged in user adds and issue. The Add Issue page shows the user name <username> in the User: portion of the window, but I do not see the user id in the form variables anywhere.

I'm not sure if this is related or another issue, but I will mention it here in case it is related. As I was experimenting with IssueTracker if I created an issue prior to logging in, and entered a dummy name and email for the issue, then after logging in, I would still see the user name that I created as a dummy instead of my user name. Hope this helps.

yah, even this is the same case for me.

Steve,

No, if you're logged in as some sort of ACL user, the form won't have a hidden variable. It can distinguise that you're logged in in the saving method too. It's more secure that way.

If you create an issue as "dummy" and then log in after, of course the issue you created before you logged in is still going to be "dummy". That's not a mistake. That's like it should and ought to be.
Or... am I not understanding your description.

 Ramy, can you do me a favor? On the issues that were saved but now says "Submitted by: No name or email" can you log in with /manage and look at the properties of that issue (or followup) and see what it says in the acl_adder, fromname and email?

In the properties of issue,following things appears

acl_adder: /insight/acl_users,radha

fromname, email are empty.

Thanks Ramy. That's interesting. What kind of object is /insight/acl_users? Is it a Issue Tracker User Folder, a plain zope User Folder or something else? Is the user "radha" still defined in there?

My next conclusion very much depends on what kind of user folder it is. If the user has a fullname and email (ie. it's a Issue Tracker User Folder) then it should not just save the acl_users link to the acl_adder property but also save the fullname and email to the issue as "backup properties" in case the acl user disappears. 

well, the "acl_users" is a plain zope folder. For ur convinience, iam also attaching the acl_users window.

Cool. I think I've got something for you then Ramy. Just give me a couple of hours and I think I might be able to fix the problem.

It's been fixed. I was able to reproduce it and fix it accurately. It was a stupid misstake.

The only problem now is that since SourceForge's CVS server is dead you can't upgrade my latest changes. I'll get back to you on that later.  

We also ge this problem in new versions. What we observe is that there is no relation between the from user/email id and the logged in user.

from user and email id are stored in cookie in browser. If I clear/delete all cookies in browser and post followup (after user login) I still get the "submitted by" is being "no name or email".

More important aspect is that after deleting cookies, if I login with my username/password for zope/plone acl-users and then goto issue tracker, click on add folloup. it will show me form where I can enter any submitted by name or email (irrespective of my username). And this will set the bookie that will be used always. So even if i login and post folloup, it will show submitted by someone whose name is there is the cookie.

Due to this we are not able to track who actually posted the issue.

I think submitted by username(of logged in user) must be shown even if name and email is shown form the cookie.

Ideally I think that issue tracker should use username, email and name as stored in acl user folder of plone if plone users are used in issue tracker. Else cookie form may be used.

No there isn't. What would be the point of doing that?

If multiple emails come into the issue tracker regarding ONE issue. I would like to be able to convert/merge the duplicate issues as follow-ups to the first rather than deleting them.

We get this all the time: one email comes in and creates the ticket, but is CC'd to everyone at the company who is involved (people love that cc thing here). Each of them hits Group reply, which includes the tracker email. It would be great if I could select via checkbox all the tickets I wanted and then hit merge from teh list screen, it would put all the selected tickets' comments into the first one, combine all subscribers, and, to use the email inbox analogy, one 'thread' of comments. I can't imagine that's a simple task, but it's something I run across continuously.

The other trackers I was comparing this one to seem to put the ticket number somewhere in the email and then look for that, whcih auto-merges them, but that may be a seperate feature request.

Being able to do it manually would be great all by itself.

Ah! I see what you mean then. In the future there might perhaps be a
way to administer which issues are blocked by which other issues. Thus
a way to manage dependencies.
For the moment nothing is really planned on the merging idea. But it's
great to hear people thinking about it. If you have some more specific
ideas about how it could practically work then let us know.


--
Peter Bengtsson,
work www.fry-it.com
home www.peterbe.com
hobby www.issuetrackerproduct.com

hmm. I can't reproduce it and I can't remember why or what was the problem because this once used to be a bug. What version do you use? Are you having the same problem on all your issuetrackers (if you have multiple)?

Here on this Real issuetracker I can expand and hide as much as I like and it works correctly.

Just using the one tracker at the moment.
Yesterday upgraded to 0.6.12 in the hope it would fix this problem.
Zope is at 2.8.1-final
Python 2.5.1
Win32 system (windows 2000 host and clients)
Internet explorer 6.0

what do you have in your User page? Do you have issues assigned to you. Are you logged in as a Issue User or a normal acl zope user?

Can you hide and expand the list of added issues? ...but not the list of followed up on? Does your browser support cookies?

I am personaly logged in as a zope user...
I have both added and followed up issues.
The hide/expand works ok on added and assigned!
Another user who is just a issue manager has the same fault!

I have noticed another odd occurance in the stats page - the first two section appear to work fine but the graph wrong. I have included a screen grab.
Do you think the errors are linked?

Thanks for the screenshot. It led me to fix something else but that's unrelated.

I'm having a hard time reproducing the bug. I have instead added a little something that might help us solve this problem. I've attached two python files on this followup. Could you please replace the old ones with these and restart your zope. Before you restart Zope, you'll need to do something to enable the issuetracker to go in debug mode. That you can do by setting:

 set DEBUG_ISSUETRACKERPRODUCT=1

In the script you use to start Zope. I don't use windows myself but I'm sure we can find a way to do that on your system.

Grateful for your help.

Looks like you have hit the problem with these files..
Now all seems fine!!
Windows runs zope as a service hence it is simpler to mod constants.py to switch on the debug info...
Have / when do you intend to release the fix for the graphs?

Cheers for the great service

Cool. The graph is fixed and will included in the next release which will be 0.6.13 which I hope to make as a stable release.

test

I will look into it. It shouldn't be so.

No I can't reproduce this.

Have you tried doing the same on an issuetracker where you don't use btreefolder for storage?

And last but not least, what's the error message? ...exactly.

I'll try and describe the situation more precisely:

In the BTreeFolder2 called "issues" within my "IssueTracker" instance, there is a selection box that has "Items 1 through 66 of 66". If I select any of them I get another screen that lists all the threads for the given issue.

However, if I select an issue without any followup it says "There are currently no items in [issue title]". Also, for any other issue, it is only the comments that are added after the issue is submitted that can be edited - the original issue posting cannot be edited.

I have not tried this on a IssueTracker not using BTreeFolder2.

This is still not reproducable. I've tried and I can happily edit any object in any combination of btreefolder2 or not and having threads or not.

"Also, for any other issue, it is only the comments that are added after the issue is submitted that can be edited" Obviouslyu there are not comments added before the issue is submitted. I assume you spelled that sentence wrong.

If you can't give me an error message or some screenshots I don't think this is a bug.

Here are the screen shots:

"issue detail" - where there should be an option to edit the issue
"issue listing" - where all issues are selectable

"issue view" - this is how the issue above looks in the issue tracker instance

On the first image you have three tabs: Contents, View, Properties

Click Properties. Then you can edit the issue details.

Oops. Sorry for that extended detour around the obvious. Thanks!

no harm mate Perhaps I can ask you to give something back

Great. We'll solve this. Can you please upload a traceback and I'll fix it.

Here's the traceback:

Traceback (innermost last):
Module ZPublisher.Publish, line 101, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 39, in call_object
Module Shared.DC.Scripts.Bindings, line 306, in __call__
Module Shared.DC.Scripts.Bindings, line 343, in _bindAndExec
Module Products.PageTemplates.PageTemplateFile, line 106, in _exec
Module Products.PageTemplates.PageTemplate, line 96, in pt_render
- <PageTemplateFile at /ausnetech/web/issues/lk/ListIssues>
Module TAL.TALInterpreter, line 190, in __call__
Module TAL.TALInterpreter, line 234, in interpret
Module TAL.TALInterpreter, line 671, in do_useMacro
Module TAL.TALInterpreter, line 234, in interpret
Module TAL.TALInterpreter, line 409, in do_optTag_tal
Module TAL.TALInterpreter, line 394, in do_optTag
Module TAL.TALInterpreter, line 389, in no_tag
Module TAL.TALInterpreter, line 234, in interpret
Module TAL.TALInterpreter, line 694, in do_defineSlot
Module TAL.TALInterpreter, line 234, in interpret
Module TAL.TALInterpreter, line 407, in do_optTag_tal
Module TAL.TALInterpreter, line 389, in no_tag
Module TAL.TALInterpreter, line 234, in interpret
Module TAL.TALInterpreter, line 460, in do_setLocal_tal
Module Products.PageTemplates.TALES, line 221, in evaluate
- URL: ListIssues
- Line 15, Column 0
- Expression: standard:'options/filteredissues|here/ListIssuesFiltered'
- Names:
{'container': <IssueTracker instance at 41e26650>,
'context': <IssueTracker instance at 41e26650>,
'default': <Products.PageTemplates.TALES.Default instance at 0x40bbd74c>,
'here': <IssueTracker instance at 41e26650>,
'loop': <SafeMapping instance at 40ec7770>,
'modules': <Products.PageTemplates.ZRPythonExpr._SecureModuleImporter instance at 0x40bb5d4c>,
'nothing': None,
'options': {'args': ()},
'repeat': <SafeMapping instance at 40ec7770>,
'request': <HTTPRequest, URL=http://www.ausnetech.com.au/issues/lk/ListIssues>;,
'root': <Application instance at 40f18020>,
'template': <PageTemplateFile at /ausnetech/web/issues/lk/ListIssues>,
'traverse_subpath': [],
'user': lk}
Module Products.PageTemplates.Expressions, line 201, in __call__
Module Products.PageTemplates.Expressions, line 196, in _eval
Module Products.PageTemplates.Expressions, line 103, in render
Module Products.IssueTrackerProduct.IssueTracker, line 3871, in ListIssuesFiltered
Module Products.IssueTrackerProduct.IssueTracker, line 3949, in _searchCatalog
AttributeError: 'NoneType' object has no attribute 'aq_parent'

This wasn't really a bug but it wasn't easy to know. The problem was that you had manually updated the ZCatalog after pressing the Update Everything button. What must have happened is that the ZCatalog (objectid=ICatalog) picked up other objects that didn't exist.

If you would have pressed the Update Everything button last it will make sure that the catalog is up to date and only with issues or followups.

Now I've improved the search a lot to make sure this doesn't create an error at least. If the search through the catalog stumbles across "junk" a warning message is printed to the log files.

The new code is in CVS and will be publically available in a few hours. If you don't use CVS you'll have to wait for the 0.6.4 release which is due out in a matter of days or weeks.

PS. I doubt this had anything to do with which user it was. Did you try exactly the same search terms?

Hello again,

Thanks so much for your help thus far.

I think there's some other problem going on because I've just loaded up the latest version via CVS and am still getting an error.

Just backtracking a little to before the CVS update: I didn't actually do the manual ICatalog update until after I got errors. It was just something I tried to see if it would solve the problem - but it didn't.

Also, yes - the problem is somehow related to the user who's logged in. If I log in as the 'lk' user - every search fails, regardless of keyword. If I log in as 'markt' - every search works (using the same keywords as for the 'lk' user tests). This continues to be the case after the CVS upload.

So, here's what I just did:

- I moved my old IssueTrackerProduct directory out of the way.

- Logged into CVS and retrieved the latest IssueTrackerProduct.

- Restarted my zope instance.

- Tried the search function for both my 'markt' and 'lk' users. 'markt' worked, 'lk' failed.

- I got the nice 'System Error' screen which had the following log file attached:

------
Bug Reporting File
2005/02/25 04:24:35.678 US/Eastern

Error type: AttributeError
Error value: 'NoneType' object has no attribute 'meta_type'

IssueTrackerProduct version: 0.6.3
-------

- Don't know whether it's necessary, but I had forgotten to do the 'Update Everything' after doing the CVS download. So, did that and tried the search again - once again, no go.

Here's the full traceback now, which seems slightly different to before:

Traceback (innermost last):
Module ZPublisher.Publish, line 101, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 39, in call_object
Module Shared.DC.Scripts.Bindings, line 306, in __call__
Module Shared.DC.Scripts.Bindings, line 343, in _bindAndExec
Module Products.PageTemplates.PageTemplateFile, line 106, in _exec
Module Products.PageTemplates.PageTemplate, line 96, in pt_render
- <PageTemplateFile at /ausnetech/web/issues/lk/ListIssues>
Module TAL.TALInterpreter, line 190, in __call__
Module TAL.TALInterpreter, line 234, in interpret
Module TAL.TALInterpreter, line 460, in do_setLocal_tal
Module Products.PageTemplates.TALES, line 221, in evaluate
- URL: ListIssues
- Line 1, Column 0
- Expression: standard:'options/filteredissues|here/ListIssuesFiltered'
- Names:
{'container': <IssueTracker instance at 40f0e9e0>,
'context': <IssueTracker instance at 40f0e9e0>,
'default': <Products.PageTemplates.TALES.Default instance at 0x40bbd74c>,
'here': <IssueTracker instance at 40f0e9e0>,
'loop': <SafeMapping instance at 40b79c10>,
'modules': <Products.PageTemplates.ZRPythonExpr._SecureModuleImporter instance at 0x40bb5d4c>,
'nothing': None,
'options': {'args': ()},
'repeat': <SafeMapping instance at 40b79c10>,
'request': <HTTPRequest, URL=http://www.ausnetech.com.au/issues/lk/ListIssues>;,
'root': <Application instance at 40e8e440>,
'template': <PageTemplateFile at /ausnetech/web/issues/lk/ListIssues>,
'traverse_subpath': [],
'user': lk}
Module Products.PageTemplates.Expressions, line 201, in __call__
Module Products.PageTemplates.Expressions, line 196, in _eval
Module Products.PageTemplates.Expressions, line 103, in render
Module Products.IssueTrackerProduct.IssueTracker, line 4149, in ListIssuesFiltered
Module Products.IssueTrackerProduct.IssueTracker, line 4280, in _searchCatalog
AttributeError: 'NoneType' object has no attribute 'meta_type'

------

Hope this all helps toward a solution, thanks once again! :-)

Great thanks for the report. I'm dedicated to sort this out and your help is really helpful.

The code on line 4280 was pretty stupid. It didn't provide a default fallback which would cause the AttributeError. (this actually happened in two places until I now have fixed it). The old code was:

 if getattr(object, 'meta_type') != ISSUE_METATYPE: 

which is now fix to be this instead:

 if getattr(object, 'meta_type','') != ISSUE_METATYPE: 

(Update your CVS in a couple of hours since SourceForge's servers are seriously cached)

The thing is that the ZCatalog contains a reference to an object that doesn't exit. So when getObject() is called on that brain (a brain is a reference item between the ZCatalog and a ZODB object) it returns None which thus caused the system error.

Why is this dodgy brain in the ZCatalog even after you pressed the Update Everything button? The Update Everything clears the ZCatalog and makes sure only good stuff is contained in it.

Why is there a difference between markt and lk? Are they defined inside the same User Folder? What roles do they have respectively? Have you changed the "Manager roles" in the Properties tab?

Have a look inside the ICatalog object. Click the Catalog tab and look at the list of brains. What do you see? On my Demo issuetracker I see only issues and issue-threads (followups). That's what you should see too.

Do you have any other python products I should know of that uses the ZCatalog? Do you run your issuetracker on a virtual host (e.g. bugs.company.com) or vanilla (e.g. localhost:8080/bugs)?

Ok - I've manually patched that 4280 line in IssueTracker.py, which stops the search from crashing - but now of course, the search finds no items when done for the 'lk' user.

Some other answers to your questions:

Why is there a difference between markt and lk? Are they defined inside the same User Folder? : No, actually they're not. 'markt' is setup in the root acl_users folder, 'lk' is setup in the issue tracker acl_users folder within this particular issue tracker instance.

What roles do they have respectively? : 'markt' is setup with the 'manager' role only. 'lk' is also setup with the 'manager' role only.

Have you changed the "Manager roles" in the Properties tab?: I don't think I've ever changed this. It's currently set to just: 'Manager'

Have a look inside the ICatalog object. Click the Catalog tab and look at the list of brains. What do you see?: I see much as you do, just issues and issuethreads. Actually, maybe this is something: it appears all the old issue threads are showing as 'issuethreadxxxx' whereas the new threads (with the current version) are showing as 'threadxxxx' (I've attached a screen shot).

Do you have any other python products I should know of that uses the ZCatalog? I'm using the Zcatalog for a site search function that I have on my website, but that's in a different directory than the IssueTracker instance - wouldn't have thought this would have any affect. Nothing else I can think of that might be affecting this - I haven't modified or added anything to the IssueTracker folder itself, only used it as an end-user would.

Do you run your issuetracker on a virtual host (e.g. bugs.company.com) or vanilla (e.g. localhost:8080/bugs)?: Its running as a virtual host (behind apache, with rewrite rules). However, port 8080 is also open, so I just tried it directly (bypassing apache) and the same problem occurs.

Thanks again for your help. Cheers,

Mark