Modify

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

Hey Konstantin,

Is this suggestion only for ticket_updates and settings ticket fields. I do not want to implement for every field another permission model. we can wrap the functions that change the ticket fields

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.

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

(In [474]) fine tuning of permission model in:

  • TICKET_APPEND
  • TICKET_CHGPROP

So email2trac will honour the permission set by the trac permission model if set in email2trac.conf. see #214, #198

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

Add Comment

Modify Ticket

Change Properties
Action
as closed The owner will remain bas.
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.