Deleting/Removing members - what to delete and when

[gsf00001]

What is the feature?

This may be similar to #11 but when a Client began to discuss this further, they were informed it was not related to the OP (which it seemed it was). #11 seems to now be included in a future release, but I don't know exactly what is being included. Soooo.... SE Staff - you may merge this, delete it, leave it here, or whatever you feel is best :)

The process of Deleting/Removing should have multiple aspects to it (please add your ideas to this thread). Some of this may already exist, but I'm including to be as complete as possible in the processes. Also not all items are needed in every situation - this is just to start the conversation here:
A) Remove or Delete - Who performs this (User or ADMIN) should be flagged somewhere in ADMINcp
B) ADMIN option to delete immediately or put into pending (like a recycle bin as per great idea by Elshara in another post). My thought is to include: 1) ADMIN settting for User-Delete (delete immediately or pending); 2) ADMIN setting for ADMIN removal (delete immediately or pending or ask each time)
C) What to be deleted - everything or certain things (with options for various content so that if ADMIN desires, certain content may be retained; this could be built upon by 3rd-Party Devs too). There are obviously those instances where everything should probably be deleted (bots), grey areas, and others where there's nothing wrong (depending on legalities) with retaining some info (including creative works if the TOS is written properly - just like of my engagement agreements with Devs - I don't 'own' what they've done (because they don't own it - it's a licensed work) but the license of use immediately transfers to me, etc.).
D) Ability to 'un-delete' (obviously only works if using Pending mode). This allows ADMIN to reinstate if desired.
E) ADMIN created questions/options for User-Deleted (ex. we're sorry to see you go - please tell us why)
F) ADMIN created options for reason the User is being removed
G) Keep email address of deleted Users for future reference (they should obviously be searchable in ADMINcp), as well as E/F info above
H) (if Pending) ability for ADMIN to email User (ex. "hey - sorry to see you go, but here's a special offer...")
I) etc.

Well, that's a starting point for this feature/function. Looking forward to your suggestions/ideas :)

[DonnaScriptTechs]

Hi @gsf00001 ,

Thank you for this thoughtful post. Things like this with many options need to be discussed in the community if you want a lot of feedback and options for an expert to develop a plugin.

Our feature tracker is for one request at a time. This is due to us needing to have our code references for any changes we make. Please see our posting instructions to assist in posting feature requests that we can consider implementing. Any with more than one feature will be closed as we cannot consider them like that.

https://github.com/SocialEngine/phpv4-feature-requests/blob/master/CONTRIBUTING.md
https://github.com/SocialEngine/phpv4-feature-requests/blob/master/README.md

Your request has several requests in it. Please edit it to contain just one item. Other items can be as separate requests. It is possible we would accept each separate item once we check impact on the script load, code, etc.

[gsf00001]

Thanks Donna for the reply.

==> "Our feature tracker is for one request at a time..."

I'm a little confused here. This is one feature request - improving the removal process of a member. There are simply many aspects to consider to one feature (as there are for many/most? FRs). Breaking this out into 8+ separate feature requests doesn't make sense to me, but what do I know :)

As far as an expert developing a Plugin for this - my thinking is that the developer of the software that allows such a core function as adding and deleting a member should be responsible for developing this function (i.e. SE).

[DonnaScriptTechs]

Ok it has several things in it. It's A-F in features. This would be a full plugin. I'll get back to you as soon as we are looking at these but it most likely won't be accepted due to the nature of the request - too many features in it to weigh each one individually for benefit to the maximum of clients with the least negative impacts on the core script.

[gsf00001]

Please go ahead and delete this post then Donna (not being cocky, just being realistic - there's no point in this FR existing if it has to be reduced to components that are meaningless w/o the others).

You know me - I'm not a difficult person :) But to call each of these as separate features is like calling the mixing of eggs, milk, water, cake-mix, and oil 5 separate features to making a cake. If you made each of those into 5 separate FRs, you would never make a cake - you would make a bowl of eggs, another of milk, etc and never have the other incredients to mix together because they may not have even been selected to be 'made'.

Part of the reason it looks like 'features' is because too many FRs are too basic and simply inflexible to handle the needs of an entire community.

I'll add this to the list of future custom development (already spent close to $6000, another $3-4000 has been estimated for future customizations so far that I simply can't afford to do yet).

[DonnaScriptTechs]

I'll keep it open as we will be looking at things as soon as we can.