Thanks to one of our long-standing Kerika users (over in Gdansk, Poland) for spotting a bug that we have fixed: if you held down the Enter key for “too long” (which is kind of a vague description, we know) while editing a card’s description, some junky HTML text would appear:
It was an odd timing issue that we hadn’t noticed before. Thanks for helping us find this bug!
In a recent update, we added a minor new feature: you can now copy and paste lines even if they are not used to connect any other objects on a Kerika Whiteboard.
We always let you copy and paste lines that were used to connect other objects, like in this scenario:
But now you can also copy and paste freestanding lines (i.e. lines that are not anchored at either end on anything else), like this:
The fact that copying/pasting freestanding lines was not possible before was actually a conscious design decision on our part, but looking back we can’t figure out why it seemed like a good idea at the time :-/
Our thanks to Larry Smith from EduTone who initially alerted us to a bug in the process of signing up as a Kerika user: the confirmation email sent by Kerika wasn’t working well, particularly if the user used any browser other than Chrome.
For example, clicking on the confirmation email and having Kerika open that link using Firefox or Chrome produced this kind of behavior:
The problem was related to a recent decision we made to use Polymer for parts of our website.
It turns out that Chrome had a different sequence for loading the Polymer components than other browsers.
In Chrome the sequence is
Our build.min.js file needed components that were loaded only when element.vulcanized.html was loaded, which meant that the sequence in which these files were loaded by the browser was important, and different browsers were loading these files in different sequences.
We fixed this bug: Polymer has a method to ensure that all imports are ready before the page is rendered.
This has been part of the learning process for us as we adopt Polymer more for our website redesign (which is underway, and should be unveiled by Christmas), and also consider using Polymer to rebuild the Kerika app itself!
(Thanks to our users in the Washington Professional Educator Standards Board for helping us find this bug.)
We recently discovered a rather quirky bug that was causing some chat, when replied to as emails by the recipient, to not get sent properly.
Here’s what is supposed to happen, and what went wrong:
(Board Admins have the option of getting all chat, on all cards on the board that they manage, pushed to them as emails, if they want to really be in the loop with every conversation that is going on in the board.)
Here’s an example of chat email:
And what clicking on the Reply button does:
In the above example, although the chat email came from Cheryl, the reply is being sent to a special address:
“Card-nj3j@kerikamail.com>”
(This helps reduce the possibility of spam email appearing inside your Kerika conversations.)
The problem we found is that some email clients, e.g. the native Mac Mail client, handled the “From:” and “Sender:” fields differently from other email clients like Gmail.
In the case of Gmail, Google places fills in both the From and Sender fields, but in the case of Mac Mail, only the From field is filled in.
For now, a temporary fix is to have the server look for both the From and Sender fields, but longer-term, as part of a server re-architecture that we are planning, this problem will get solved differently that further reduces the possibility of spam.
It looks like we were on the bleeding edge of Google’s problems last Friday (Oct 9): fairly early in the day, Pacific Time, we started seeing authentication failures from Google related to our Kerika+Google users.
The exceptions shown in the Kerika server logs were clearly pointing to problems on Google’s end:
What was a little frustrating for us — and our beloved users — was that Google itself didn’t seem to be acknowledging any problems until fairly late in the day:
By this time — almost noon, Pacific Time — dozens of Kerika users had been affected. We tried to let folks know via Twitter that there was a problem, and continued to monitor the situation through the day:
.@Google‘s authentication service for login to @Kerika is throwing a bunch of errors right now, affecting a range of our users. Apologies.
— Kerika (@kerika) October 9, 2015
A range of users who use their #googleapps IDs to login to Kerika are being affected by mysterious, unacknowledged problems on Google’s end.
— Kerika (@kerika) October 9, 2015
Looks like the @Google authentication failures have trailed off; hopefully our Kerika+Google users can login now without trouble.
— Kerika (@kerika) October 9, 2015
Google eventually acknowledged the problem as it became clear that it was widespread.
By mid-afternoon, the issue was largely cleared up, at least as far as Kerika was concerned, although it is possible that other apps, which also use Google for authentication or Google Drive for storage, were affected for much longer.
Once again, our apologies for everyone who was affected.
We are currently seeing a bunch of errors from Google with respect to their authentication service — which lets you login to your Kerika+Google account using your Google ID, and they seem to be affecting a wide range of users.
Here’s a sample of what we are seeing:
This error normally shows up when a user is logging in with a Google for Work ID, e.g. Google Apps for Business or Google Apps for Education.
What’s surprising today is that we have seen at least 1 user with a regular Gmail address have this same problem, which is theoretically impossible.
Right now there’s not much we can do but wait this out. The problem seems to be small enough that Google is not even reporting it on their Google Apps Status Dashboard. 🙁
Our thanks to Tatjana and Steve from Ducks Unlimited in Canada, who helped us track down a bug that was stopping notification emails being sent properly when a Team Member is assigned a card on a Task Board or Scrum Board.
(Board Admins were getting these emails when people’s assignments changed, but not the Team Members themselves.)
We fixed this with our latest release.
If you use the “file picker” that’s built into Kerika to add an existing Google Drive or Box file to a card, canvas or board — for a Task Board, Scrum Board or Whiteboard — you will see a message that says the file is being copied.
This is the file picker:
Clicking on the File Picker button brings up the File Picker dialog:
And this is the “copying…” message that’s shown.
So, what’s happening?
Well, Kerika stores all your Kerika-related files in a set of special folders within your Google Drive or Box account, if you are using Kerika+Google or Kerika+Box, and these are organized neatly into folders corresponding to each of your boards.
Here’s what the folders in your Box account look like (you can learn more by reading about how Kerika integrates with Box):
It’s a similar structure if you are using Kerika with Google:
Keeping all the Kerika files together in a set of related folders makes things cleaner for you: when you look at your Google Drive or Box Account, you know exactly what’s being used by Kerika, and what’s other stuff.
And this is why we make a copy of your existing Google Drive or Box file when you use the File Picker: it enables us to put a copy into your Kerika-specific folders, where it is easier to share with the rest of your project team.
When you are writing a chat message, on a card or canvas on any Kerika Task Board, Scrum Board or Whiteboard, what happens if you need to leave that message in the middle and go look at something else in Kerika?
For example, suppose you are in the middle of writing a chat message, but in order to complete it, you need to go off and look at another card’s details, or maybe a file attached somewhere else on the board?
You can leave aside a chat in mid-stream, go somewhere else in Kerika, return to the chat, and pick up where you left off!
That’s because Kerika uses your browser’s local cache storage to keep your unsent message: it means your changes aren’t lost while you go look at something else in Kerika.
This is a handy usability fix we have always had in Kerika, but it may be one that folks didn’t realize existed…
Well, now you know 🙂
We use a number of Amazon Web Services, including one called Simple Queue Service which Kerika uses to handle communications between our main project database server and a separate server that handles the Search function.
AWS works very well in our opinion — it has very high reliability across most of its services — but like all software, it isn’t entirely infallible.
Over the weekend we observed a small handful of errors in our services logs where it looked like SQS had a temporary problem.
We cross-checked this time period with other activity on Kerika, and determined that about 7 Kerika boards may have been affected: not in terms of any data loss or corruption on the board itself, but in terms of some changes not being updated in the search index.
Now, 7 boards is a tiny portion of the entire Kerika project database, which numbers in the hundreds of thousands of boards, but we are glad to have spotted the potential for trouble and have re-indexed the data on these particular boards.
If we did our job well, no one will notice.