With our most recent update (which was yesterday), we have fixed a problem with thumbnails of attached images not showing correctly. (Not always, but sometimes.)
Here’s what the problem used to look like:
As you can see, this card has two images attached. The first one doesn’t show a thumbnail properly (it has a standard “missing image” icon instead) while the second one works fine.
The underlying cause for this was a mismatch in the duration for which Kerika was caching the thumbnail of an attachment after it had first been retrieved from Google Drive, and how long Google Drive was keeping the thumbnail around.
So you never saw the problem when you first attached an image, but if you went back to the card after 30 days you would see the “missing image” icon instead.
We have fixed this. You may still see this if your browser is caching old thumbnails; you can completely eliminate the problem by clearing your browser’s cache, which would force Kerika to request new thumbnails from Google.
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.
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.
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.
If you create a list of tasks on a card on a Task Board or Scrum Board, Kerika does a bunch of stuff in the background to make sure your view of what’s due, at the card level, board level and account level, are always correct.
We found a couple of edge cases where the due dates on tasks wasn’t rolling up correctly to the card level, potentially giving users a misleading view of what was currently due for them:
When the last task with a scheduled due date was removed (deleted) from a card, this wasn’t correctly adjusting the due date for the card itself.
Similarly, when the last task with a scheduled due date was no longer scheduled, this wasn’t correctly adjusting the due date for the card.
Both bugs have been fixed. They were real edge-cases, so it’s likely that most users never noticed them in the first place, but still…