Como

Ah. Is this what I should be looking at? Assuming it is, I still might have some questions. :)

v5 Cloud Hi all, I wish to add an item to the mobile footer (not the 'Menu' option contained within), to be located between 'Search' and 'Menu'. I thought the Menu Manager would let me do this, but of course it does not (I can only add items within 'Menu', not the level up from there). Can anyone clue me in to how I would achieve this given that there is no longer access to templates? Please keep in mind that I am not a coder. Thanks.

Hi, I've asked a couple of times via the ticket, but the question seems to have been missed. Can anyone tell me if upgrades/downgrades occurring during an active subscription results in (or should result in) the setting of new expiration date for the full subscription period or is the old expiration date retained? AND, the same question for an upgrade/downgrade occurring during the grade period: original renewal date or a new one? Thanks.

Never, to my recollection. Unless that was an instruction from Invision some months ago. I recall something about it, but do not recall the specifics.

I am not sure I've ever noticed badges in members profile since I disabled them early on after switching to Invision (18+ months ago). Some months ago, the badges were missing and you had to reload them. I seem to remember something about them being recalculated (or I noticed), and I then forgot about it. I was investigating badges back then, but then become busy with real world stuff. Yeah. I had already noticed that. Thanks anyway.

Hi @Jim M. They do not show in their profile.

Yes. You'll need to use an admin account. Standard subscriptions system. Except for the price, all subscriptions have similar terms (two days).

