You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Something like this, to simplify email configurations for common providers. This will rest on top of our smtp / imap objects rather than replace them.
mail_provider:gmaildo |provider|
provider.username="..."provider.password="..."provider.overridesdosmtp.something= ... # a post hook, only used for special casingendend
Ideally, there will be a nice internal API for defining new provider types, so that third party extensions can add their own, and so that it is easy for users to contribute these profiles to Newman itself.
The text was updated successfully, but these errors were encountered:
How about something like this in config/environment:
mail_provider:gmaildousername""password""smtpstarttls_enabled: true,port: 587# only used for special casingimapstarttls_enabled: true,port: 993# they should be there in provider class by defaultendset:simplelist_db,"db/lists/simple_mailing_list.store"set:librelist_db,"db/lists/libre.store"set:ping_email,"<<USERNAME>>+ping@gmail.com"set:live_test_delay,5set:domain,"gmail.com"set:templates_dir,"views"set:default_sender,"<<USERNAME>>@gmail.com"set:polling_interval,10
I don't know what's the different between service and application settings, shouldn't we just call settings and set those setting values by calling set method?
wherever possible, I'd prefer to avoid switching context via instance_eval, so that means I would want to yield a provider object rather than instance_evaling code against one in mail_provider. The difference between service and application is that service exists to tweak configuration settings Newman provides and application exists to provide the user with a way to add their own configuration data to the system which is NOT meant to be used by newman. These two namespaces are significant... Newman will eventually add validations for its own settings and then service will no longer be an openstruct.
set is nice because it looks familiar to sinatra developers, but is a bit too limited for what we're trying to do here. I actually am very happy with the segmented Lua style configs we have now, I just want to make setting email providers a bit easier because it is a common operation.
Something like this, to simplify email configurations for common providers. This will rest on top of our smtp / imap objects rather than replace them.
Ideally, there will be a nice internal API for defining new provider types, so that third party extensions can add their own, and so that it is easy for users to contribute these profiles to Newman itself.
The text was updated successfully, but these errors were encountered: