Opened 14 years ago
Closed 14 years ago
#214 closed enhancement (fixed)
Permission to update the ticket, but not set properties
Reported by: | Konstantin Ryabitsev <icon@…> | Owned by: | bas |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | email2trac | Version: | 1.6.0 |
Keywords: | Cc: |
Description
Hello, me again:
I like the new permissions system, but I would like to see it more fine-grained. I would like anyone to be able to update the ticket comments, but restrict setting properties (via subject line or inline properties) only to people who have permission to update the ticket. What do you think?
Attachments (0)
Change History (8)
comment:1 Changed 14 years ago by bas
- Status changed from new to assigned
comment:2 Changed 14 years ago by Konstantin Ryabitsev <icon@…>
Basically, my problem is this. We started using inline properties, but ran into the problem with "outlook-style replies" (always a problem with these). If I put "@status: closed" in my email and my client replies to it, the "@status: closed" will be evaluated again and ticket won't be re-opened. So, the solution is either to adjust the parsing mechanism to look for outlook-style quoting patterns and stop parsing upon encountering a succession of From: To: Subject:, or to allow setting properties only when From: corresponds to a trac account that has TICKET_CHGPROP.
comment:3 Changed 14 years ago by bas
The TICKET_CHGPROP is a good suggestion and easily to implement in the current model. What is find strange is that the inline properties are not filtered out. So something else is going wrong. There is nothing in the syslog. Here is the code from inline_properties and those line should not be in sent:
for line in text.splitlines(): match = INLINE_EXP.match(line) if match: keyword, value = match.groups() self.properties[keyword] = value.strip() self.logger.debug('inline properties: %s : %s' %(keyword,value)) else: body.append(line)
comment:4 Changed 14 years ago by Konstantin Ryabitsev <icon@…>
Sorry, I caused a bit of a confusion. Trac doesn't send out any emails -- all our communication is done via mail clients. Trac integration is mostly for logging and for adding additional info to tickets (like diffs, notes, attached files, etc). You're right, inline properties are stripped by email2trac, but the client responds to emails they receive from us, not to Trac mails.
comment:5 Changed 14 years ago by bas
comment:6 Changed 14 years ago by anonymous
Very nice! I will test it out tomorrow (not at the office today). One last request I have is for parsing of inline properties -- the one at the top should "win" over any others further down in the message. The use case for this is, again, outlook-style replies, something like:
Hello: Both foo and bar are fixed. @status: closed ----- From: Client To: Developer Subject: Re: Foo needs fixing Yes, please fix bar as well. ----- From: Developer To: Client Subject: Re: Foo needs fixing I notice that bar needs to be fixed as well as foo. Do you want me to fix foo? @status: assigned ----- From: Client To: Developer Subject: Foo needs fixing Foo is not working right, please fix.
In this case "@status: assigned" will win over the latest "@status: closed" because the parser does not check if "status" has been set already as it parses the message. This shouldn't interfere with non-outlook style replies because they are always quoted with ">".
comment:7 Changed 14 years ago by bas
I would be a nice feature. Can you not filter the mail in the MTA to remove those lines before sending the ticket back to the customer? And i or others have to rewrite the stripping of replies. That is the next thing on the todo list. There are a lot of tickets on this subject. For now we have a cluster upgrade and some other projects that need my attention ;-)
It is also depends on the reply setting. Above or Below!
comment:8 Changed 14 years ago by bas
- Resolution set to fixed
- Status changed from assigned to closed
- Version changed from 1.5.2 to 1.6.0
I will close this ticket. The fine tuning of permissions is done. And the last question is another request. Fix is 1.6.0
Hey Konstantin,
by a permission model. For now we can choose two permission models. One of them is trac, so can trac check the permissions you propose.
Maybe i can add hook so you can supply your own permission model.