Before we start, I want to welcome Leonardo da Luz to our team. If you’re reading this in Portuguese, it’s thanks to him. If you read the boring English version instead, we forgive you.
During April, JudgeApps saw few changes, most of them regarding privacy. These changes follow last month’s announcement regarding account creation and verification. With changes making it easier to register an account – and plans to allow unregistered users to view more content on the site in the near future – we needed to give people the option to better protect some personal details that used to be public. With the new changes, we allow users to choose between showing some information to all users, only registered users, or only certified judges. Of course, certain trusted user groups (site admins or program leadership, for example) might be able to see certain information despite these settings.
New privacy settings were added to user profiles. A user can now decide whether their location and avatar can be seen by everyone, registered users or certified judges only. Like before, the location information can be set to hidden.
The default for the location was set to registered users (or hidden, if it was hidden before), and avatars are only visible to certified judges by default. If you want to check or change these, you can do so by going to your profile page and click on the “Edit Profile and Settings” button. The settings for avatar and location visibility can be found under the “Privacy” category.
Additionally, a bug that popped up as soon as this changes were implemented caused uncertified users to not be able to see their own avatars. This was fixed.
Another bug that was fixed this passing month relates to comment notifications. While rare, if someone posted a comment on a judge’s application to an event, but then would stop being an admin for that event, they would still get notifications for further comments about said application. Notifications now check whether a possible recipient is an event admin before being sent.
Comment Error Descriptions
On a similar note, we improved the error notifications for checklist failed comments. Previously, every error was met with a very uninformative “Error! Can’t post a blank comment! Go back in your browser and try again…”, even if everything seemed fine. The error notification was changed to explicitly point out the erroneous fields.
If this headline sounds familiar, it’s because we discussed something similar a few months ago. During the January update we introduced cloning a failed checklist so it can be fixed and re-submitted. Now we’re introducing a similar option for checklist types, so if two checklists have mostly the same requirements, one can be cloned and edited slightly instead of being created completely from scratch. This should make things easier for judges using this feature.
As always, we’re here if you have any comments, requests, bugs to report or any sort of feedback.