Cache ownership change through OC_TEAM/ADMIN

[andrixnet]

This is a feature request for OC_TEAM/ADMIN ability. That is to be able to reassign cache ownership from one user to another, equivalent to adoption, but performed by an administrative account. Either fully change ownership, or initiating an adoption procedure.

This may be both a useful feature and a controversial one. Hence it should be properly regulated by OC RULES.

Case scenario 1: user account blocked. has active cache. obviously unable to maintain listing. volunteer offers to adopt and maintain cache. Block remains permanent for proper reasons or user does not respond/improve towards unblocking within a reasonable amount of time (ie months, but less then auto-archive rule)

Case scenario 2: user disabled (deleted/data removed). has active cache. obviously unable to maintain listing. volunteer offers to adopt and maintain cache.

Case scenario 3: user no longer active (ie does not respond to communication within a reasonable amount of time (ie months, but less then auto-archive rule) ). has active cache. obviously unable to maintain listing. volunteer offers to adopt and maintain cache.

---

At this time, technically, at server administrative level, one could hypothetically manually perform the necessary database modifications.

Case 1 - possible scenario. Case 2 - new scenario with the new functionality to remove account Case 3 - actual scenario at OCUK ( requested by @Amberel via FB tech support group)

---

IMO there are two major policies that can be applied:

1. won't fix, based on a same as Groundspeak policy to archive unmaintained/unmaintanable caches and publish new listings (even if with identical data)
2. enhanced community collaboration and support for existing caches.

This feature request comes with the latter policy variant in mind.

[rapotek]

IMHO there is only one case when a cache ownership change could be initiated by OC_TEAM/ADMIN. It is the case of an user account removal, when each not archived cache owned by removed user can be adoptable by other users without the user explicit permission, because it is definite that the user removed will not return to the game. But even then this policy should be clearly stated in OC RULES. Every other case requires an owner permission to give up a cache.

[Amberel]

I'm not sure if this will appear as I'm not a regular contributor, but it was probably something I said that initiated this topic.

Every other case requires an owner permission to give up a cache.

A hypothetical situation, but one which might have occuured:

A user has lost all interest in caching and moved on to other things. They never log on, but they responded briefly to an email from admin about their cache. They were perfectly happy for anyone to adopt their caches, but couldn't be bothered to log on and start the procedure themselves. So the admin would be doing it on their behalf.

Rgds, Andy

[rapotek]

I'm not sure if this will appear as I'm not a regular contributor, but it was probably something I said that initiated this topic. Every other case requires an owner permission to give up a cache. A hypothetical situation, but one which might have occuured: A user has lost all interest in caching and moved on to other things. They never log on, but they responded briefly to an email from admin about their cache. They were perfectly happy for anyone to adopt their caches, but couldn't be bothered to log on and start the procedure themselves. So the admin would be doing it on their behalf. Rgds, Andy

If they responded briefly to an email, they can log on as well, or in case of forgotten password, reset this password using this email address. Otherwise it seems to be identical or not far from giving the admin a password to the user account, so the admin can "do it on their behalf".

Looking at the bigger picture: policies described in above scenarios could be implemented, but only when they could be enabled or disabled on the node level. Maybe in OCUK node they would be functioning as they should be, without any abuse or complaints, but there could be flame wars arising from their using in another nodes.

[andrixnet]

In the context described by @Amberel one could argue that the user in question has abandoned the game, and while he/she has responded positively towards the idea of cache adoption, he/she is not willing to have anything to do with geocaching anymore, including going through the hassle of recovering the authentication to the site and performing the adoption steps.

[rapotek]

In the context described by @Amberel one could argue that the user in question has abandoned the game, and while he/she has responded positively towards the idea of cache adoption, he/she is not willing to have anything to do with geocaching anymore, including going through the hassle of recovering the authentication to the site and performing the adoption steps.

I see it, and moreover I agree with giving the admin (or I should write here an OC_TEAM member, because a database admin can do it already) permission to do it when there is no objection from questioned user or anyone else. And I see the purpose: to have more actively maintained geocaches. But I see the danger of giving such a tool without taking into consideration a particular node conditions, too.

[Amberel]

In this case I am hoping that the existing c/o will perform the request, so it wouldn't be an issue this time, it's more of a discussion for the future. And yes, I can see it places a great responsibility n the admin to act correctly.

Incidentally, I am a database admin, but I am very wary of making changes to the database, such as changing the userid asscoated with the cache, without understanding the implications - I don't wish to accidentally break the integrity of the database.

Rgds, Andy

[andrixnet]

I fully agree with @rapotek that this functionality be activated by per-node configuration.