LiquidFractal

I don't think I'd advocate for automated changes based on what is being brought up, but I wouldn't be opposed to some additional options on the campaigns.
Allow more than one instance of this campaign Automatically cancel this campaign if purchase/subscription is cancelled That first option would have to be implemented very carefully. The reason it behaves the way it does presently, as I recall, is because if you set a campaign to initiate when a user reaches 10 posts or whatever, you definitely wouldn't want the campaign to fire at 10 posts...and 11 posts...and 12 posts...and so on.

Hi @liquidfractal
 
There are currently no settings for these two modes.
One of the uses is to put several spots on the image and link each one to a product. Note that the product image cannot be displayed this way
 
Slideshow mode will be created asap.

 

In that same vein, if the originating "type" (like a purchase) is cancelled, I think it would be reasonable to expect the campaign instance to be cancelled as well.
e.g. Someone buys a product, a campaign fires and queues up an email to be sent 30 days later requesting a product review.   If the customer changes their mind and the purchase is cancelled, we wouldn't want that email to still go out.

I think I've mentioned this before, but since one can add a member to a campaign from the adminCP, it might also be very useful to be able to remove a member from a campaign there as well.

@liquidfractal, I discovered this need as well last night!
I've found that there is a check that asks "Does this campaign ID exist for this member already?".  If its true, then you can't add any more of the same campaign.
I think if we had some extra criteria added to Instances, we could get around this.
For example, maybe we could use the purchase id?
If the campaign ID and purchase ID pair exist for a given member, don't create an Instance.   If the purchase has never had the particular campaign run on it, run it!  This way a member can have multiple instances of the same campaign active,  but associated to the individual purchases.
To get the purchase id, maybe we could capture it when the instance is created via purchase?
We'd use the purchase id as the search criteria instead of the package id, then when actually launching the instance, we could save the purchase id as some variable, then redeclare the package id as the value for that function in order to keep it working the way it normally does (because we still want to only run the campaign only on certain packages).
Just some thoughts!

I have a suggestion regarding members and campaigns.
To use my current case as an example: when member X purchases product Y they are added to a drip campaign for emails for thanks, followup, etc.  However, as EDC currently stands, if X purchases Y again in a few weeks' time (or ever, in fact) they won't receive any more messages because they're already part of the DC for product Y, which is now listed as completed. 
OK, I see a certain logic in this in some cases.  But in my case, I have clients making repeat purchases of hours packages, and they're often buying for others (e.g. their children, who are students) and may not pay a lot of attention to/may forget/may just delete the initial followup emails/messages, which in my case contain a link to the Store and other useful information for repeat purchases.  I would have to go into their adminCP Member profile and manually restart their campaign (which can be time-consuming if you have lots of people making repeat purchases).
I think this could be alleviated by removing a user from a campaign as soon as it's completed.  I realise that, depending on the nature of the product and the campaign associated with it that timelines could get a bit choppy, and that perhaps there isn't a one-size-fits-all solution, but sometimes it makes perfect sense for the campaign to restart with a repeated purchase.
OR.....could this be toggled on a per-campaign basis?  What if one could configure a campaign to automatically restart if it is re-triggered by a member's repeat purchase before it is completed the first time around?
[Or (just spitballing here) if each step could be configured to either execute once or to repeat with repeated triggers?  (Not sure about this last one - it just came into my head while I was typing!)]
I hope this makes sense.  

Hello,
Thank you for developing this application!
We are upgrading from 4.4.10 to 4.6.5.1 soon, and one of the reasons we haven't upgraded yet is our dependence on the no-longer-supported Rules application.
We use it to perform actions both immediately after a purchase is made, as well as some amount of time later.
We can do the "immediately after" stuff via creating our own plugins, but not the "some amount of time later" things.  Its beyond my abilities to create a scheduler for that.
Upon installing (the 4.4.10 version) Email Drip Campaigns, I see a couple of areas for improvement that would really help our use case.
1.   The ability to evaluate the purchase custom fields to see if the campaign should be run or not.  For example, a vehicle's identification number informs a lot of these decisions.   If it is a 2011 Chevrolet Cruze, request some specific information about the transmission.  If it is a 2017 and up vehicle, request some other information.  If the purchase is for some custom widget, send an email to our warehouse staff to specifically package it up.
2.  In addition to the actions of "Send an email" and "Send a personal conversation", we would benefit from "Send a Support Request", where we also associate the purchase to the request.
3.  In lieu of adding a specific action, it would be nice if we could "Run custom php", and basically just use the same code we've always used, but triggered by EDC instead of Rules.
All in all, we are looking forward to replacing Rules with EDC because it fulfills all we ever used Rules for anyway.  We just need it to be able to create support requests, and evaluate custom fields.
Thanks again!

