Tag Archives: Bugs

About software bugs.

A bunch of bug fixes and usability improvements for Tasks

We have done a bunch of small bug fixes and usability tweaks to the Tasks feature we introduced a few weeks ago:

  • When a user’s last Task within a card is marked as Done, the user’s name is removed from the list of people shown as being assigned to that card. (Previously you had to do this cleanup manually.)
  • When a Task that was previously marked as Done is changed to be “undone” (open/remaining), the user who had previously been assigned to that Task is added back to the list of people shown assigned to the card.
  • Bug fix: If someone is assigned to a Task, and this person had previously completed a Done Task, this user wasn’t getting added automatically to the list of people shown on the card. This has been fixed.

 

Bug, fixed: Custom Highlights were getting carried over from one board to another

We fixed a bug that was kind of annoying: if you had a Custom Highlight defined for one board, and then switched to another open board, the Custom Highlight was getting applied automatically to the second board as well.

This happened only if people used the Board Switcher button that appears on the top left of the Kerika app:

Board Switcher
Board Switcher

The Board Switcher keeps track of all your open boards and is a fast way to switch between them if you are working on several different projects at the same time — you don’t have to go back to the Home page to find your boards again and again.

Every of your open boards can have Highlights set, or not, as you like. This bug fix makes that a smoother process.

Bug, fixed: adding SharePoint URLs as attachments on cards

Thanks to one of our users at Washington State’s Employment Security Department, we found and fixed a bug that was causing problems when users tried to add SharePoint URLs as attachments on cards, for Task Boards and Scrum Boards.

The problem turned out to be in some code we have that tries to check whether a user is entering a valid-looking URL.  SharePoint’s URLs are somewhat unusual in that they include the “{” and “}” characters, which most other web servers don’t use.

Our old code was treating these characters as invalid, thereby rejecting URLs coming from SharePoint.

This has been fixed now.

Thanks!

Bug, fixed: board descriptions in Internet Explorer 11

We found a bug that was causing problems for users who wanted to edit/update their board descriptions, using Internet Explorer. We fixed that.

In case you are wondering where the board description is found in the first place, here’s how you can edit it:

Click on the gear icon that appears on the top-right corner of every Task Board, Scrum Board or Whiteboard, and then chose the Settings tab:

Editing board descriptions
Editing board descriptions

 

By default, the board description field will be empty, naturally, but if you are one of the Board Admins (or the Account Owner), when you move your mouse over the Description field you will see a pencil icon appear (highlighted in red, above), and clicking on that will let you add a board description.

Adding a board description
Adding a board description

 

Board descriptions can be up to 180 characters long, and as you type the system will automatically let you know how many characters are left for you to type. (Yes, Twitter-style.)

Board descriptions are going to be very useful in the future as we make some changes to our user interface and search functions.

Bug, fixed: handling non-English characters

This is kind of annoying and embarrassing, but a while back a bug crept back into our code that made non-English characters appear as question marks.

Embarrassing because we have fixed this bug before. More than once.

This time around the bug crept back in while we were taking care of some other feature, and unfortunately it was one of our (Chinese-speaking) users who spotted it before we did.

Our own team is multilingual (3 languages) but we work almost exclusively using English, so this was one of those rare scenarios where we didn’t use a particular feature of Kerika and so developed a blind spot.

Sorry about that.  The good news is that the fix is retroactive: any non-English characters that you had previously entered will not appear correctly, without any work on your end.

Bug, fixed: holding down the Enter key while editing project descriptions

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:

Card description bug
Card description bug

 

It was an odd timing issue that we hadn’t noticed before. Thanks for helping us find this bug!

Bug, fixed: sometimes email replies to chat weren’t working

(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:

  • If you are assigned a card, on a Task Board or Scrum Board, you will get email pushed to you whenever any other Team Member (or Board Admin) chats on that card. This helps you stay in the loop on the most important items on a project board: the ones you are currently assigned to do.

    (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.)

  • When chat gets pushed to you as email, it shows up looking just like regular email, and you can reply to it wherever you are dealing with your email: your desktop, laptop or mobile device.
  • When you click on the “Reply” button in your email client, Kerika automatically changes the address for that reply to be the URL that points to the specific card (or canvas) that’s being referenced in the chat.

    Here’s an example of chat email:

    Chat example
    Chat example

    And what clicking on the Reply button does:

    Replying to Chat Email
    Replying to Chat Email

    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 email is received by a server that listens only to chat replies. When a chat reply is received by the server, it checks to see who the reply came from.
  • Since only Team Members and Board Admins are allowed to participate in the chat on a particular board, the Kerika chat server tries to make sure the email is coming from someone who is authorized to comment on that particular card or canvas.

    (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.

Bug, fixed: Team Members weren’t getting notification emails when they were assigned cards

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.

Bug, fixed: handling filenames with Cyrillic characters

A Russian user kindly alerted us to a bug that we have now fixed: filenames that used Cyrillic characters were not getting uploaded correctly, because of an encoding problem.

The problem had to do with Kerika not using a sufficiently large character set, which resulted in some languages not being supported properly.

We have fixed that by moving away from the UTF8 character encoding to UTF8MB4, which is an encoding format used by MySQL databases.

UTF8 uses a maximum of 3 bytes per character, which limits the range of languages that can be supported.  UTF8MB4, however, uses a maximum of 4 bytes per character which considerably extends the range of possible characters.