I am testing what happens with refunds (as credits) when a plan is upgraded. For testing, all plans last for two days with pro rata refunds/credits. I just upgraded from a $5 plan (due to expire tomorrow) to a $10 plan. I was charged $7.50. My initial reaction was that this makes sense: A $2.50 credit from the lower plan, taken off the $10 plan. However, the renewal date has not changed - it is still tomorrow. So I upgraded again. The new plan is $25, and again its renewal period is 2 days. This time, I was refunded/credited $5 towards the $25 plan and charged $20. This, again, would make sense, except the new plan is still slated to renew tomorrow (not in 2 day's time). Using the second upgrade example: If the expected behaviour is that the renewal date is unchanged with upgrades, then the new plan initial payment should be calculated as: (0.5 x $25) - (0.5 x $10) = $12.50 - $5 = $7.50 Whereas, if the plan starts over, with a new expiration date, then the initial payment should be: (1 x $25) - (0.5 x $10) = $25 - $5 = $20 In the first calculation, the total is incorrect. In the second, the expiration date is incorrect. If I cannot explain this to myself, I cannot explain it to members. Hopefully I am just missing something here.

I should add, badges do display in the ACP for each member.

Hi all, I do not really understand the attraction of badges, but I wish to play around with the system to see what I might do with it. Apart from the preinstalled badges, I've added another for testing. None of them are visible and I do not know what. I just manually awarded the new test badge to an account, and it does not show either. And yes, I have it enabled in Members => Achievements => Settings. Any ideas? I should add, all my badges were missing a while back Invision had to reinstall them. A related issue, perhaps?

Hi @Marc This is for Subscriptions, not a store product. Unless I am mistaken, 'Client area settings' exists only for products, there is no option to prevent the member from paying early in Subscriptions. But what I am suggesting is for members to not be allowed to generate credits in the first place. Allowing for the buildup of credit and subsequent withdrawal adds potential complications and refund fees. It seems unnecessary to allow this, but it is forced upon me (unless I am missing something).

I am trying to make sense of the Subscriptions system. I think it might be improved and simplified. Early PaymentsWhat is the thinking which allows members to pay their subscription early? I suggest that if their card details are on file, and the payment fails, they would enter a grace period where they would be invited to pay manually. At the end of the grace period, another attempt should be made for payment with the card on file. And if this fails, subscription services are then suspended/removed. (All automated, of course.) I can see the advantage of allowing early payments at a site like Invision, where non-payment (and suspension of services) impacts more than a single individual - none of us would wish to see our websites go offline because of payment glitch of some kind. So having the option to pay early makes sense. But in most cases, allowing early payments only adds potential confusion and complexity. CreditsIn testing, I allow for upgrades and downgrades, with pro rata refunds applied as account credits. But for credits to be applied to the account, I must also allow the member the option to manually add credits to their account. I think this is totally unnecessary in most situations. Yes, to account credits for refunds arising out of downgrades, but I fail to see the advantage of members being able to load up their account with credits they cannot have refunded (if they decide to leave; they are banned; I stop providing the product; etc.). Yes, I could potentially manually refund their card in such situations and/or provide in the ToS that no refunds of credits are possible in these situations, but I'd prefer to avoid this potential situation altogether. Default Payment MethodWhen a member pays early, they are presented with the option to pay using account credits, but the default is to pay by card. I note that if they do not pay early, and there is an automated payment, this will first use account credits and only use the card on file if there are insufficient credits. This is the correct way of doing this of course. But the default option being to use the card on file rather than account credits when paying early does not make sense to me and is contrary to the action taken during an automated payment. And I think it worth adding that option to instead use account credits during manual payment by the member is easily missed - I missed it during testing. In SummaryI think for most usual cases, Subscriptions could be simplified. No manual early payments; and no ability for members to manually add account credits. If these changes are made (or provided as admin options), the default payment method for prepayment not being account credit becomes somewhat moot (though, still applicable where/if pre-payment is still allowed).

Hi @Marc. Thank you for the reply. If you would lock the duplicate thread and re-title this to 'Unsubscribing to Bulk Email (and Notifications) via Email 'Unsubscribe' Link', it would be appreciated. That's message is shown at the time of unsubscribing - yes? So, it is a one time offer? Or can they resubscribe to email later? It does not inform them of the full consequences of unsubscribing or that it is irreversible if they do not resubscribe at the particular time, or that they will not be able to rest their password. That's as I expected. It is understandable and reasonable. Invision must protect the mail server from these types of eventualities. I did test this. The blocked moderator did not receive email when she attempted to reset her password. I'll test this further, but from you have written there, it seems the cause for her not receiving the password reset email has other causes. So, resubscribing (after the initial offer to resubscribe immediately after clicking unsubscribe) is not possible. I think a way for members to resubscribe would be good to have (even if password reset email are unaffected by this - I will test this for myself). Thanks, @Marc. Beat me to it. Thanks again, @Marc Seems that I have lost my post which should have gone under the original title of this thread. Urgh.

@Randy Calvert Oops. Yeah, posted this in error. I had several things on the go, was tired, being constantly interrupted, and I am a bit of a doofus. 🙃 I'll have to go through my posts to see what I did. ☹️

CLOUD Customer Hi, I recently had a problem with two members of our team who unsubscribed to notifications via the 'Unsubscribe' link in their email. They did not realise - frankly, neither did I - that this is an irreversible process. They used it as a quick fix to receiving too many notifications. But there is no option to resubscribe to email notifications and neither can I re-enable this for them. Fortunately, Invision resolved this for me and without any fuss. However, I have a sizeable number of members showing up in the Email Undeliverable list, and for most of them I cannot reverse this (I have not previously removed them from the list). Presumably, most/all of them used the email unsubscribe option which removes the option for me to remove them from the email undeliverable list. But how many of them did this not realising the consequences is more of an unknown. I suspect many of them. But is it worse than this. When a member unsubscribes via the email link, they also PERMANENTLY unsubscribe from receiving newsletters and all notifications. Worse still - and more critically - they can no longer use the Forgot Password function. A few questions: Is this expected behaviour? Is this optimal behaviour? Is this somewhat forced upon Invision because of the shared email server environment? Is this because it is simpler to apply? (I am not suggesting that 'for the sake of simplicity' is never justifiable.) Unless there are overriding reasons for this behaviour of which I am not fully aware, I think this action should be reversible by at least the member (if not forum admins). And I am particularly concerned about the member being unable to request a password reset email. I can think of an edge case which might be the reason for including password resets in email unsubscribe: if someone else attempts to login to the account, they could trigger a password reset email. That would be legitimate reason, and could be exploited to cause problems for Invision. In which case I suggest that if a member who has unsubscribed (via the email link) wishes to request a password reset, they are instead prompted to email the site owner or an admin from the email address associated with their account to request a password reset. Some method would need to be developed to then enable this. So, unless I am missing something, I'd like to see two things: The ability of members to reverse blanket unsubscribe via their user account. It should include a warning and the action logged (for Invision''s benefit). A method developed to ensure that the block on password reset email might be circumvented by the member so that they are not permanently locked out of their account. It is not obvious that unsubscribing via the email link disables the ability to request a password reset.

Ah. OK. I think I must have forgotten to save the change in my testing. I just tried again (and after saving) and the following appears: Would you like the changes you have made to be applied all existing purchases, or just to new purchases? With the options: Update Existing Purchases | Apply to New Purchases Only I suppose that answers my question. Though, I've just noticed a bug with it. I back-clicked to check something without choosing an option, and it had saved the change. I did not know which option had been chosen, and I cannot tell for certain what happens in all situations from the front end looking at my account subscription. But it seems to indicate that if I fail to choose an option, the new price is not applied to existing subscribers. However, if the plan is already cancelled (but still active as it is within the period already paid), reactivation will be at the new price. That's probably the correct behaviour. But what should not occur is completion of the price change if I have not selected if the change should apply to Existing or just New purchases. If we choose to apply this to existing customers, without a forced update to ToS, this could lead to problems. In any case, unless there are pressing financial reasons to force the change on existing subscribers, it is probably counterproductive to have this apply to existing customers. Even if they are were all contacted (which they are not), many might have been letting the subscription ride - due to laziness, supporting the project, etc. - but a forced price change might persuade them to end their subscription. Anyway. Thanks for the reply @bradl.

Hi, How does the subscription system handle changes to the price of a plan? How are subscribers informed? Will a change automatically charge existing subscribers at the new price? And if so, how might this be justified without a new subscription agreement? Assuming that fee changes do charge existing customers at the new rate and without a new agreement, I suppose the only good alternative would be to prevent new subscriptions to the existing plan, create a new one to replace it, and grandfather-in existing subscribers to the (old) similar plan. Still, this would not allow for increasing the plan fee for existing customers, which may be required at some future point (or if the existing price structure should turn out to not make financial sense). I am just trying to anticipate possible future difficulties. Thoughts?

OK. Thanks, @Marc.

Urgh. I missed that option at the payment page. It defaults to card. I'll see what I can do to highlight the account credit option. Having said that, what's the thinking about it defaulting to card rather than account credit? (Maybe there is something I have not considered.) And is there a way I can default it to account credit? Thanks, @Marc.

You think!? 🤐 Gotta say, the description doesn't help much either. Top up SettingsAllow members to add credit to their account? But your help and patience is appreciated, Jim. Thx. Ah. Just checked - upgrading still does not deduct from the account credit. Is this how it is designed / expected behaviour? Or a bug?

Great! Where is that option? I did search for such an option. Urgh. 😔

Hi Jim. I see the credit amount now - I had missed that (wood/forest for the trees and all that). But there are still no details for any refunds in the account subscription data. Is this usual? If so, it is confusing. Yes, I see that. But as I stated, from the front end view of my account, 'Account Credits' is not listed in the dropdown menu. Neither are credits/refunds listed in my 'Orders'. As an ordinary user, how would I track my subscription credits/refunds? As an Admin, how do I track credits/refunds for an account when (except for the headline figure) they are not recorded and I receive inevitable questions from members? Further, when I upgrade, existing credits are not used. This is surely a bug. (Or part of a larger problem affecting my installation.)

Not sure I follow - typo? If you mean their entry in Commerce => Subscriptions => Subscribers, there are no entries for the account relating to refunds or credit. The same goes for Members = Members => Customer View If I go here: admin/?app=nexus&module=payments&controller=invoices&member= It shows only upgrades, expired, pending and cancelled transactions. The item is checked, but the whole option is greyed out in 'menu item type'. And it does not appear in the dropdown in Subscriptions (front end, my account). 'Show this item to users who can access its content' is selected, but when I select 'I want to choose which groups can see this item', it does not save the option and it reverts to the original option. Well, not really. The ID could be used to confirm my identity here since it is displayed in plain view in my profile URL. It is not vital, but I prefer to keep the separation. My impression is that most Invision clients/members do not advertise their forums/websites here. I'll send you the details in reply to your PM. Thanks.

Hi @Jim M Looking at the client area here, I see there is a 'Account Credit' option in the dropdown menu. I do not have this at my community. I checked it out in the menu manager and the menu option is greyed out. Upon hover, it displays, 'This feature is disabled and so a menu item for it will never show'. I have searched and I cannot find where this might have been disabled. I prefer separation between here and my community. So will not post my ID/useranme in public.

Actually, @Jim M, how do I get the ID/username information to you?