Bug with new cache submission wizard

[+Beach_hut]

Don't know if this the right place to report, but I've tried out the new cache listing, and I encountered a few bugs...

 

I was writing out an unknown type listing, and at the stage where the wizard asked me for the final co-ords, the default was 'visible', and on an iPad as I was, it wouldn't let me edit this.

 

At the stage where the wizard asked me the date the cache was placed, it wouldn't take today's date as an answer, even though it was the default. I presume that as our site preferences are for date formats in dd/mm/yyyy, (i.e. 13/05/2014, which was exactly how it displayed on the wizard page for me) the wizard was looking for a date format in mm/dd/yyyy? In order to progress, I had to set the date as 01/05/2014, which is a valid date in both formats.

 

So in both cases the workaround was to input something wrongly on purpose then edit the cache page once it had fully generated, which is liveable with but not ideal.

[+Radnor]

Thanks for the bug reports!

 

A Mystery Cache type's final cache stage visibility is locked to be "Visible" until you choose to add another stage.

 

The date validation bug is indeed a problem - we will fix this ASAP!

[+JPreto]

I have a problem with format of the hints field.

 

Previously it would "understand" ENTER and now it doesn´t. If I use the code <br /> solves the problem but the code in the hints vanishes every time so, if I edit anything on the cache the <br /> goes away and the format of the hint is wrong again.

[Moun10Bike]

I don't believe we've supported formatting in the hint field for several years. Way back when you could put all sorts of HTML in, but that's been a while.

[+JPreto]

I don't believe we've supported formatting in the hint field for several years. Way back when you could put all sorts of HTML in, but that's been a while.

 

Yesterday in the hint with this:

 

[PT] Magnético, não é um nano!
[EN] Magnetic, not a nano!

 

Showed like it is... today after submission shows like:

 

[PT] Magnético, não é um nano![EN] Magnetic, not a nano!

 

If I use:

 

[PT] Magnético, não é um nano! <br />
[EN] Magnetic, not a nano!

 

solves the problem but everytime I edit the cache it goes back to:

 

[PT] Magnético, não é um nano![EN] Magnetic, not a nano!

[Moun10Bike]

Hmmm, okay - I will let the team know that there has been a change with line returns in the hint field. Thanks!

[+JPreto]

Hmmm, okay - I will let the team know that there has been a change with line returns in the hint field. Thanks!

 

By the way, the same think happens in the Profile Edit page with

it can interpret when you use it (I use it for tabs) but then, every time you edit the profile page you have to do it again...

 

This also happened before today... It´s just something I had noticed before but never told.

[+JPreto]

I don't believe we've supported formatting in the hint field for several years. Way back when you could put all sorts of HTML in, but that's been a while.

 

Yesterday in the hint with this:

 

[PT] Magnético, não é um nano!
[EN] Magnetic, not a nano!

 

Showed like it is... today after submission shows like:

 

[PT] Magnético, não é um nano![EN] Magnetic, not a nano!

 

....

 

It is corrected now! Thanks!

[+KRON family]

I see if we are editing listing of multi-cache first time in new form, we must choose stage type. This is a mistake, or the system can not detect it from waypoints?

In other words - should the owners of all multicaches now edit their listings and choose stage type?

By the way, the map at that moment shows the sea. After submit already not.

Screen: http://img.kx.cz/images/4km60ujigmggqu52buva.png

 

EDIT: Yes, http://support.Groundspeak.com/index.php?pg=kb.page&id=72.

Edited May 14, 2014 by Tiskar94

[+Skippy and Pingu]

Last night I used the new cache submission form. I used the drop down calender to select the date of placement. It autofilled the field using dd/mm/yyy format (my default on geocaching.com). When I clicked continue it said my date was not valid (13/05/14). I tried using the drop down calender again and I still had the same problem. I eventually thought I would swap the dd and mm round manually so put it in the format mm/dd/yyyy (05/13/14). This was accepted. It doesn't tell you what format the date needs to be in and more to the point its autofilling it wrongly. Had the dd been 12 or less I wouldn't have known of the problem and it would have put the cache being placed in totally the wrong day and month.

[+Gamboy]

Same here with the date format bug. We had two different behaviours:

• with the default date => complaint about the format
  
• with day before yesterday => complaint about the selection being out of range
  

 

In any case, we were not able to go past that stage and get a listing started.

[cezanne]

A Mystery Cache type's final cache stage visibility is locked to be "Visible" until you choose to add another stage.

 

