Caches being "Unpublished" instead of Archived

[+Volvo Man]

Ever since the API program came out, I've been having a whale of a time using the rich feature set to make my offline DB so much more useful, and my on the day caching activities much simpler (Thank you so much GC & GSAK)

 

On the flip side of this is that the API has picked up some irregularities with some of the caches I have previously had delivered via PQ.

 

The oddest of these is the "Unpublished" caches that at some time or other in the past have been Published, and Found (in some cases found by me) but for some reason, instead of being archived, they are "De-Published". The API status check of these caches indicates them as Temp Disabled, so they are not picked up by the various things that I do to weed out Archived listings from the list.

 

When I come to do a refresh cache data, via the API, if the anomalous caches are in the list, they cause an error as the response is unrecognized, and I waste a whole bunch of data for that query (a waste both in terms of my API access credits and GC.com's Server bandwidth).

 

An example cache listing is GC1C5QB

 

This all results in the following Questions:

 

1: Why were these caches "De-Published" instead of being archived as normal?

 

2: Does the API Status check response include whether a cache is published or not? if so, I will take this topic to Clyde at GSAK too. If Not, please could it?

 

3: Why does the Status check acknowledge their existence, but the Other API commands do not?

[jholly]

If there is a problem with the cache (permission, proximity, etc) and there are no finds I've seen the cache be retracted, i.e., as if it did not exist. But generally if it has been found it is archived. I would think being retracted would subtract from the finders find count.

 

As for API status check, who knows? Probably if you would wade through the return info from the API you might see some sort of status that is not being dealt with by GSAK, it is after all a very low occurrence error and Clyde would probably need a specific example.

 

It sounds like there is an inconsistency between the API calls on this cache. I probably would post that question in the Website problem forum so it is properly visible.

[+Volvo Man]

I'll cross post for Clyde, but the cache I listed as an example has 7 found it logs on my GSAK DB, and was updated via PQ over a month after it was first published. I've also got a couple of these in my found it count, in one case, it was placed by a user who was subsequently banned. The stats still show for my count, but the cache pages come up unpublished when you click the link.

[+Volvo Man]

A Further Example:

 

GC8D0D - placed by a cacher known to have been banned, found by me, remains on my found count, but not on my public found list

[+The A-Team]

I would think being retracted would subtract from the finders find count.

Nope, just a few months ago I logged a find on a cache, only to see the cache be retracted later in the day. It's still included in my count and in the MyFinds PQ, and you can access my Found It log, but you can't access the cache listing. I just dug into the MyFinds GPX for that cache, and it lists the following:

available="False" archived="False"

So it's neither archived nor active.

I'm really not sure why the reviewer retracted it. It was published in error because it had a proximity problem with a puzzle final, but if people had already found it, I would think archiving would have been the way to go.

[jholly]

I would think being retracted would subtract from the finders find count.

Nope, just a few months ago I logged a find on a cache, only to see the cache be retracted later in the day. It's still included in my count and in the MyFinds PQ, and you can access my Found It log, but you can't access the cache listing. I just dug into the MyFinds GPX for that cache, and it lists the following:

available="False" archived="False"

So it's neither archived nor active.

I'm really not sure why the reviewer retracted it. It was published in error because it had a proximity problem with a puzzle final, but if people had already found it, I would think archiving would have been the way to go.

The log is not available to others. It says you can not see logs of unpublished listings and that user logged something.

[+JL_HSTRE]

I also thought the policy was if something is published accidentally then Finds = Archived & No Finds = Retracted.

 

Would love to hear from a Reviewer whether there is an official policy on this or if it is entirely Reviewer discretion.

Edited May 29, 2012 by Joshism

[+dprovan]

I've run into retracted caches a couple times, and they puzzle me, too. From the examples I know about, caches are retracted like this when it was a "mistake" to publish them to begin with. One in my area had many finds, but it turned out that 80% of the people logging it found on line were actually finding and signing a puzzle final nearby without knowing it. I actually did exactly the same thing myself, despite the fact that I'd found that same puzzle final many months earlier! When I realized what was going on a week or so later, I posted an archive note, but the cache was unpublished, instead.

 

So apparently the response to this kind of oops is to undo the mistake by retracting because -- I'm imagining -- archiving it would be technically more like blessing the mistake and then fixing it. I have to concede that there's a certain logic to that, although it caused some odd things to happen before the API, and now it appears that similar issues have extended into the API area, as well.

[+Volvo Man]

From the checking I've done, and the replies above, I can only conclude that the best thing to do (unless GC are willing to add another field to the Status check (Published=True/False)) is that all "retracted" listings should first be archived. At least that way the Status check won't keep sticking them back into live databases, and they'd be real easy to filter out of Refresh & Get Logs requests.

[+The A-Team]

The log is not available to others. It says you can not see logs of unpublished listings and that user logged something.

Didn't know that. Thanks for letting me know.

[+DanPan]

Another example of an unpublished cache with founds:

 

BB2 - Langs de vaart 5 (Schobbejak)

 

This Eartcache has 5 founds:

 

16/04/2012 [log] Zwuzze

15/04/2012 [log] pasy

15/04/2012 [log] Rikrikkert

15/04/2012 [log] Delangen

15/04/2012 [log] RJ-fire

Edited May 29, 2012 by DanPan

[+DanPan]

It seems that the EarthCache Team is starting re-reviewing existing EarthCaches.

 

If the educational task of the EC has no relation to the specific Earth Science, the EC will be disabled and the CO will be asked to modify his EC. If not the EC will be "unpublished".

 

Over the past weeks many EarthCaches are disabled or "unpublished".

Edited June 3, 2012 by DanPan

[+Volvo Man]

So, it would appear that the "unpublish" method is actually a method of performing a "cover-up" when an error has been made.

 

That's going to be an utter pain weeding out all those covered up earthcaches from my DB, I'll have to check each one manually online

[+palmetto]

There are three caches referenced by GC Codes in this thread,

 

GC8D0D an archived Virtual, not retracted, not an Earthcache

 

GC1C5QB a retracted Traditional, not an Earthcache

 

GC38WWD a retracted Earthcache

 

Just FYI

 

I don't see any trends here, just the normal transactions on this site. I can't follow the Earthcache review notes, so i have no idea why it was retracted rather then archived.

[+Volvo Man]

There are three caches referenced by GC Codes in this thread,

 

GC8D0D an archived Virtual, not retracted, not an Earthcache

 

GC1C5QB a retracted Traditional, not an Earthcache

 

GC38WWD a retracted Earthcache

 

Just FYI

 

I don't see any trends here, just the normal transactions on this site. I can't follow the Earthcache review notes, so i have no idea why it was retracted rather then archived.

 

The thread is about Un-Published caches which have at one time or another been published before becoming "Un-Published" thios plays havoc with refreshing databases via the API as the data GC sends out on an API refresh of them is not valid xml.

 

It's got nothing to do with whether they are Earthcaches or not, merely the dubious practice of UN-Publishing a cache that has been logged in the past, as, according to correct process, the cache should have been archived, not un-published.

 

and, FYI, GC8D0D is an unpublished cache that has previously been logged, but the CO was banned from GC.com for some reason (he no longer shows as banned, but he did several years ago)

[+The A-Team]

Just to be clear, the act of making a cache "unpublished" is retracting. A cache that has undergone this procedure is retracted. See the full list of log types here.

 

@palmetto: When I try to bring up GC8D0D it says it's unpublished, so if it says it's archived on your end, it must have been retracted and then archived (or vice versa).

[jholly]

Just to be clear, the act of making a cache "unpublished" is retracting. A cache that has undergone this procedure is retracted. See the full list of log types here.

 

@palmetto: When I try to bring up GC8D0D it says it's unpublished, so if it says it's archived on your end, it must have been retracted and then archived (or vice versa).

Of course palmetto has the special xray vision glasses that we don't.

[+Volvo Man]

On the Matter of GC8D0D, as it is one that I have logged personally, I can absolutely vouch that it is a retracted cache, What happened was that the cache was archived by a reviewer not long after I found it. The reasons for archiving were the result of the CO setting up an autoreply to all contact via GC.com (one of the ALRs for the cache) which made a somewhat political statement about his view of a change in GC policy at the time.

 

The CO didn't let it stop at the archiving, and began posting rebuttal notes to some of his cache pages that had been archived, but were cross listed and active "elsewhere". this was before the change in the way URLs were formed for cache pages and anyone who knew the GC code for a cache could access and log it regardless of its status. I believe there was some similar goings on on these forums from the CO too, which resulted in him being banned (this was at one time actually shown on his GC profile, as opposed to his forum profile although it doesn't show anymore). Anyway, eventually, and quite rightly, the caches that were being used as soapboxes were retracted, as a cache page is not a discussion forum.

 

