iancassel

On 6/30/2023 at 8:57 AM, Marc Stridgen said:

We are not able to share exactly what is coming in future releases as of yet. However, if its currently present on subscriptions it will still be there. The only thing going is physical items. So sizes of items and shipping.

What if we setup subscriptions as a product (before the subscriptions feature was in IPS)? Is there a way to migrate those to subscriptions, or will there not be any impact?

@Jim M Jim I sent an email to support (our migration thread, we only just moved to your cloud yesterday) almost 2 hours ago, but wasn't getting a response which is why I opened it here.

7 minutes ago, Jim M said:

Various IP addresses are expected depending on region due to the CDN used to deliver our Cloud.

Unfortunately (or rather fortunately), I am not having any issues with access myself. Additionally, that "Not Found" should not be exposed on our Cloud (we have a standard cloud error page). Could I confirm that you are not routing this through CloudFlare (bypass mode is on)?

@Jim M Jim all you have to do to troubleshoot is to change your hosts (linux/Mac: /etc/hosts) and put this in there:
 

forums.microcapclub.com 13.32.27.51

and then flush your DNS, and you to can unfortunately experience what ours users are experiencing. ;-)

@Jim M yes bypass is and has been on:

Just now, nodle said:

Has it had enough time to propagate?

You can check here:

DNS Propagation Checker - Global DNS Testing Tool (whatsmydns.net)

It's been a week, and I did check and emailed IPS, showing some of the CNAME forwards to their DNS is not propagating. The issue is some IPs work and some don't I've discovered some users in the US have luck of the draw and get a defunct one, it certainly pings, but it doesn't load the site. And I just ran into the issue here myself in Europe with the IP I posted above, which just changed again in the last 5 minutes and is working now. 

I've discovered 2 IP addresses that are broken on your round robin DNS:

US: 108.156.91.25

EU: 13.32.27.51

It shouldn't be that hard to trace the issue.

It's happening to me now, IP address for Europe (resolved DNS) changed too: 13.32.27.51

looks like 108.156.91.25 is up now. There might be others still down. By why doesn't the network status page reflect partial outages? 

Looks like the CNAME records I setup resolve different IP addresses (round robin) depending on geo location. Some of these locations our users are getting a "Not Found" in their browser. This IP works: 13.32.27.115 (I'm in Europe) and one of our Admins gets this IP address: 108.156.91.25 (he's in Chicago) and its failing. I had him do a "ipconfig /flushdns" and no dice. Many user complaints now about this. Some have no issues, others, it's completely unreachable. 

11 hours ago, Jim M said:

My first suggestion is to fix or remove POP3 for incoming emails on support in ACP -> Commerce -> Support -> Settings -> Incoming Emails.

Outside of that, please apply the latest patch in ACP -> Support.

 

Didn't work. Disabled POP3 and applied latest patch. It's still generating invoices every 50 minutes for this same user. It's completely taken over all of our invoices pages pushing some our recent customer purchases to the 3rd page now. Can someone please check this and disable whatever rogue process/script/loop is doing this?

2 minutes ago, Marc Stridgen said:

We would need to look further into this for you, however the access details on file appear to be incorrect or missing. Could you please update these details by visiting your client area, selecting the relevant purchase, then clicking "Review/Update Access Information" under the "Stored Access Information" section. 

We look forward to further assisting you. 

 

Hi Marc. Updated SFTP/Admin CP logins. Should work now.

This strange behavior just started. When renewals come up, it's generating an invoice every 50 minutes for customer that doesn't have auto-renew turned on. We're also seeing the system logs filling up with pop3 errors (not sure if this is related)

@Marc Stridgen @Jim M yes, we've been using cloudflare for years, this always worked. Just had another one I had to manually check. Some recent update to Invision broke this. If Cloudflare was blocking something why do 90%-95% of them go through? Disabling Cloudflare is a non-starter as it saved us earlier this year from a DDoS attack. It seems like it's an issue with PayPal recurring payments. It never generates an invoice. PayPal just charges them because of the recurring billing agreement, and the invision suspends their account without checking for payment. I have to manually click the "CHECK" button, and that works, so if Cloudflare was "blocking" something why does the manual thing work? Can't a CRON job fix this please? Or is there an issue with invoices being generated on recurring PayPal payments?

Attached are a BEFORE and AFTER clicking check:

@Jim M @Marc Stridgen We're having this issue now on a regular basis. At least once per week I have to manually force the system to recheck with PayPal. Today we got an interesting one, the payment email from PayPal came in, it was a recurring subscription payment. I had a really hard time finding it on the invision side, I had to look for more details from PayPal because I identified which user it was (different PayPal email address than on our board). There is no invoice issued, last one was Nov 2021, and when I checked the PayPal subscription ID in Invision, there was a "recheck" option and it didn't do anything. I went through all of the steps again and clicked the "check" button once more (this was a button, not the hyperlinked text I clicked the first time) and it finally looks like it worked. How can we fix this going forward, it's causing us a lot of headaches. 

10 hours ago, Jim M said:

Could you please let us know the display name or user ID for this user? (feel free to message me if you do not want this public)

I believe what is happening here is that the PayPal reoccurring payment may have happened, hence the PayPal screenshot but it is not connected or failed to connect to your server. Checking this fully with the member will help fill in some missing info/questions I have.

hmmm, I think I fixed it. Looks like there was a temp connection issue when it checked his renewal, I reset it, waited about 10 minutes and then clicked the “check” button again and it synced and moved him into the subscriber group. Thanks Jim, hopefully if this happens again that will be the simple fix.