Why? This does not seem to make sense and is confusing. Why should mystery caches be treated differently than multi caches with respect to the final?

 

Moreover, I wonder whether it could happen that in this manner someone not authorized could get to see my mystery coordinates within the time period I need to add a further point and to change the visibility type. This change also increases the danger that cache owners will forget to change the visibility type of the final coordinates for mystery finals.

Edited May 14, 2014 by cezanne

[+Traditional Bill]

A Mystery Cache type's final cache stage visibility is locked to be "Visible" until you choose to add another stage.

 

Why? This does not seem to make sense and is confusing. Why should mystery caches be treated differently than multi caches with respect to the final?

 

Moreover, I wonder whether it could happen that in this manner someone not authorized could get to see my mystery coordinates within the time period I need to add a further point and to change the visibility type. This change also increases the danger that cache owners will forget to change the visibility type of the final coordinates for mystery finals.

 

If I'm not mistaken, most recently I've been told that for both mystery and Multi caches, you need to now list the "posted" coordinates as a reference waypoint as well. If that's true, than it would make sense that the first waypoint be set to visible by default so that the (unnecessary) reference waypoint for the posted coordinates can be seen. I haven't tinkered with the new submission process yet, but I can imagine after getting over that initial hurdle, all of the following waypoints are likely hidden by default.

[+Noach!]

I try to make a multi cache, but at the end of the proces (after the reviewer note) I get this:

 

"Validation failed for one or more entities. See 'EntityValidationErrors' property for more details."

 

What can I do to solve it and to get my cache published?

[cezanne]

If I'm not mistaken, most recently I've been told that for both mystery and Multi caches, you need to now list the "posted" coordinates as a reference waypoint as well.

 

I have done so since quite a while even in the old system by adding an additional waypoint with the same coordinates as the header coordinates in order to classify whether or nor something is hidden there. As far as I know the local reviewers even required this approach as the proportion of mysteries and multi caches is relatively high, but most of them nothing is hidden at the header coordinates.

 

Note that in the new system mysteries and multi caches are treated differently. For the final coordinates of multi caches right from the beginning all visibility options are available which

is not the case for mysteries. That's not logical and inconsistent and I do not feel comfortable to provide the final coordinates as visible even if I can change it later.

Note that I talk about the final coordinates and not the header coordinates of a mystery cache.

 

I indeed noted however that the new system for an unknown reason also treats old mysteries and old multi caches differently.

For all my old multi caches the system had classified my header coordinates in the new system as virtual (which was true anyway) while for all my mystery caches except one (a special case) the header coordinates in the new system were not classified at all and I had to edit all of them to turn the type to virtual.

 

If that's true, than it would make sense that the first waypoint be set to visible by default so that the (unnecessary) reference waypoint for the posted coordinates can be seen. I haven't tinkered with the new submission process yet, but I can imagine after getting over that initial hurdle, all of the following waypoints are likely hidden by default.

 

I do not agree. See my explanation above.

 

 

Cezanne

Edited May 14, 2014 by cezanne

[Moun10Bike]

I try to make a multi cache, but at the end of the proces (after the reviewer note) I get this:

 

"Validation failed for one or more entities. See 'EntityValidationErrors' property for more details."

 

What can I do to solve it and to get my cache published?

 

It appears that the system is taking too long to validate all of the stages in your 24-stage multi. I have notified the dev team and they are investigating ways to improve the performance on this page. As a work-around, you might want to submit what you can using the new form and leave the cache disabled, then add the needed additional stages via the waypoints tool on the cache page.

[BlueRajah]

A Mystery Cache type's final cache stage visibility is locked to be "Visible" until you choose to add another stage.

 

Why? This does not seem to make sense and is confusing. Why should mystery caches be treated differently than multi caches with respect to the final?

 

I would say a there are puzzles without another waypoint. They will always be at the location, (challenges). So if you choose to not enter anything it will be at the puzzle location and visible.

 

A multi will never be at the location (as far as I can think of) so you must enter another waypoint. The start location may be virtual or not.

 

Thats just off the top of my head, and it may not be what you are thinking, or describing.

[+baer2006]

The only feasible way to create a Mystery or Multi cache with the new form seems to be to accept anything the "wizard" suggests, get a more or less blank listing, and add/edit everything (incl. header coordinates, all(!) waypoints, etc.) afterwards in the still usable "Edit" form.

 

I don't think, this is an improvement .

[cezanne]