At this point, the cache details and a few logs were in my GSAK database as finds, and got transferred over to a separate my finds database. I hadn't ever refreshed the data on that database since the entries, once found, were simply moved over to show the point at which I had found the cache, and I had no further interest in using my PQs to keep logs and details up to date for caches I would never be searching for again. Fast forward to last week and I was using my finds data to test out some changes to a refresh macro to try to stop some intermittent errors I had been experiencing, and I discovered that this cache's unpublished status was what was causing the errors I had been experiencing. I then did a status check, and it changed from available to archived, which cured the issue as my filter ignores archived caches.

 

Having that personal evidence that the cache had once been active, but now was "unpublished" led to the conclusion that this was being used to retract caches. Now, in this case, due to the course of events, the retraction was done the way it really should be, in that it was first archived, then retracted, so it will not hamper the API (albeit this happened by chance long before the API existed) once a status check has been done the cache will forever be ignored by any well formed refresh method ie status first then refresh what's live.

 

In highlighting this issue, discovering the reasons for it and then further examining the possible scenarios, I hope to bring to attention the need to archive a cache before retracting it, as, as can be seen in the case of GC1C5QB, if the cache is not archived before being retracted, anyone who has got that cache in their DB, perhaps for tracking their finds or whatever, will not be able to eliminate it with a status check, as even manually changing it to archived is restored to temp disabled when status checked, but it is impossible to refresh so an error results.