We ran into this issue last year too, we have a member that has PayPal auto renewal turned on, we can see the payment processed, the Profile ID matches on the PayPal invoice and the customer data in Invision, it even says next renewal date is September 14, 2023, but its not moving him to the subscriber group or showing that his invoice has processed on the Invision side:

 

Is there an issue with this current version on the latest Invision version? We sent a bulk PM to only 2 groups, and it sent it to everyone. 

We're still having issues. This application stopped most of our notifications from being sent out, and every time we forced it to run background tasks, it kept resending the last Bulk PM. We had to disable it, and then run the background tasks, which finally finished after 10 days. We're running 1.0.6 on the latest IPS 4.6.4 ...we're reluctant to enable this application again as it chewed through our monthly allowance of Mandrill sends and we had to buy more. Can you please confirm a fix. Thanks.

We're running 1.0.9 and unable to install/upgrade/download the latest version. We're on IPS 4.6.x is there an upgrade or can you provide the 1.1.4 version directly so I can install over this very old version? @newbie LAC

We just noticed that messages sent via BulkPM is sending folks to the adminCP when they try to adjust their notifications settings (in the footer of the email) but normal emails (which have the exact same footer BTW) take them to the correct notifications preferences.We just noticed that messages sent via BulkPM is sending folks to the adminCP when they try to adjust their notifications settings (in the footer of the email) but normal emails (which have the exact same footer BTW) take them to the correct notifications preferences.

More details when you click on the link:

Error: Class 'IPS\core\modules\admin\system\notifications' not found (0)
#0 /srv/users/microcapclub/apps/microcapclub/public/forums/system/Dispatcher/Dispatcher.php(109): IPS\Dispatcher\_Admin->init()
#1 /srv/users/microcapclub/apps/microcapclub/public/forums/admin/index.php(14): IPS\_Dispatcher::i()
#2 {main}

We have a subscription product where we occasionally provide coupons. The coupons are intended to reduce the cost of the initial term of a subscription but we don't want them used for renewals or more than once. So, we set "Can be used for renewals of selected products?" to off in the coupon configuration. However, we have found that users can use the coupon again by letting the subscription lapse, creating a new instance of the subscription, and then applying the coupon.

A mechanism to avoid the problem of using a coupon more than once (e.g. renewals) would be to set the "Number of times this coupon can be used by a single member" to 1. However, whenever a coupon is applied to an invoice for our subscription product it is marked as a use even if has never been purchased. We have found that people frequently create an invoice and apply the coupon but don't actually buy. Then they come back a few days later and actually try to buy on a new invoice. Unfortunately, in this situation the coupon can't be applied a second time which results either in support requests to us or people that don't subscribe. So, we set "Number of times this coupon can be used by a single member" to 4 but then have a loophole.

So, to ensure that a coupon is only used for the initial subscription and not renewals we propose that one of the following options be implemented.

OPTION #1: Only consider a coupon “used” once the payment process has completed, then we could simply set the individual uses back to 1 and have it work as designed.

or...OPTION #2: IPS emails them the original invoice with the coupon code applied so they can go back at a later date and pay it.

@Mike John Is it possible for Auto Welcome to provide different messages for different user groups? We have three user groups (registrants, members, and subscribers) and would like to send a different message to each one. For example, is there a way to use conditional text in the editor?

8 minutes ago, newbie LAC said:

Hello,

Find

			$topics = \IPS\forums\Topic::getItemsWithPermission($whereTopics, \null, $limitTopics, 'read', $visibilityt, 0, \null, \true, \false, \false, \false, \null, \false, $joinTags);

change to 

			$topics = \IPS\forums\Topic::getItemsWithPermission($whereTopics, \null, $limitTopics, \null, $visibilityt, 0, \null, \true, \false, \false, \false, \null, \false, $joinTags);

Find

			$posts = \IPS\forums\Topic\Post::getItemsWithPermission($wherePosts, \null, $limitPosts, 'read', $visibilityp);

change to 

			$posts = \IPS\forums\Topic\Post::getItemsWithPermission($wherePosts, \null, $limitPosts, \null, $visibilityp, 0, \null, \true);

 

Thank you for the quick response. Just updated according to your code changes above but it still shows blank for guests. 

EDIT: Nevermind, it took about 5 mins to shows. I guess it was a caching issue. Sorry. Thank you, works great and great support!

On 8/17/2015 at 2:32 PM, newbie LAC said:

Hello,

You can change code

Find

		$topics = \IPS\forums\Topic::getItemsWithPermission($whereTopics, null, $limitTopics);

Change to 

		$topics = \IPS\forums\Topic::getItemsWithPermission($whereTopics, null, $limitTopics, null);

Find 

		$posts = \IPS\forums\Topic\Post::getItemsWithPermission($wherePosts, null, $limitPosts);

Change to 

		$posts = \IPS\forums\Topic\Post::getItemsWithPermission($wherePosts, null, $limitPosts, null);

 

Looks like the code changed in 1.0.9, how do I apply the above in the new version to let guests see topics/posts (titles only) that they don't have permission for?

8 minutes ago, newbie LAC said:

I can't reproduce.

Do you have similar problems with other widgets (Topic Feed, Post Feed)?

If your board is not big you can try this

Ok, I updated the cache for the slow update fix, regarding the topics showing I didn't realize there were 2 places to exclude, topics and posts. Thanks.

On 6/7/2018 at 7:25 AM, newbie LAC said:

Hello,

I only added prefixes. I can't reproduce locally.

Check any inbuilt widget. For example Topic Feed

We were also several versions behind (like a year to two) when we upgraded to the latest version of your plugin. Could that have caused an issue?

Another issue. The plugin is ignoring the forums I'm telling it to exclude in the list. The topics show anyways: