Jump to content

thomfre

+Premium Members
  • Posts

    571
  • Joined

  • Last visited

Everything posted by thomfre

  1. Look at the description. Two different times, making it very confusing. Which one is correct?
  2. If times like these aren't allowed anymore, the reviewers would need to start enforcing it as well: http://gc.link/GC81R2M
  3. 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.
  4. 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).
  5. 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.
  6. 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?
  7. 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?
  8. My Pi-Hole is self hosted, so yes, I track my own traffic. I don't see any problem with that...
  9. 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.
  10. 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).
  11. 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...
  12. The simple solution is for you to just delete your will attend log. The best solution is to just archive all recurring events.
  13. 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...
  14. This clearly is a bug. Bugs happen. In all software. You really need to take a chill pill.
  15. 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...
  16. 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.
  17. 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: Thank you for patching security holes before you tell people how to abuse them, Groundspeak. This is the way you should do it.
  18. 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.
  19. 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.
  20. Are you sure it's not just your browser blocking popups? That was the case on my profile...
  21. 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.
  22. 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.
  23. 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...
×
×
  • Create New...