Currently I'm using a dynamic Subscription Provider to provide my list of Receivers.
My use case is so that I need to send newsletter on a daily basis. I expect the list of subscriber to be dynamic based on some flag that tells me wether these people already received this email or not.
My first guess was to flag the original object to true once fetched by the provider. On next run I would only fetch other receiver whose flag is false.
As I figured it out, if the email is viewed clicking the online link (link app_plugins/newsletterstudio/pages/rendernewsletter.aspx), the provider is called again, and so is the render tasks.
With this approach, I can't guarantee that the provider would give correct list of Receiver. In this particular case, if anyone clicks on the online link (say the same day), the provider would return no values (as they have all been sent previously and flagged as such); the render task might then fail to insert correct content.
Now my questions:
If the custom data are stored in DB, why is it necessary to fetch the list of subscriber upon online viewing ?
Can you advise the correct way to handle use case described ?
Be sure we have a licence and I expect particular help on this point. Thanks in advance for your help.
So just to make sure that I get your situation right. You have a custom subscription provider that returns a dynamic list of receivers based on some information on the receiver.
When this receiver tries to read the letter online this fails since your logic in the subscription provider does not return this subscriber at that stage?
If this is the correct understanding I see why you're having issues. Your other issue with "read online / custom data" is related to this as the read online-feature uses the Subscription Provider to get the information about the receiver. I'm thinking that it's probably possible and better to use the "real" EmailTrackingItem and not use the mock - but it was years ago this was created so I need to look closer at it.
If the real tracking item is used the subscription provider would not be hit by "read online" and your issue would be fixed right?
If there is still a need to hit the provider at that stage we could add a parameter to the call that indicates that this is a "readonline"-request.
Before a new release there is not really a good way to implement this in a "clean" way. But. Your subscription provider will be called in it's own thread during the send out and HttpContext.Current would most likely be null.
But when the user reads online (app_plugins/newsletterstudio/pages/rendernewsletter.aspx) there is a HttpContext.Current and you can look at the Request-object to figure out if it is a "read online"-call and then ignore your "only one e-mail per day"-logic at that stage.
If you need an urget fix this is your best bet - I will look at this and release a version with fixes but that might take a week or two.
Which way to filter my subscribers ?
Hi,
Currently I'm using a dynamic Subscription Provider to provide my list of Receivers.
My use case is so that I need to send newsletter on a daily basis. I expect the list of subscriber to be dynamic based on some flag that tells me wether these people already received this email or not.
My first guess was to flag the original object to
trueonce fetched by the provider. On next run I would only fetch other receiver whose flag isfalse.As I figured it out, if the email is viewed clicking the online link (link
app_plugins/newsletterstudio/pages/rendernewsletter.aspx), the provider is called again, and so is the render tasks.With this approach, I can't guarantee that the provider would give correct list of Receiver. In this particular case, if anyone clicks on the online link (say the same day), the provider would return no values (as they have all been sent previously and flagged as such); the render task might then fail to insert correct content.
Now my questions:
If the custom data are stored in DB, why is it necessary to fetch the list of subscriber upon online viewing ?
Can you advise the correct way to handle use case described ?
Be sure we have a licence and I expect particular help on this point. Thanks in advance for your help.
Hi!
So just to make sure that I get your situation right. You have a custom subscription provider that returns a dynamic list of receivers based on some information on the receiver.
When this receiver tries to read the letter online this fails since your logic in the subscription provider does not return this subscriber at that stage?
If this is the correct understanding I see why you're having issues. Your other issue with "read online / custom data" is related to this as the read online-feature uses the Subscription Provider to get the information about the receiver. I'm thinking that it's probably possible and better to use the "real" EmailTrackingItem and not use the mock - but it was years ago this was created so I need to look closer at it.
If the real tracking item is used the subscription provider would not be hit by "read online" and your issue would be fixed right?
If there is still a need to hit the provider at that stage we could add a parameter to the call that indicates that this is a "readonline"-request.
Before a new release there is not really a good way to implement this in a "clean" way. But. Your subscription provider will be called in it's own thread during the send out and HttpContext.Current would most likely be null.
But when the user reads online (app_plugins/newsletterstudio/pages/rendernewsletter.aspx) there is a HttpContext.Current and you can look at the Request-object to figure out if it is a "read online"-call and then ignore your "only one e-mail per day"-logic at that stage.
If you need an urget fix this is your best bet - I will look at this and release a version with fixes but that might take a week or two.
Thanks for this return;
Yep your understanding is correct.
What I don't know at that stage is wether the provider might get called for some other reason (despite sendout and online reading) ?
I would take a closer look at the thread checking to see if that helps.
Hi!
I've made hotfix that gets the correct EmailTrackingItem when reading online. My testing shows no issues with this at the moment.
Drop me an email: markus [at sign here] enkelmedia.se and I'll send it to you now for testing.
// m
To be clear - if my fix works for you, you will not have to change your subscription provider.
is working on a reply...