-
-
Notifications
You must be signed in to change notification settings - Fork 403
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create email log page #651
base: master
Are you sure you want to change the base?
Create email log page #651
Conversation
@TheLastProject , please check out issue 599. Would this address your need (admittedly in a completely different way)? |
It would work, yeah. But it seems more complex to me and easy for things to go wrong when filtering that data back out when replying causing possible data leakage to other users. But it indeed would solve my issue. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The PR looks good so far, just left 2 comments :).
{% endif %} | ||
</td> | ||
<td> | ||
{{ email.contact.email }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can preload the email_log.contact.email
to avoid generating another query to the database. Here's an example to preload the Alias.mailbox
:
Session.query(Alias).options(joinedload(Alias.mailbox))
@@ -7,6 +7,15 @@ | |||
</a> | |||
</li> | |||
|
|||
<li class="nav-item"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this page isn't used a lot by "beginner" users so I'd put it in another place. I don't have an idea on where to put it yet though, I'll change its location after the PR is merged then :).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah that's a good idea!
Sorry I haven't gotten back to this, been quite busy and the current way of blocking single emails that's currently implemented in SimpleLogin is good enough for my needs. I personally would still like to see a method where I don't have to check which alias I received a spam mail on before I can block the sender, which this PR solves, but I don't think I'll have time to get back to this PR any time soon. Maybe someone else can finish it :) |
I sometimes get spam and find it difficult in my mail client to see which alias is actually receiving the spam. Having the full log would be nice to have to more quickly disable the alias
I understand this probably won't scale as-is, but I first wanted to discuss this a bit before putting a lot of time into this.
My plans for this:
Screenshot:
May also be worth making the boxes on the top of the aliases screen clickable instead, to not have an extra navigation option: