Capability to remove all imported meetings simply & easily

[jcookson-infoblox]

Is your feature request related to a problem? Please describe. Not sure if its been requested or not. A capability to remove all imported meetings in a simple manner.

Describe the solution you'd like Case : site data has been imported many times over a long period of time and it is desired amongst the site leadership (the stewards of the site) to ensure the data is current and refreshed. Regular imports are supposed to replace existing info as well as remove info (if option selected), but things could slip through the cracks and get missed (however - the data should still be marked as imported). This so that one could clear out all data marked as 'imported' so that a completely fresh series of uploads could occur, ensuring data quality and timeliness.

Describe alternatives you've considered Alternative would be to output all meetings for site, render the imported ones somehow and then manually remove any unwanted imported ones.

Additional context As sites come to embrace feeds and the attendant data it generates, data quality can and will be affected without a means to clean the slate and refresh the data if needed.

[kiyote33]

I may be missing something here. I've been clearing the slate (or so I thought) by clicking the X in the Last Update column to remove the records associated with a data source, and for those Imported with a CSV I use the "delete all meetings, locations, and groups not from a data source" option. The TSML has been showing no records when I do this, so I assumed all meetings were being dropped from the database. Are we talking about the same thing here?

[jcookson-infoblox]

In every real sense that should cover it, my request comes out of experience. If somehow the data retained its flag that indicated it was imported, but somehow was missed with that option (meaning the data got orphaned). Then this would truly clear everything specifically flagged as imported out.

[tech2serve]

Are you talking about csv input? Or JSON feeds from other sites?

[kiyote33]

So there is history of Post records being orphaned that can't be removed by one of the methods mentioned above. That is a little troubling. I'm assuming that this is known because they can be viewed in the Meetings admin view. If that's the case, why not delete them directly there via the bulk selection and "move to trash" feature? I guess I'm not seeing an issue here. Are you having to edit the Post records directly in mySQL to remove them? I'm sorry, but I guess I need more info on this as I'm struggling to understand this issue.

[jcookson-infoblox]

Hold on a sec. I do QA for living, so I look at these things and see scenarios for covering functionality so that our consumers do not have to feel a particular pain point. Is it possible data can be orphaned in our system, yes. Do I definitively know for sure, vis-a-vi doing it myself, not yet … Am just making the point that as a user of the system, if I want to remove all imported entries, it should be simple and easy – all the heavy lifting should be done behind the scenes. I know, as an AA, I might want to have an understanding of how it works, which can be accomplished with some simple explanative text, but detailed controls over this would be a more advanced feature-set, for a later implementation.

James Cookson Infoblox | Software Engineer II m: 1.253.227.6336<tel:+12532276336> @.**@.> | www.infoblox.comhttp://www.infoblox.com [A picture containing text, clipart Description automatically generated]

From: kiyote33 @.> Reply-To: code4recovery/12-step-meeting-list @.> Date: Tuesday, June 22, 2021 at 6:00 AM To: code4recovery/12-step-meeting-list @.> Cc: James Cookson @.>, Author @.***> Subject: Re: [code4recovery/12-step-meeting-list] Capability to remove all imported meetings simply & easily (#379)

So there is history of Post records being orphaned that can't be removed by one of the methods mentioned above. That is a little troubling. I'm assuming that this is known because they can be viewed in the Meetings admin view. If that's the case, why not delete them directly there via the bulk selection and "move to trash" feature? I guess I'm not seeing an issue here. Are you having to edit the Post records directly in mySQL to remove them? I'm sorry, but I guess I need more info on this as I'm struggling to understand this issue.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/code4recovery/12-step-meeting-list/issues/379*issuecomment-865961571__;Iw!!JYsgTRAg6ZQ!Z14-QzuaXhx4A8Eb0sWe6u34tnzAqZ6sPvqJfLREaeI9eTbXQ4ddlLpGyyxEieFftQ$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AMOLRMF7EOA2O4PJIN3X7I3TUCCPJANCNFSM47B6MTZA__;!!JYsgTRAg6ZQ!Z14-QzuaXhx4A8Eb0sWe6u34tnzAqZ6sPvqJfLREaeI9eTbXQ4ddlLpGyyw62FKdaQ$.

[kiyote33]

Thanks for the feedback James. I think I understand a bit better. I was able to orphan records by crashing the browser after starting the data source import. Even though the Data Source record count showed '0', there was 50 meeting records in the Admin view. I had no problem removing these orphaned records via the two-stage bulk delete feature. I validated success by a visual inspection of the mySql Post table which confirmed the orphaned records were removed. So, I humbly submit that it is easy to remove all imported meeting records within the TSML plug-in, but there must be quite a few use cases that I haven't covered. If you can outline a repeatable test where the data source can't be returned to a pristine condition, it would surely help.

[tech2serve]

Hey James—

I’m still not seeing the actual situation. First, if people are routinely seeing orphaned meeting data, they aren’t complaining to us. It sounds like your “suspecting” there may be orphaned meeting data without actually experiencing it?

Also, I think the standard Wordpress UI provides the method to remove meetings in bulk. In your subject, you’re specifying “imported”. I asked above how you’re importing those meetings, but I didn’t see your response.

I guess I’ll need to spend some time experimenting with this, but it would help if you could share more with me about the specific issue you’re facing with imported meetings?

[jcookson-infoblox]

I import all my meetings via feeds or provided csv’s by others …. So IF data is orphaned, it would only be visible by digging into the db – which do not have access to. As long as the UX piece captures the methods for importing and then utilized the same options (essentially import in reverse) in removing, then it’ll be OK. Again, I test items for a living, and I am seeing possibilities when end-users start an import and something happens to the browser, connection, corrupted-data, viral-data, file-formatted-to-be-csv-that’s-actually-something-else, etc …. As long as we have somewhat robust failure/error capture & recovery (Ironic for a group of drunks), we’ll be good.

Humbly, in service. J

[kiyote33]

This makes more sense to me now. Although I’ve been able to ensure the database is pristine by visual inspection, many users might not be able to do that. I can also see where having the option to choose whether the hierarchical regions/districts terms are replaced or preserved during refresh operations might be advantageous to end users who may be looking at different configuration scenarios. That flexibility is provided when importing by CSV, but when Refreshing via the Data Sources we are stuck with the single inherent delete policy built into the software.

I think it would be relatively minor to tweak the functionality and screen dialog so that the delete policy selected via the radio buttons applies equally to all data imports, regardless of whether the import is from CSV or Data Sources. That way end users who delete a data source would have the same confidence in their operation as someone using the CSV Import.

Does that work for you fellows?

From: James Cookson @.> Sent: Friday, June 25, 2021 11:00 AM To: code4recovery/12-step-meeting-list @.> Cc: kiyote33 @.>; Comment @.> Subject: Re: [code4recovery/12-step-meeting-list] Capability to remove all imported meetings simply & easily (#379)

I import all my meetings via feeds or provided csv’s by others …. So IF data is orphaned, it would only be visible by digging into the db – which do not have access to. As long as the UX piece captures the methods for importing and then utilized the same options (essentially import in reverse) in removing, then it’ll be OK. Again, I test items for a living, and I am seeing possibilities when end-users start an import and something happens to the browser, connection, corrupted-data, viral-data, file-formatted-to-be-csv-that’s-actually-something-else, etc …. As long as we have somewhat robust failure/error capture & recovery (Ironic for a group of drunks), we’ll be good.

Humbly, in service. J

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/code4recovery/12-step-meeting-list/issues/379#issuecomment-868703623 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ANT2UM46646ZGECVPKPOC23TUSY2FANCNFSM47B6MTZA . https://github.com/notifications/beacon/ANT2UM35N2BNJWARHUIITS3TUSY2FA5CNFSM47B6MTZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGPDV3BY.gif

[jcookson-infoblox]

Absolutely, yes. Much appreciated.

[joshreisner]

There is an undocumented way to delete all your TSML content (the nuclear option). You can go to:

https://yoursitename.org/wp-admin/admin-ajax.php?action=tsml_delete

You have to be logged in for this to work.

[kiyote33]

This works for me. While developing the "Data Source Change & Notification" feature I found that the removal of data sources, followed by the removal of CSV Imports also returned the database to a pristine condition. That also can be accomplished by any logged in administrator. So I think this issue can be closed.

[jcookson-infoblox]

many thanks.