Modify

Opened 14 years ago

Closed 14 years ago

#202 closed enhancement (fixed)

email2trac does not honor Trac permissions when creating/updating tickets

Reported by: Dennis McRitchie <dmcr@…> Owned by: bas
Priority: major Milestone: Version 1.5.0
Component: email2trac Version: trunk
Keywords: Cc: kris@…

Description

Hi Bas,

I love this script, and am increasingly using it with our Trac projects; however, one problem is that it does not appear to respect the Trac permissions set up for creating or updating tickets.

This seems to happen whether the reporter is "anonymous" (in which case, I would expect it to respect the permissions assigned to "anonymous"), as well as when the reporter has an email address that can be translated into one of the known users (where I would expect email2trac to respect the permissions for that user).

As it is, email2trac will create a ticket for anyone, even if that person could not create a ticket if they went to the Trac website and tried to do it from there. I would think the two methods should be consistent.

Is this intentional, or just something you have not had time to get around to yet? Or worse still, does Trac not support a way of finding out the permissions using its API?

Thanks,

Dennis

P.S. I'm actually using 1.4.2, which is not on the Version drop-down list.

Attachments (0)

Change History (10)

comment:1 Changed 14 years ago by kris@…

  • Cc kris@… added

Interested in seeing this fixed too, thanks. :)

comment:2 Changed 14 years ago by bas

  • Status changed from new to assigned

I will look into it, just back from a short break and will combine it with #203

comment:3 Changed 14 years ago by bas

  • Version changed from 1.4.3 to trunk

I just found out how this works and can be easily implemented. So you get the same behaviour as you expect with the web interface. Only side effect there is no feed back. I user does not know why it fails. Maybe we must implement a log fucntionality

comment:4 Changed 14 years ago by bas

(In [397]) implement permission system for ticket. Added

  • None
  • trac permission model, see #202, #203

comment:5 follow-up: Changed 14 years ago by bas

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [398]) Added permission check system, closes #202, #203.

  • can be activated by setting ticket_permission_system:
    • ticket_permission_system: trac
    • ticket_permission_system: update_restricted_to_participants

If it is set to trac it will honour the settings that are set in the trac system.

If 'update_restricted_to_participants' is choosen then a ticket update is allowed only if:

1) the updater is the reporter, 2) the updater is in the CC 3) the updater has trac permission to update the ticket.

If the update is denied, a new ticket will be generated instead as to not loose the issue .

comment:6 Changed 14 years ago by bas

  • Milestone set to Version 1.5.0

comment:7 in reply to: ↑ 5 Changed 14 years ago by Dennis McRitchie <dmcr@…>

Thanks very much, bas!

Can 'ticket_permission_system:' be set to both values?

If not, then, is setting it to 'update_restricted_to_participants' a super-set of setting it to 'trac'? That is, if I set it to 'update_restricted_to_participants', and a *new* ticket email arrives, will it honor the trac permissions?

Both features are valuable, and it would be desirable to enable both. This should even apply, I think, to the fallback behavior that if the update is denied a new ticket will be created: this behavior should only occur if trac permissions allow it. So either the user or 'anonymous' would need to have TICKET_CREATE permission.

Thanks,

Dennis

Replying to bas:

(In [398]) Added permission check system, closes #202, #203.

  • can be activated by setting ticket_permission_system:
    • ticket_permission_system: trac
    • ticket_permission_system: update_restricted_to_participants

If it is set to trac it will honour the settings that are set in the trac system.

If 'update_restricted_to_participants' is choosen then a ticket update is allowed only if:

1) the updater is the reporter, 2) the updater is in the CC 3) the updater has trac permission to update the ticket.

If the update is denied, a new ticket will be generated instead as to not loose the issue .

comment:8 Changed 14 years ago by bas

Dennis no you have to choose one of the models. Trac will honor the permission set by trac. The other option will allow all users to create tickets and only the owner and user that have the right trac permission to update the ticket. So if the user can not update the ticket a new one will be created. Hope this clarify some things:

comment:14 Changed 14 years ago by dmcr@…

  • Resolution fixed deleted
  • Status changed from closed to reopened
So I guess I'll go with setting the new parameter to 'trac', and that will
be a big improvement over the previous version. Thank you.

Just as a suggestion, it may be worth allowing the two options to be
combined, so that creating a ticket requires permission, and updating a
ticket will be even more restrictive by allowing only the reporter and owner
(who must also have permission) to perform this action.

But thank you for the prompt action on a very useful script.

Best regards,
             Dennis

comment:15 Changed 14 years ago by bas

  • Resolution set to fixed
  • Status changed from reopened to closed

your welcome

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.