Project

General

Profile

Actions

Feature #14420

open

Allow emails from a locked account to be overridden and credited to anonymous user

Added by Deoren Moor almost 11 years ago. Updated almost 10 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Email receiving
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:

Description

I tried several times to submit a detailed report, but the submission filter kept blocking my attempts (Error 422 - This request was denied because it was consid...). I'll try to post that detailed report as a follow-up comment.

Actions #1

Updated by Deoren Moor almost 11 years ago

My follow-up attempt was also blocked, so I'll try to post the report to the forum thread mentioned previously.

Actions #2

Updated by Deoren Moor almost 11 years ago

Scenario:

  1. John Doe leaves Example.com and we lock his account (we don't want him logging into Redmine).
  2. John Doe notices a problem with the Example.com services/products, so he emails support from his email address.
    • While we don't want him in the system John Doe retains access to his original email account since he is an Example.com customer.
  3. John Doe's email is rejected and it is moved to rejected_emails where a support person may or may not notice it being there for some time.

Goal:

  • Allow overriding the locked account status to credit the email from jdoe as coming from an Anonymous user
Actions #3

Updated by Deoren Moor almost 11 years ago

The email scraping script used in its present form:

#!/bin/bash

cd /opt/redmine

sudo -u www-data bundle exec rake -f /opt/redmine/Rakefile redmine:email:receive_imap \
    RAILS_ENV="production" \
    host=mail.example.com username=support@example.com password=secretPassword \
    move_on_success=accepted_emails move_on_failure=rejected_emails \
    project=unassigned category=unassigned tracker=support \
    no_permission_check=1 unknown_user=accept port=993 ssl=1 \
    allow_override=project,tracker,status,priority,category,assigned_to,\
    fixed_version,start_date,due_date,estimated_hours,\
    done_ratio > /dev/null 2>&1

I could see an option similar to this one being introduced for use with an email scraping script:

unknown_user=[ignore|accept|create]
Actions #4

Updated by Jan Niggemann (redmine.org team member) almost 11 years ago

Deoren Moor wrote:

Scenario:
  • John Doe leaves Example.com and we lock his account (we don't want him logging into Redmine).
  • UserID of jdoe tied to
  • While we don't want him in the system John Doe retains access to his original email account since he is an Example.com customer.

Do employees and customers really share the same maildomain? I'd argue that this is insecure, random customers could identify themselves as employees and trick other customers into disclosing information (phishing)...

Actions #5

Updated by Deoren Moor almost 11 years ago

Jan Niggemann wrote:

Do employees and customers really share the same maildomain?

I used 'employee' and 'customer', but really what I had in mind is an educational institution where the same mail domain is shared. I can't speak for others, but ours is setup this way.

Actions #6

Updated by Deoren Moor almost 10 years ago

This would come in handy and would go nicely with other requests to allow locked accounts to be the target of assignee, author and other queries where they're currently excluded.

Perhaps a UI option to "Reject email from locked accounts" or something similar.

Actions

Also available in: Atom PDF