Hi!

At the moment we don't have a really good extention model for this. There is a new version comming in about a week that will include the infrastrucutre to handle additional information but the current release would require you to use a render task to fetch the data.

If you make changes to the views you will probably end up with some problems when you try to upgrade as well.

The safest way at the moment would be to use a custom subscription provider and custom render tasks and then replace the mailing list-node with your custom stuff.

// m 

New version 2.1.0 is out but is there any help/tutorial how to use the new feature "Custom Fields on a subscriber" ?

Hi Markus

I have been testing the Custom Subscription Provider and managed to add successfully which shows up only when Sending; currently it returns 3 targets (couldnt figure out how to show the count next to each custom list yet) 

For end-users it would be crucial to see these custom lists in the main Mailing Lists page, even its read-only. Because as of now, when users click on Mailing Lists they only see the Default list which is shipped, and no knowledge of the Custom generated lists until they click Send Options and Send.

Would adding the Custom Lists under Mailing Lists listing would be a feature that we can expect soon?

Hi!

Yes, there will be a tutorial and better documentation but I cant give you an exact date. Its not that hard. Just add a key and value to the CustomData-collection in the Subscriber provider and then include that value in the newsletter using this placeholder: [#nameOfKey]

Reg. your other question. The mailing list-tree of Newsletter Studio only shows the mailing lists created inside the package. Since a end user cant change the content of a custom list we decided to only show the list as an option when you send. Could you explain more on why its crucial for you to see it in the mailing list tree?

This is the first time someone is asking about this so we don't have any plans on if and when this would be included.

Hi!

This thing has two parts that I'll try to handle separate in my answer.

Data structure and API

So Newsletter Studio has a concept of “Subscription providers” that basically is a connection between the send out engine and a source of subscribers/receivers. We ship Newsletter Studio with one provider for the Umbraco members and another provider for our own storage that we call “Mailing lists” - this is the lists that you can handle in the Newsletter Studio-section in the backoffice UI.

The subscription providers will hand over a collection of Receivers (NewsletterStudio.Bll.Providers.Receiver) to the send out engine during a send out and this class has property with a collection of objects called Data.

So the provider that is implemented for Umbraco members will loop over all generic properties for a member and add one item (key, value) per generic property. The provider that is connected to Newsletter Studios built in mailing lists does not support these custom properties at the moment.

You can build your own views for handeling the mailing lists and then use your custom mailing lists in Newsletter Studio by creating a “Subscription Provider” that talks to your custom mailing lists collection.

UI in the backoffice

The current version of Newsletter Studio can’t handle custom properties for the Mailing Lists in the Newsletter Studio-section. We have an idea of making this possible in the future but we haven’t spent a lot of time in this area of development as the feature is at the moment not something that we see a lot of demand for.

Solution

If you really need this I would use the implementation that we have for the Members-section and then add “salutation” as a generic property for the member type that you are using.

Or if you really need to have it in the UI – building a custom Mailing Lists-section would be another solution.

Hi!

Sounds like a good idea!

The analytics will work great with any data source - the core of Newsletter Studio is using subscription providers as well.

When you implement your provider you'll have two methods that are used to unsubscribe.

Its:

bool Unsubscribe(string email) - Used to unsubscribe from ALL lists bool Unsubscribe(string email, string listItemId) - Used to unsubscribe from one perticular list.

Sometimes a provider only contains one list - then just can just use the same logic in both methods.

This is how the built in subscription provider for the built in mailing lists looks:

     public override bool Unsubscribe(string email)
    {
        int unsubscribeCount = 0;
        foreach (var item in _subscriberRepository.GetSubscribersByEmail(email))
        {
                item.Status = SubscriberStatus.Unsubscribed;
                if (_subscriberRepository.Save(item) > 0)
                    unsubscribeCount++;
        }

        return unsubscribeCount > 0;
    }

    public override bool Unsubscribe(string email, string listItemId)
    {
        // Try to find in subscriptions
        int unsubscribeCount = 0;
        foreach (var item in _subscriberRepository.GetSubscribersByEmail(email))
        {
            if (item.SubscriptionId == Convert.ToInt32(listItemId))
            { 
                item.Status = SubscriberStatus.Unsubscribed;
                if (_subscriberRepository.Save(item) > 0)
                    unsubscribeCount++;
            }
        }

        return unsubscribeCount > 0;
    }

is working on a reply...