Remove terminated members

[fjjulien]

Since the logic for organizational members is based on the usual name field, these organization will theoretically continue to be listed in our directory in perpetuity. This is not right. We should be able to trim out members who are no longer in good status.

We created a field for this purpose in the wp_usermeta table to explicitly record membership end dates. The field label is "Member Termination Date (no longer in good standing)" (@dugost can you please confirm the field name and add it to the list of fields to be extracted and loaded to Artsdata?)

The logic will be simple:

1. If the field is empty, the member is in good standing: continue to extract data and to display member profile in the directory.
2. If there's any date value in the field, this means a CAPACOA staff has deemed that the membership status no longer exists: load this particular data point in Artsdata (so that we can eventually push it to Wikidata), and stop displaying the member profile in the directory.

[dugost]

The admin-only field name is MemberTerminationDate and has been added to my repo. I'll hold off on a PR until I get feedback on the following and have had a chance to review other messages.

The issue with using MemberTerminationDate is that it isn't created when a member is added, made clear by the short list from my db search. I created a new member on staging to test out the process. Manually approving an order or updating the profile via Member Account does not add it. Currently, only an edit to the user via the back-end will.

So the onus is on the admin to ensure a new member's user profile is updated when they join. An edit will add the field with a blank meta_value unless a termination date is included. As-is, that field won't be a reliable filtering method unless a default value is passed through the form on account creation.

If you like, I can set a default value to "None" to automatically create and populate the field for all new members. The admin can then add an actual date when applicable. All existing members will need to be updated by the admin, though, or through a query. Note: Any renewal or level change transactions would reset the date to "None" and then a new one can be entered.

The same is easily done for "Member Start Date" and "Lifetime Membership Date". Might be good to always have those added for new members in case we're ever able to populate those automatically down the line.

[fjjulien]

@dugost This may not be a significant problem. Here's why.

Any new member record must be promptly reviewed by a CAPACOA staff to ensure data quality (and to manually record administrative data points such as the member start date and the active year). Typically, the record would be reviewed within 1 or 2 weeks, at which point the MemberTerminationDate would be created. If, during that period, the absence of the MemberTerminationDate field prevented the extraction-transform-load of the data to Artsdata, this delay could actually serve as some kind of quality assurance process (which is arguably a good thing). This is a scenario I would be entirely comfortable with.

If however the absence of the field generates more serious issue on Artsdata's end, then I agree that we should find a solution to automatically create the field. I would however not recommend populating with a default text-based value such as "none". Even though this field is coded as a text field in our database, it is intended to serve an xsd:Date value to Artsdata and other databases. Any text string would trigger constraints violations in Artsdata and in other database such as Wikidata. If a default value is absolutely needed it should be something like 0000 that could be interpreted as a valid date and would not trigger a constraint violation.

[dugost]

@fjjulien Great points. I thought I had an alternate solution but it didn't work out. I could automatically create a blank meta_value post-checkout by hiding the field using other options in its array and including value=''. But that also hid the field from the admin. Very frustrating. So at this time, I'm unable to find a solution that creates the field including a blank meta_value on order creation that's visible in the admin but hidden from the member/checkout.

If this doesn't pose a problem for AD then it will have to be manual population for the time being. If it does, maybe AD's logic can be modified to only exclude a member if exists - meta_key: MemberTerminationDate AND meta_key: YYYY-MM-DD >= current date / else ignore?

[fjjulien]

FYI - We implemented an internal process by which Dessa is forwarded an email notification of anytime a new member record is created. Dessa will be responsible for validating the quality of user-submitted data, and for editing internal admin fields - and when she does, the Member Termination Date field will be created. Dessa should be able to do this within a one-week time frame, which is the same frequency as the ETL into Artsdata.

@saumier : This field will change your extraction logic to determine which data record to ETL. It would be as follows :

1. If the Member Termination Date is inexistant, don't ETL (this means data quality has not been validated yet);
2. If the Member Termination Date exists but is blank, check the terms_conditions field;
3. If terms_conditions is NOT do not agree (v1.0) or do not agree (v1.1), ETL. (see #23)

Then, in your display logic, you should include an additional step that checks the Member Termination Date field:

1. If Member Termination Date is empty, display in the directory;
2. If Member Termination Date has an xsd:Date value that is older than today, exclude from the directory;
3. If Member Termination Date has a value, but it is not a proper xsd:Date, trigger an error in the error report.

[fjjulien]

For priority setting purposes, this issue is not in direct scope for the current iteration. We can deal with it in a subsequent iteration.

[saumier]

@dugost @fjjulien I am blocked until there is some data for the field "Member Termination Date" appearing in the Wordpress Users API. Same need as in #25

[fjjulien]

At present, I don't think we have any member whose status has been determined to be "terminated". I'll ask Chandel if she anticipates to "terminate" members soon or if she will wait at the end of the current membership cycle (in April 2024). More on this soon.

[dugost]

@saumier I think I need some further clarification on the WordPress Users API. In issue #25 the 'description_fr' field wasn't available to the plugin. I suspect this is due to Polylang Pro being required for passing translated versions of default Wordpress fields to the REST API. It makes sense as 'description_fr' is the only default field specifically created for French by Polylang while others like "name", "id" and "website" are universal.

But MemberTerminationDate is generated via PMP just like presenting_format or operating_name1. So if the plugin can pull data for those PMP-generated fields why can't it also do it for "MemberTerminationDate"? Or is the issue that there aren't any members with data in the "Member Termination Date" field in the first place so the display logic can't be tested fully?

[fjjulien]

@dugost @saumier We added termination dates to a member record so you could run some tests:

• Culture Creates (user_id=45)

Please check whether you are able or not to extract this particular data point.

[dugost]

@fjjulien @saumier PR submitted with latest field modifications.

[fjjulien]

I think I might be on something... The PMP admin interface filters members by membership levels, as well as by these other categories: expired, old, cancelled.

• The "All levels" filter currently shows 202 records with an active membership level;
• The "expired" and "old" filters both have 53 items and the lists seem identical - these filter seem to be based on the "Membership Level History" in the PMP admin interface, which includes an expiry date for each membership level entry;
• "Cancelled" is a distinct category, with 4 items - these were manually cancelled by an administrator.

None of these numbers match the current number of records in Artsdata (218), because the extraction process only considers membership levels for the sake of assigning a type. The consequence is that some cancelled members with a properly documented termination date, such as CAPACOA Member 240, are still extracted from the CAPACOA database and displayed in the membership directory.

Now that we are managing all member records in PMP AND we have reinstated the use of expiry dates, could this be the simple solution to the issue of excluding past members from the directory?

We'll have to discuss this option with Chandel to make sure it does not create too big of an administrative burden upon her (some members still manage their membership renewal offline).