Real Issue Tracker

I'll have a look.

Any idea what attachedFile_2 is?

Can you figure out what's on line 1094 and line 1077 in your IssueTracker.py since it's different from my latest version now.

A quick followup... The email I was sent (as notification) had the correct 'submitted by' information in it.

Sorry about all the followups in such a short time..

Looking through the ZMI, I found one of the issues that's causing problems and looked at the issue's properties. Under properties, 'fromname' and 'email' are both set correctly. That is, the actual submitter's name and email are correct. Also, the acl_adder value is "/munhousing/acl_users,tony" which appears correct also.

I began to wonder if it was my customized ZPT causing the problem so I renamed it so issuetracker would use the default ZPT and still have the problem. So we can rule that out.

Once again I will investigate further.

I tracked down this specific error.. Not sure if it is present multiple times in the code or not, but here's the one I found..

in Issue.py, somewhere around line 2779 (may be +/- a few lines since I've edited the file):

authenticated_member = mtool.getAuthenticatedMember()

should be
authenticated_member = mtool.getMemberById(name)

The getAuthenticatedMember method return the currently logged in member, but we want the member who submitted the issue.

Tomorrow I'll poke around the rest of the code to see if this error is in more than one place.

haha, one more followup, the line number is closer to line 209.. Was looking at the wrong number in vim..

Thanks a bunch! I'm away from the office and my laptop for a few days. Will update and fix when I get back.

The same error is in the getEmail method in Issue.py, directly under the spot mentioned above.

Same problem in Thead.py, line 117

Done. All in svn. Thanks for your support!

I don't understand why, but on line 144 in Thread.py I had to change back to

authenticated_member = mtool.getAuthenticatedMember()

otherwise all emails in the thread were set to the first email address in the thread.

The CVS version has the email correct, the SVN version does not, that is how I came up with this change.

I don't get what you mean. Surely getMemberById(name) returns the member object based on a name and getAuthenticatedMember() just returns the currently logged in member.

There are 4 places where getMemberById() (showing issues and followups) is used and 1 place where getAuthenticatedMember() (submitting issues and followups) is used.

Wow! Cool. I've only just begun reading the patch and it looks quite promising so far. I'll patch it in on a dev branch and scrutinize your code.

And yes, this won't be on by default. But a great "advanced feature" for those who know what they're doing.

One thing that did catch my eye was this:

     def safe_getProperty(self, property, default, where = None):
        """Try to get a property, else return default"""
        try:
            where = where or self
            return type(default)(where.getProperty(property)) or default
        except:
            return default

Where did you learn that syntax? Perlschool? :) Seriously, I'd rather see a:

 def get<InsertPropertyName>(self):
     return self.<insertpropertyname>

...but that's secondary. To begin with I'll look at the functionality.

The idea was to factorize code, by avoiding having many functions that does the "same thing", only the name of property being different (being blocked by and blocking in my implementation is, technically, the same, just the wording and property name have to be different).

Another goal of this code was to prevent any backward compatibility problem: if the property doesn't exist, all fine, we have defaults, so need to run migration scripts (which, on our 100 trackers with some have >1000 issues takes a loooong time and sometimes even crash the zope).

But feel free to implement it in another way if you prefer

I can't reproduce this one. I...

• created a standard User Folder object
• created a user in there with role Manager
• went back into the folder which holds the user folder
• created an Issue User Folder
• said that I wanted to keep the one user I had in there
• entered an email for him and created the Issue User Folder
• went back to change the email address

All went fine. I have linux but the same versions for Zope and Python as your bug report.

Any more hints on how to solve it? Can you try to wrap up the whole traceback with REQUEST and everything for me?

(if you feel so so about showing this, how about sending it via email to me personally?)

just changing the status

That might be tricky, only in that the Issue Trackers it happened on existed prior to the 0.6.5 update, I'll see if I have an old dead one around I can test with.

I have an existing Issue Tracker which just has too many users without email addresses to make me bother converting up to now, apart from the bug I appeared to have.

I copied that Issue Tracker, Added a IT User folder to it, added in some email addresses (it would be better if keep were automatically updated if an email addresses was added) and then let it create it which it did without error.

If keep is selected without a valid email address then a fairly ugly error page gets put up.

I imagine the original error was caused by some weirdness within that Issue Tracker or that ACL folder. And as neither of us can now reproduce it, mark it as Closed.

thank you. your help is appreciated.

Ah I spoke too soon. The error is in then going into the User Folder and then editing one of the converted users, when I get the exact problem as above.

http://............/tfhIssues/acl_users/ma...=jonathan&submit=Edit

Is the actual request, obfuscated a little.

The cause is that the user it fails on post the copy doesn't have a role explicitly set.

In other words, the fix would be to assume a role of Issuetrack user in the absence of one.