Skip to content
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

Admin user feature (Second attempt) #186

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Lewik
Copy link

@Lewik Lewik commented Feb 15, 2017

Sorry about #185
I removed CRLF to LF, now you could see admin functionality.
I beleive, that admin users should be able to get all emails from all boxes. This will be very usefull for using greenmail in development.

@marcelmay
Copy link
Member

Some thoughts about this:

  • Is "admin" the correct name? User does not administrate. It is more of a sink or wildcard user.
  • Current API would enable multiple admin users. This probably makes no sense?
  • Instead of configuring such a user, what about one predefined special user with this behaviour, always available? By convention instead of having to add such a user?
    I could think of additional predefined, special users:
    • {greenmail.all}@greenmail for all mails, for all domains
    • {greenmail.all}@<DOMAIN> for all mails for given DOMAIN

@buildscientist
Copy link
Member

I also wanted to add that it's not clear to me why you need an admin user?

@Lewik can you explain to us what you're trying to accomplish?

  • What is your use case?
  • How would this functionality help you accomplish what you're trying to do.

I beleive, that admin users should be able to get all emails from all boxes. This will be very usefull for using greenmail in development. This will be very usefull for using greenmail in development.

This statement does not explain why you need this feature. Based on the PR it sounds like what you're trying to do is add an API to allow for easy access to any users email in a mailstore.

@Lewik
Copy link
Author

Lewik commented Feb 16, 2017

@buildscientist At the moment we (team) need to implement some sort of intelligence mail ... blast. Broadcast to multiple users. Each user have particular email. Like [email protected] [email protected] and so on. While developer works on that, he need to login (we use web ui for that) to [email protected] than login to [email protected] - it's not useful. We will be very happy, if we could have one account to get ALL emails. We will have more complicated mail blasts, so we really need this. Seems that @marcelmay got what I want, may be he can explain more verbose.
"you're trying to do is add an API to allow for easy access to any users email in a mailstore" - yes I do.

@marcelmay
I just found mbaechler/Greenmail#14 and try to repeat admin (ALL emails) part

  • Yes, admin user do not administrate. I'm not so good at English, please choose any name and I will rename it.
  • Yes, after my PR there can be multiple admin users. Multiple is not necessary but there really no need to restrict number of admin. Devs/Test will configure users and they will have all info about that.
  • Actually, I don't this that predefined wildcard users is good idea:
    • Hardcode is not good.
    • I can't come up with example, but I believe that there can be some existed naming convention within dev team. And our predefined user could mismatch with that.
    • As I know, greenmail is only for devs/tests. Devs/tests do not need to made doman-wildcard-user. Either I can code configurable doman-wildcard-user. But I don't think that this is useful.

@Lewik
Copy link
Author

Lewik commented Feb 21, 2017

Any updates?

@marcelmay
Copy link
Member

@Lewik
Why do you need to configure this special user, what is the motivation/requirement vs. a preconfigured one?

@marcelmay marcelmay self-assigned this Feb 23, 2017
@Lewik
Copy link
Author

Lewik commented Feb 24, 2017

@marcelmay I can't come up with 100% reason. Why preconfigured is better? =)

@marcelmay
Copy link
Member

Because you do not require an API, and Convention over Configuration.
No API maintenance, no increased complexity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants