email2trac does not honor Trac permissions when creating/updating tickets

[Dennis McRitchie <dmcr@…>]

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.

[kris@…]

Interested in seeing this fixed too, thanks. :)

[bas]

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

[bas]

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

[bas]

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

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

[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 .

[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 .

[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:

• ​https://subtrac.sara.nl/oss/email2trac/wiki/Email2tracConfiguration#PermissionSystem

[dmcr@…]

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

[bas]

your welcome