I would say a there are puzzles without another waypoint. They will always be at the location, (challenges). So if you choose to not enter anything it will be at the puzzle location and visible.

 

It's true that there are mystery caches with no other waypoint, but still it is a very weird way to lock the status of the final waypoint to visible

and to make the majority of mystery cache submissions more involved.

 

It would make much more sense to provide an error message in the submission process if only a single waypoint is provided and it is not visible.

 

I still do not understand why the system does not distinguish between header coordinates and final coordinates for a mystery cache.

They still could point to the same point. Then the header coordinates could have the visible status by default and the final coordinates could be whatever

and it would not cause any issues to the majority of mystery caches (in my country about 1 out of 200 mysteries is at the posted coordinates).

 

To me the whole new process for mystery caches is confusing as the form by default only asks for final coordinates and does not even mention header coordinates.

While for multi caches the form by default asks for the header coordinates and the final right from the beginning. Of course, additional waypoints can be added in both cases.

 

I do not understand why the form does not ask for header coordinates for mysteries right from the beginning. If it would, then the status of those could be turned to visible (as it is

done for multi caches as well) and all visibility types could be provided for the final coordinates. It would not cause a problem if the final waypoint of a challenge at the

posted coordinates had status "hidden" as the header coordinates waypoint (identical) would have the status visible anyway.

 

 

Cezanne

[+Ruddles1325]

Tried submitting a new multicache today. To be honest I like the way it displays the waypoints on the map - very nice. However I got all the way to the end, and was about to submit, when I realised I needed to change something in the waypoints. So I used the Back button (on the screen, not in the browser) to go back to the beginning. However when I got there all my Virtual waypoints had become Physical, and all the Descriptions were missing. Worse, I couldn't edit anything on the page. Nothing on the webpage was clickable. All I could do was edit the URL in the address bar, or close the browser completely. I did this, and tried to submit the cache again, but the system (or my browser) had cached the page, and once again it wasn't clickable. So I guess I need to find another computer now and try all over again (I tried clearing the cache in my browser but this didn't resolve the issue).

 

I'm using Safari 5.1.7 on a Mac running OS X 10.6.8

[+Ruddles1325]

I'm using Safari 5.1.7 on a Mac running OS X 10.6.8

 

I managed to use a different computer today. The draft cache listing is clearly stored in my geocaching account - very smart. I was using a Windows 7 computer with IE9 and this time I could edit the draft listing with no problems. The titles had still disappeared (I meant titles in previous post, not description) but the WPs were correctly shown as virtual or physical instead of all being physical. So it looks like there's a bug with editing a draft listing on Safari.

[+S.B82]

There's still problems with the hint.

Here in Sweden we try to make our caches more tourist friendly by adding the hints in both Swedish and English and the line break bug is still there (submitting a whole bunch of new ones right now).

Regarding using formatted hints, this is nothing new and also something we often need to do if we need certain chars.

Edited May 29, 2014 by S.B82

[+-CJ-]

One of my friends also saw that "Validation failed for one or more entities. See 'EntityValidationErrors' property for more details" message.

 

I believe that displaying this message ("EntityValidationErrors property") is a technical bug to be replaced with something comprehended for a common user, right?

Edited June 15, 2014 by -CJ-

[Moun10Bike]

Can you provide the username for your friend? I can then look at what is occurring with any saved drafts on their account.

[+-CJ-]

korinskiy. His situation appeared to be the same as one described above. I just wonder if that error message is changed since "See 'EntityValidationErrors' property for more details" makes little sense to me and could confuse other players, especially those who speak no/little English.

[Moun10Bike]

I just spoof logged in as korinskiy and found no saved draft, and was able to proceed through the CSP without error. Do you know if he is still experiencing the error that you reported? We had an issue right after release with date formats that was causing that error, but that was corrected right away.

[+-CJ-]

No, he said the problem was with additional points. He removed them and got his cache published. After that he added his points. Looked like the bug described above in this thread.

[Moun10Bike]

The issue with additional points was also fixed shortly after release of the new CSP. When did he experience these issues?

[+-CJ-]

June 15, as far as I can see from our correspondence.

[+KRON family]

We have a problem with our speed.

We created a small trail. If we chose "Continue" on wapoints page before this page was fully loaded, we were redirected back to planning page.

[Moun10Bike]

June 15, as far as I can see from our correspondence.

 

Unfortunately, without seeing the saved draft of what was causing errors, I can only speculate.