Some Kerika users — specifically those who had signed up directly — had trouble logging in if they had left Kerika running overnight on a browser.
Their browser was endlessly refreshing itself, bouncing between the /app and /setup URLs. There was a workaround (type “https://kerika.com/logout” to clear Kerika’s cookies) but the workaround was far from obvious, so obviously some people were inconvenienced.
(Would have been a lot more had it not been for the Christmas holiday season!)
This has been fixed now. We found a problem with the configuration of our NGINX web server software.
We found and fixed a bug that reported incorrect counts for some Views (on the Home page), that was triggered when users did a particular sequence of opening a View, applying the Assigned to Me toggle, and then returning to the Home page.
It was an edge case that took us a while to figure out because our own team didn’t see the problem happen; it only affected a few users.
The counts shown on your Home Page, under the Views tab, should be correct now.
Thanks to our users in Belgium and Finland for pointing this out to us: our Pricing Page wasn’t displaying correctly in browsers that had their default language set to something other than English.
This was happening only sporadically, and only in Chrome; other browsers like Microsoft Edge were handling it correctly.
Chrome was trying to localize text for non-English users before the language resources were ready; this problem had actually been fixed in the latest version of Polymer We are using ‘app-localize-behaviour’ of Polymer’s app-localize-behaviour (1.0.2). Turned out we were a version behind in updating our use of Polymer.
We recently found and fixed an odd bug related to the optional 6AM Daily Task Summary email that you can get from Kerika: if you had toggled the preference setting for this email — from ON to OFF, and back to ON again — the email was getting sent at 8AM instead of 6AM.
Essentially a coding mistake on our part, and one we didn’t notice (and none of our users noticed, either) for a long time because no one would try changing this preference setting very often.
Fixing bugs. Lots and lots of bugs, all minor but we don’t like to have any known bugs at any time.
We recently implemented some new error reporting services so that we can trap server and browser exceptions more efficiently.
This threw up a bunch of errors that we hadn’t been aware of before. Obviously these were minor, since no one had observed any ill effects before, but it’s long been a point of pride for the Kerika team that no known bug gets away alive.
One advantage of having a clean slate is that it makes any new errors immediately more visible. If you get used to ignoring some exceptions/warnings because you know they are not important, your team eventually gets desensitized to the presence of these errors and warnings, and bigger, more important issues start to get ignored as well.
Thanks to a longtime user from Poland, we discovered — and fixed — a bug that crept into one of our recent feature enhancements, where items couldn’t be permanently deleted from the Trash column on Task Boards and Scrum Boards.
We did an update yesterday that included a bunch of minor bug fixes and usability tweaks. (It also included a ton of behind-the-scenes improvements to our architecture and product development processes, but if we did our job well you shouldn’t see any of that change…)
When the Kerika server is being updated (to a newer version), your browser will no longer keep trying to reconnect while this is underway.
We have some code in place to help fix broken network connections: if your browser can detect that it’s connection to the Kerika server is broken for any reason (usually a network error), the browser will automatically attempt to reconnect.
This doesn’t make sense if the server is down for planned maintenance.
If you are working in multiple accounts and you decide to switch between them, we offer your choices in a more logical way: all the account owners you are connected to are listed alphabetically, and then each account owned is listed alphabetically.
Our previous display was kind of random making it hard to scroll through a long list of accounts. This affected only a very small number of users who were working on many different accounts, but still…
Now that we are encouraging our customers to converge around service accounts, we are trying to make sure these service accounts don’t get too crowded from the perspective of any single user.
We have always had the ability to “favorite” some boards (and templates) so you can have your own personal, curated list of boards that you care about — and so you can ignore the rest — but now we have made it easier for Board Admins to move their boards to the trash or archive (or to restore them later) so they can help keep the commonly-shared service account in a more useful and relevant state for all the users within that account.
A really small thing, but we decided to change the Sort by Status feature on our Task Boards and Scrum Boards so that On Hold cards appear at the bottom of the column, below all the others.
Bug fix: if you changed the name of a board using the Board Settings dialog (assuming you are one of the Board Admins), the new name is now reflected immediately in the breadcrumbs.
If someone who is currently a Team Member on your Task Board or Scrum Board is made a Visitor, he/she will not be removed from the current card assignments. This makes it easier to change your mind if you decide you want that person to be a Team Member after all: just change this person’s role in the Board Team dialog, back to Team Member, and all the old card assignments will be there.
With the proliferation of top-level domains we have had to update some of our old code that tried to make sure people were signing up with properly-specified emails.
In the old days, of “.com” and “.org” and other short domain extentsions, this was easy to check at the time someone entered an email address: if it wasn’t properly formatted we could alert the user right away so they didn’t go down a dead-end path.
We can’t do that anymore: new top-level domains are being launched on a regular basis by registry companies and the list of potential domain extensions is no longer finite or easily matched by regular expressions.