thomfre
-
Posts
571 -
Joined
-
Last visited
Posts posted by thomfre
-
-
If times like these aren't allowed anymore, the reviewers would need to start enforcing it as well: http://gc.link/GC81R2M
-
44 minutes ago, hleeful said:
A time is only added to an event cache when a new cache is created or an existing event cache is edited, so it's very likely that the CO is editing the cache and not noticing the new time requirement. We'll try to let COs know when we see this occur, though hopefully it will be a small number of caches that have this inconsistency.
Maybe the best is to not have any default value in the time fields? So that the CO must explicitly set a time for it to do anything. That would probably be the best in the long run anyway, to avoid default values being submitted and published.
-
.png)
5
-
.png)
1
-
-
-
Then there's this issue: am vs pm: https://coord.info/GC82GWH
The autogenerated part of the description say 01:00 - 03:00 (01am-03am), and a few lines below it's 1pm-3pm (13:00-15:00). -
I noticed a new issue now. Some events will have two times, and it's hard to tell which one's correct. One time added by the new field (the CO might not have seen it while editing) and the old written by the CO.
This could be because the CO didn't notice, and a default/random time was selected in the new fields. Or it could be that the CO changed the value in the new field, without updating the existing information in the description.
-
1
-
-
This is awesome!
I love that the minimum time and no multi-day events finally get enforced! We see a lot of events published with wrong times, and even no times at all. And many work very hard to hide the event times, for some reason I can't understand. So this is a huge improvement to the entire community!
A few requests from me:
- Please allow custom times, like 11:11
- Please add option for time format to the user preference page, I don't want times to show in 12-hour format
-
The automatically added date-time text in the description looks ugly in my otherwise nice description, does it have to be there?
-
4
-
My wife got the same issue, the app just crashes. Latest version available, 7.2.0.
I noticed the same happening now when I zoomed the map out too far. Too many caches?
-
Just now, on4bam said:
They in turn track (by design) your traffic. he same can be done having an extensive hosts file.
My Pi-Hole is self hosted, so yes, I track my own traffic. I don't see any problem with that... -
On 11/9/2018 at 12:55 PM, NYPaddleCacher said:
...I don't want commercial solicitation sent at all.
I highly recommend Pi-Hole. It will "block" (it's a DNS server, that resolves all ad domains to 0.0.0.0) the ad before it gets to your browser.
-
8 minutes ago, Kaarthuul said:
I get the popup and say OK but it just opens another profile page instead of the link. The post above talked about changing the HREF link to go via geocaching.com but I could not get it to work?
You can get this to work in your browser by using my user script: https://thomfre.net/gcunappifier.user.js (you will need to install Tampermonkey first).
-
1
-
1
-
-
3 minutes ago, monsterbox said:
Hi Cindy!
Looks like the milestones form the standard statistics are affected, too. As well as the GSAK-FSG statistics who look pretty uggly now, hope they will come with a quick fix...
Bye,
Christian
I see the same. Milestones doesn't work at all (the geocaching.com provided statistics). I also see some error messages in the JS console, so I guess there's something wrong somewhere.
Maybe not the best idea to release major changes right before an extended weekend...-
1
-
.png)
1
-
-
The simple solution is for you to just delete your will attend log.
The best solution is to just archive all recurring events.
-
38 minutes ago, Mausebiber said:
GS is changing there System from "working" to "Server Error" and you are telling us this is the way software works?
I expect that systems are tested before they go live, I don't want to be GS testing Guinea pig.
They did not change it from working to "Server Error". Nobody does that. But bugs are rather common in software development. There's always that one thing you forgot to test, that is different in production.
For all I know, this could even be a problem with the load balancer. It's probably anyway unrelated to the profile page change, since it affects all pages (seemingly randomly).
The systems are tested. But keep in mind that Groundspeak has less than 100 employees. Even Facebook and Google, with thousands of devs, have bugs in production...
It sucks when things doesn't work, I fully agree on that. But it doesn't help to attack the people that can fix it...-
2
-
-
See also:
-
10 hours ago, RNKBerlin said:
And fresh from the adding insult to injury department, this. Yes, that is my current profile page. Thanks for nothing, Groundspeak.
This clearly is a bug. Bugs happen. In all software. You really need to take a chill pill.
-
1
-
-
1 minute ago, reybr said:
How does changing a link from plaintext to a JS link with the original target base64 encoded make things more secure? With plaintext I can easily see what site a link will send me to before I click on it. Not so much with this change.
And JS links in general are just a very bad idea when thinking about usability
This is so very true. I consider this to be a much higher security risk than just allowing plain normal links without that stupid warning alert. But if it's just base64 encoded, we should be able to make a simple user script to fix this... -
I also see this a lot. Not the normal custom error page, but a standard runtime error (specifying that another exception occurred when trying to display the custom error page).
Any ETA on a fix for this? It's making it hard to log caches etc.
-
29 minutes ago, RNKBerlin said:
Do you work for Groundspeak? If not, would someone from Groupspeak care to provide an official response? Including which problem(s) exactly Groundspeak was trying to solve?
Wow, no need to be so unfriendly. I do not work for Groundspeak. But I work a lot with GDPR.
But this response is from a lackey:
On 11/9/2018 at 1:28 AM, bootron said:We have been making various changes to the website and mobile app in order to support GDPR issues and also PCI Compliance and general security concerns. This particular change is more about the latter two than it is about GDPR.
bootron
Thank you for patching security holes before you tell people how to abuse them, Groundspeak. This is the way you should do it.-
2
-
-
1 hour ago, RNKBerlin said:
The EU-GDPR was implemented on 25 May 2018. Has Groundspeak been breaking EU law for months? If not, which EU-GDPR related issues exactly were addressed by this change to the profile pages?
Most companies have been breaking the law for months, yes. Including the big ones, like Facebook. But in this case, it's just bad wording from Groundspeak. This change has nothing to do with GDPR. This has to do with security, so it is probably more related to PCI.
-
7 hours ago, Gill & Tony said:
Can anyone explain to me why European law applies in the US or any other non-European country? I mean, if an EU citizen chooses to visit the US physically, they are subject to US law. Why is it different if they choose to visit virtually?
Because Groundspeak is doing business in Europe, selling products to European customers. It's the exact same when companies do it the other way, provide services from Europe to American users.
-
13 minutes ago, lodgebarn said:
None of the cache links on my profile work now.
Are you sure it's not just your browser blocking popups? That was the case on my profile...
-
1 minute ago, HHL said:
Right, but the logs (and hence the ratings) are the loggers' property.
That's irrelevant. If they use this for any kind of automatic decision making, we need to be informed about it.
But right now, we don't know very much about this thing. So all of this is just speculations.
The only I know is that it's been hidden on the cache page for a while now (try to inspect the HTML above the cache name), and lots of people have seen it. Some have said they will archive everything, and some probably will.-
2
-
-
3 minutes ago, noncentric said:
Really? I thought GDPR was about protecting PII. How would ratings about a cache be under the purview of GDPR?
They are collecting data about my cache. My cache is my property. So someone might be able to argue that they have to share the data they collect with them.
This might be taking it a bit too far. But it's certainly not very different from other things they are blocking/changing due to GDPR.
If they decide to use this data to make profiles and/or automated decisions, decisions that can affect European users, it will be covered by GDPR.
-
1
-
-
Can you please restore outbound links? I see the need for blocking javascript, but links shouldn't be any problem.Can you please make links open the normal way, so it doesn't trigger popup blocking...
-
4
-
.png)
.png)
.png)
Release Notes (Website: Event start and end times) - January 15, 2019
in Geocaching HQ communications
Posted
Look at the description. Two different times, making it very confusing. Which one is correct?