Hey @Marc Stridgen.  Yes, I'm using the most recent IPB version, 4.6.5.1 (complete with recent patch).  I just tried restoring all buttons to the default configuration once again to be on the safe side and the problem persists.  And the Support page shows no files missing.
I'll submit a ticket.  Thanks for all the followup here!

Could I confirm you are on the latest release first of all? Also, check within Support (top right of ACP) to ensure that there is nothing showing up there. Specifically that its not showing files missing. If you're still not seeing any resolve, please submit a ticket and we can take a look to see what is happening

Resetting the default configuration was done through the ACP? (we sometimes have people applying CKEditor files to the file system which will cause issues so wanted to clarify)
Are you receiving any errors in your browser console?

Just wondering if Invision should include the ability for developers to notify purchasers/subscribers that app/plugin X is "now UNSUPPORTED" or "support will expire at date X" as per this comment?
This could be a real help for those of us who want to leave unsupported apps behind and plan for the future of their sites.

Just wondering if Invision should include the ability for developers to notify purchasers/subscribers that app/plugin X is "now UNSUPPORTED" or "support will expire at date X" as per this comment?
This could be a real help for those of us who want to leave unsupported apps behind and plan for the future of their sites.

That would be interesting for both dev and client. 

Ahh, OK.  I'm not sure if you've done this already, but it might help if you listed them as "unsupported" so that people like me can look at deleting them and looking for alternatives.  I know you have a huge list of stuff to update with every cycle, but it saves people asking you all the time too!
Come to think of it, I wonder if it wouldn't be a good idea to have a developer notification sent out to purchasers telling them that "App X will lose support after time X," like an EOL notice or something.  Lets people plan for the future of their site.

Sorry, just seen that I didn't mark this one as IPS 4.6 compatible - I'll get to testing it over the weekend.

Please, please, point them at this discussion and request that they actually read it - because the moment you mention this application, they will switch to "3rd party issue" mode.

Take a look at our pages app
https://invisioncommunity.com/features/publishing/?ct=1629284291

@Adriano Faria When I activate this app I get:
ParseError: syntax error, unexpected '[', expecting identifier (T_STRING) or variable (T_VARIABLE) or '{' or '$' (0) #0 [internal function]: IPS\IPS::autoloader() #1 [internal function]: spl_autoload_call() #2 /home/site/public_html/system/Task/Task.php(718): class_exists() #3 /home/site/public_html/system/Task/Task.php(198): IPS\_Task::constructFromData() #4 /home/site/public_html/applications/core/interface/task/task.php(56): IPS\_Task::queued() #5 {main} BACKTRACE
 
#0 /home/site/public_html/init.php(1004): IPS\_Log::log() #1 [internal function]: IPS\IPS::exceptionHandler() #2 {main}  

Uploading a new version now that should address the concern.

Hey @rebraf,
A bug in EDC which needs remedying:
I am trying to set up a drip campaign which begins when a member purchases a product or a selection of products.  All well and good - however, I find that when I check the Product Purchased option and access the Products drop-down menu, the list includes every single product I've ever created in Commerce, whether they're current or deleted years ago - including tests from a couple of years back and custom invoices I created for individual clients!  So obviously this list needs to reflect current products only.
Thanks!

I suggest that those members clear their browser cache on their device. I use Firefox on all my devices and do not have issues, so it could be a cache issue maybe?

That's a tricky one.
The frequency is stored as a string ( e.g. P0Y0M0DT1H0M0S ) so it's not going to work by the default MySQL sort.
I have filled a bug report for this.

Disable at a group level - change the permissions for accessing the module:

Disable at the user level:

Of course....but I'm not the one who (ideally) tests its different functions under different circumstances.  That's why the dev is a dev!  And even then the app doesn't cause any issues...until it does.  But at least the dev has used their expertise to give it trial runs and catch anything which mainstream users may not think to try.

Submitted app to include 4.6 compatibility, waiting on approval now! 😛 
 
 
Not yet sorry, it's been a busy summer for me. It should be ready in september normally when I have some more time