BUG: Importing user does not cancel previous levels; Sets enddate as TODAY if importing same level ID as active.

[dparker1005]

Sample CSV: https://gist.github.com/dparker1005/bc3617df25b56d873618ff45715574bf

To recreate bug:

1. Run Import Users using that csv 2.Check the user's profile. Everything should have set correctly, including the membership's expiration date
2. Run Import Users again after checking the update user checkbox
3. Check the user's profile. Their membership expiration date appears to be the same as the current date

[kimcoleman]

Users often perform multiple imports of duplicate data, often when they are testing the format, or adjusting the settings in their import.

In this case, importing the exact same data twice results in multiple rows of active memberships in the pmpro_memberships_users table. It does update the 'previous' row to have enddate of "today", but doesn't set the row's membership status to inactive. It inserts new rows with active membership for each duplicate import.

[ideadude]

Additionally, importing users multiple times can lead to "old orders" being found while the pmpro_changeMembershipLevel function is called, which will lead to the gateway subscriptions for those orders being cancelled.

We should consider adding this every time we import:

add_filter( 'pmpro_cancel_previous_subscriptions', '__return_false' );

Or adding an option to the import screen RE whether or not to cancel gateway subscriptions when importing. I lean toward always doing it, because I can't really think of a case where you'd want an import to cancel subscriptions (although some people do try to use the import tool as a mass update tool) and can think of many cases where users would accidentally cancel subs or be confused.

Another option here is to use the "pmpro_other_order_ids_to_cancel" filter and somehow check if the order ids found have the same subscription id as the row currently being imported and if so, exclude it from the list being cancelled.

[andrewlimaza]

This has been fixed in a newer release and here's the PR for @ideadude last comment. Always have it set to return_false unless you actively set a filter to bypass this code from running in the IUCSV specific code only.