Edited June 4, 2012 by Volvo Man

[+Volvo Man]

Well, I seem to have succeeded in my aim of this thread. I have just tried some API refreshes of the caches mentioned in this thread, and whilst their various statuses have not changed, suddenly the API no longer passes invalid data for them, and simply skips over them as if they didn't exist, thereby not wasting any API credits, and not crashing my refresh halfway through, as was happening a few days ago.

 

Thanks to GC for fixing that bug, much appreciated. BTW, the status check still returns the cache status, I tried manually changing the status in GSAk, then status checking them and it returned them to what they have been showing all along, archived for GC8D0D & Disabled for GC1C5QB

[+The A-Team]

Anyway, eventually, and quite rightly, the caches that were being used as soapboxes were retracted, as a cache page is not a discussion forum.

That was absolutely NOT the right thing to do. That cache listing should have been locked, not retracted. That way the listing is still available to be viewed, but no one can add any logs to it and the CO can't edit it. I've seen listings be locked because they've been used as a forum, the CO is allowing armchair logs, etc. To me, retracting a long-active listing is unacceptable. Retraction should only be used to correct mistakes, such as a mistakenly-published cache (or for reviewers to have fun on April 1 ). As soon as there are any finds on a cache, it should never be retracted, but rather archived.

[+Volvo Man]

Anyway, eventually, and quite rightly, the caches that were being used as soapboxes were retracted, as a cache page is not a discussion forum.

That was absolutely NOT the right thing to do. That cache listing should have been locked, not retracted. That way the listing is still available to be viewed, but no one can add any logs to it and the CO can't edit it. I've seen listings be locked because they've been used as a forum, the CO is allowing armchair logs, etc. To me, retracting a long-active listing is unacceptable. Retraction should only be used to correct mistakes, such as a mistakenly-published cache (or for reviewers to have fun on April 1 ). As soon as there are any finds on a cache, it should never be retracted, but rather archived.

 

Didn't know it was possible for a cache to be locked, as even an archived cache can be logged if you know how (I've been using one of mine for pitstoping my TBs for years). So on that piece of information, I agree, locking would be the right thing to do in this case.

[+The A-Team]

Didn't know it was possible for a cache to be locked...

