ptrader

I thought I remember a plugin/extension that would write a new user registration (or better, a Commerce purchase) to a forum.  Does anyone know of anything that does this?  
The use case is simply that:  I want to write the data from a new purchase to a specified forum.  Why?  To make a non-email record and notification of the event for our records.  
Thanks for any insight on this...

The only option when a package expires seems to be to move the user to their previous group when a package expires.  That's great - except that the "previous group" on a new purchase is...the first group they joined.  Why can't we designate a group to move a user to once their package expires (i.e. Guest, former member, etc.) instead having to only default to the previous group?
Again, this is to automate the system better and save admin time moving people in and out of groups.  It also seems like super simple coding since that code already existings in multiple places.  The system already checks for expiry dates and moves the user somewhere - just let the admin decide in each product/subscription they create where to expire the member to.

The only option when a package expires seems to be to move the user to their previous group when a package expires.  That's great - except that the "previous group" on a new purchase is...the first group they joined.  Why can't we designate a group to move a user to once their package expires (i.e. Guest, former member, etc.) instead having to only default to the previous group?
Again, this is to automate the system better and save admin time moving people in and out of groups.  It also seems like super simple coding since that code already existings in multiple places.  The system already checks for expiry dates and moves the user somewhere - just let the admin decide in each product/subscription they create where to expire the member to.

The only option when a package expires seems to be to move the user to their previous group when a package expires.  That's great - except that the "previous group" on a new purchase is...the first group they joined.  Why can't we designate a group to move a user to once their package expires (i.e. Guest, former member, etc.) instead having to only default to the previous group?
Again, this is to automate the system better and save admin time moving people in and out of groups.  It also seems like super simple coding since that code already existings in multiple places.  The system already checks for expiry dates and moves the user somewhere - just let the admin decide in each product/subscription they create where to expire the member to.

In IPB 3.4.x, there were options on all of the transactions to set an expiration date on the package purchased, regardless of whether or not the package was a recurring one or not.  I used this option to edit the expiration date to ensure IPB expired the user's access on the date entered.  It wasn't perfect, but it was better than manually trying to figure out who to remove from members access and who not to.
In IPB 4.x, that option to edit the expiration doesn't exist if the package itself isn't set for a recurring renewal option.  In my use case, we create one-time packages for workshops/memberships that are for a specific period of time and not offered again.  Since those don't renew, there's no way to expire the package and kick the user off the forums after the workshop is over (except by administrator's manual action) under the current version.
I have long asked for the option to set every package with an expiration date, both a rolling and a hard calendar date.  ESPECIALLY a hard calendar date.  (Because why should I have to go edit them on every transaction if I can set the correct one in the package?)
Use case:
1.  At the package/product create or edit, the option should be Does this product have an expiration date?
2.  If yes, present option to set expiration date.  
     A.  Choose expiration date type:
           - XX days (similar to options shown under recurring package.
           - Date:  MM/DD/YYYY (all products purchased under this package will have the same expiration date.)
3.  If no, continue. Expiry_date is left blank.  
Move this option out of the recurring field, but leave the invoicing options there.
Please, could we get this feature?
Pam Trader
 
 
 
 

In IPB 3.4.x, there were options on all of the transactions to set an expiration date on the package purchased, regardless of whether or not the package was a recurring one or not.  I used this option to edit the expiration date to ensure IPB expired the user's access on the date entered.  It wasn't perfect, but it was better than manually trying to figure out who to remove from members access and who not to.
In IPB 4.x, that option to edit the expiration doesn't exist if the package itself isn't set for a recurring renewal option.  In my use case, we create one-time packages for workshops/memberships that are for a specific period of time and not offered again.  Since those don't renew, there's no way to expire the package and kick the user off the forums after the workshop is over (except by administrator's manual action) under the current version.
I have long asked for the option to set every package with an expiration date, both a rolling and a hard calendar date.  ESPECIALLY a hard calendar date.  (Because why should I have to go edit them on every transaction if I can set the correct one in the package?)
Use case:
1.  At the package/product create or edit, the option should be Does this product have an expiration date?
2.  If yes, present option to set expiration date.  
     A.  Choose expiration date type:
           - XX days (similar to options shown under recurring package.
           - Date:  MM/DD/YYYY (all products purchased under this package will have the same expiration date.)
3.  If no, continue. Expiry_date is left blank.  
Move this option out of the recurring field, but leave the invoicing options there.
Please, could we get this feature?
Pam Trader
 
 
 
 

Brandon,

First, I have EMAIL VALIDATION selected for my system. I use subscriptions extensively. It has been a major headache in my system to get new users to get to the payment screens. After reading your answer above, I learned something new about when they can get automatically logged in. That explains a lot.

However, is the Validation system truly working as advertised? If a user creates an account, he/she can immediately log into the system without any further action. I just tested this numerous times while playing around with one of the features. (What doesn't happen is the automatic login, but the email (or administrators) validation DOES NOT have to happen in order to log in.

Just an observation.

Brandon,

First, I have EMAIL VALIDATION selected for my system. I use subscriptions extensively. It has been a major headache in my system to get new users to get to the payment screens. After reading your answer above, I learned something new about when they can get automatically logged in. That explains a lot.

However, is the Validation system truly working as advertised? If a user creates an account, he/she can immediately log into the system without any further action. I just tested this numerous times while playing around with one of the features. (What doesn't happen is the automatic login, but the email (or administrators) validation DOES NOT have to happen in order to log in.

Just an observation.

I'll be the minority - I don't have any problems with the new UCP. I found it intuitive and easy to find what I was looking for.