Yep, here's one that was recently discussed in the forums. Everything is still visible, but nothing can ever change. I think at one point locked listings had "(LOCKED)" appended to the end of the cache name in the browser titlebar, but it doesn't seem to do that anymore. If you attempt to log this cache, it will tell you it's locked.

[+Harry Dolphin]

Just to be clear, the act of making a cache "unpublished" is retracting. A cache that has undergone this procedure is retracted. See the full list of log types here.

 

I have logged finds on two caches that were later retracted. One was in the stone wall of an old building of some historical significance. I guess retraction stopped people from ever looking for it again, and possible causing damage to the ruins.

The other was a very nice puzzle cache, with the final seventy feet from the final of an earlier placed cache. I suspect that the CO may have mislead the reviewer as to the final. I do not understand the reasoning for retracting this one, rather than archiving it.

I know of one other locally that was retracted. Something to do with nesting vultures...

Those are the only three that I know of within 65 miles. If there were more, I'd probably notice when they disappeared (while running GSAK.)

[+dprovan]

Those are the only three that I know of within 65 miles. If there were more, I'd probably notice when they disappeared (while running GSAK.)

I've seen about 5 personally, and I suspect there are a few times as many that I never noticed. But, still, I think it's definitely so few that they aren't a serious issue. That's part of the reason I'm prepared to assume the reviewers are doing it for a perfectly good reason, even if it's not entirely clear to me what that reason is.

 

By the way, retraction isn't a complete deletion, it just returns the listing to the reviewing state, from what I've seen. One cache had several logs including a find and discussion of why it shouldn't have been published. It was retracted, but then later republished after the problems were sorted out. In fact, I'd say all of the caches I've seen retracted could conceivably have been republished. Perhaps it's cleaner to republish a cache that's been retracted instead of archived.

[+Volvo Man]

Those are the only three that I know of within 65 miles. If there were more, I'd probably notice when they disappeared (while running GSAK.)

I've seen about 5 personally, and I suspect there are a few times as many that I never noticed. But, still, I think it's definitely so few that they aren't a serious issue. That's part of the reason I'm prepared to assume the reviewers are doing it for a perfectly good reason, even if it's not entirely clear to me what that reason is.

 

By the way, retraction isn't a complete deletion, it just returns the listing to the reviewing state, from what I've seen. One cache had several logs including a find and discussion of why it shouldn't have been published. It was retracted, but then later republished after the problems were sorted out. In fact, I'd say all of the caches I've seen retracted could conceivably have been republished. Perhaps it's cleaner to republish a cache that's been retracted instead of archived.

 

I don't think anyone here is really arguing about whether retracting a cache is right or wrong per se, although a couple of examples have been given where perhaps more appropriate methods could have been used. What's at issue with these caches, is the "cleanliness" of the retraction. if a cache is found to be inappropriate after publication and finding, no matter whether it should have been allowed in the first place or not, It should be archived. If for some reason, it is also deemed that access to the cache details should be removed from public view, then, and only after it is archived, should it be retracted.

 

If a cache is mistakenly published before it is ready, then, by all means retract it, and await its release shortly, but I know this clogs up the reviewer's work queue if its there too long.

 

The reviewers have told many a hider who takes too long or cannot maintain a cache for too long, that if circumstances change, they are happy to Un-Archive at some point in the future, so its obviously not an issue to archive any cache and resurrect later if need be.

 

It does appear that TPTB have fixed the dodgy data issue which these practices were causing, so the effect on offline databases is limited to the occasional incorrect status that just won't ever update. In the case of caches that have concerns over people trying to find them in places they should never have been hidden, these absolutely should be archived before being retracted. As, should a cacher not notice that the waypoint has not been refreshed for 5 years, (or perhaps even it was retracted 2 weeks ago) they might go looking for it and cause the very damage the retraction was intended to prevent (or worse still personal injury).

 

In the vast majority of cases that have been discussed here, perhaps a more appropriate method would be for the reviewer to archive the cache, and change the co-ords to a nearby location which would not be an issue (such as next to a live cache) and then lock the cache. In the cases of unco-operative or belligerent COs, any inflammatory or otherwise troublesome content could also be removed from the cache page, then at least the find logs would be visible to all for posterity.