It’s possible to copy-paste text into a Kerika Chat message, and there are legitimate use-cases for this: for example, a developer may ask a question to a coworker who replies with a code snippet.
Kerika handles code in chat messages by storing two versions of the message: as plain-text, and as the original format. When a chat message is displayed, the original format is used but not executed, which means the embedded code is visible, but doesn’t run in the browser. This makes it easy and safe to share code snippets through chat messages.
While making this improvement, we went through all the places where a user can type in text, Card Title and Description, Board Name and Description, Tag, Attachment Name, etc. to make sure we are guarding against malicious code injection.
With our latest release we have introduced a new way to have your Task Board and Scrum Board cards numbered automatically.
Our original implementation was rather rudimentary: if you turned on Auto-Numbering (which you can access from the Board Settings dialog, by clicking on the gear icon/button on the top-right of the Kerika app), Kerika would automatically insert a card number as part of each new card’s title.
Turning on Auto-Numbering of Cards
The card numbers inserted by Kerika were pure text that was prefixed to whatever you typed in as a card title. This meant that they could easily be changed by any Team Member (or Board Admin), and this, in turn, meant that what you saw as a card number couldn’t be completely relied upon as the real/original number of that card. A coworker could have easily edited that number to something quite different.
An example of card numbering.
To make these numbers more reliable and trustworthy, Kerika now keeps the card number as a separate attribute (field) of each card: it is shown, when Auto-Numbering has been turned on for a board by it’s Board Admin, but it cannot be edited by anyone.
With card numbers being stored as a separate attribute of each card, we are also adding an improved way to search for cards by their numbers: if you type in a number in the Search box inside Kerika, the system will first look for a card with that number before showing any other results.
Card Numbering in Scrum Boards
Card numbers are always unique to each board: a card with number 100 on Board A will have no relation with a card numbered 100 on Board B. Each board will keep track of its own numbering, starting with “1”.
So what happens with Scrum Boards? Scrum Boards are different from regular Task Boards in that they let you share a backlog across multiple Scrum Boards. This lets you run several Sprints one after another, with each Sprint drawing from the same shared Backlog.
(And, of course, this also makes it possible to run several projects at the same time that draw from the same shared backlog.)
Since each board keeps track of its own sequence of card numbers, if you move a card from a Scrum Board back to the Backlog column it will lose the number it previously had.
That’s because once a card goes back into a shared backlog, we can’t be sure which board it will get pulled into the future: the card may return to the same board where it was originally located, or it may get pulled into a different Scrum Board.
The smart approach in this situation is to reset card numbers when cards go back to a backlog.
We have started purging defunct accounts: users whose email addresses don’t seem to be valid anymore.
We are not doing this in a hurry, but instead are trying to be methodological about it: if someone’s email bounces, and we see they haven’t logged in during the past 6 months, we are going to assume this user doesn’t exist within that organization anymore, i.e. has probably left the company where they were previously working.
(The 6 months of no-activity helps us avoid temporary email problems, such as when someone’s email server is down for a day.)
Also getting purged are new users with invalid emails: this can happen when an existing user mistypes a coworker’s email address at the time they invite people to join their teams.
An account is created at the time someone initiates the invitation, but if we find the email associated with that account is bouncing, we will delete that account.
Kerika works well on modern browsers, but we still occasionally get folks trying to sign up using an obsolete or very old browser. (For example, Internet Explorer is obsolete; you need to use Microsoft Edge.)
To handle this, Kerika checks the browser information returned by your computer when you try to sign up or login, to weed out the unsupported old browsers.
We have expanded this now to make sure organizations that are using Mozilla’s Extended Support Release (ESR) program to manage their Firefox deployments are not hindered. Based upon this chart from Mozilla:
It looks like ESR 60.3.0 is equivalent to regular Firefox 63, so we now let people using this ESR (or newer) to use Kerika.
We have disappeared again from the Google App Marketplace: this is the third time in the last two weeks, and Google is trying to find the bug that’s causing this to happen.
The sequence that triggers it seems to be as follows:
1. We make an update to the Kerika product description on the Marketplace, to reflect some significant new improvement or feature.
2. The update shows up correctly, for a day or two.
3. Then the entire Kerika product listing disappears, without any warning or notification!
4. We contact Google, and they try to to restore the Kerika product listing. Unfortunately they find a really old set of screenshots and text, at least 3 years out of date if not more, and it’s a mystery where they even dredge this up from.
5. So, we try to update our Marketplace listing, and the cycle begins anew…
All of Microsoft’s browser focus is on their Edge browser, which means that as newer HTML5 features and standards get adopted by the browsers, these are going to show up in Edge, not IE 11.
And since Kerika is a pure Web app, one that requires you to download no software of any kind, including browser add-ons and plug-ins, we really need to make use of the latest HTML5 goodies that the browser vendors provide.
These goodies are going to be available only on Chrome, Firefox, Safari and Edge, and that’s where Kerika is gong to work best.
As you know, Kerika is a Web Application: everything runs inside a browser, without the need for any plug-ins or add-ons.
We achieve all this with a ton of JavaScript code (and a sprinkle of SVG, for our Whiteboards.)
One, significant, disadvantage of JavaScript is that it is “single threaded”: two bits of script cannot run at the same time; they have to run one after another.
So while Kerika is running inside a browser on your laptop, our JavaScript has to share a thread with lots of other stuff that’s going on, such as painting, updating styles, and handling user actions. All of this has the potential to slow down Kerika, while the JavaScript code waits for something else to finish.
To get around this, we used JavaScript’s Promise function: this let Kerika’s code get going with its normal business while waiting for other browser functions to finish. What we didn’t expect, however, was that the Promise function isn’t supported by Internet Explorer 11. (Although it is supported in Microsoft’s Edge browser.)
This caused problems for all of our Internet Explorer 11 users — people using Chrome, Safari, Firefox or Edge were unaffected. We finally figured out what the underlying problem was, and did a workaround using a polyfill, which is a way to provide new functionality in older browsers that don’t support it natively.
The Box Platform has some limitations that you may bump into:
Certain characters are not allowed in file names, e.g. “/”. We noticed people were running into this problem, most probably because they were hitting the wrong keys inadvertently when renaming files.
Kerika is going to take of this silently from now on: if you try to rename a file using a character like “/” that Box can’t handle, Kerika will silently ignore that character in your renaming action.
File names can’t be more than 260 bytes. For people using English and similar languages, this generally means a file name cannot be more than 260 characters (with each character requiring one byte of storage). But for most Asian languages, e.g. Thai or Japanese, one character may require two bytes of storage, because the size of the alphabet is much larger than the Roman alphabet used by English.
This means that in some languages, file names may have to be much shorter, depending upon how many bytes are needed for storing each character, which in turn depends upon the size of their alphabets.
Some folks from Thailand were running into this problem: Kerika will start detecting this better, and provide more useful error messages
Kerika offers a great deal of control over how each board is shared:
A board can be made public to everyone. This makes sense for open-source projects and many nonprofit and advocacy groups, where the goal is to get maximum visibility and publicity rather than to hide the details of what the project is about.
Making a board public means that anyone who has the URL of the board can view it, even people who are not Kerika users. Note: we are talking about viewing the board; viewing doesn’t mean anyone who isn’t part of the board team can make changes.
If a board is viewable by the public, it can be found by anyone using Kerika’s search function.
A board can be viewable by everyone who is part of the account team. This is the default setting, and it makes a lot of sense for most organizations: you want your coworkers to be aware of what your team is doing, unless the project is particularly sensitive.
As people get added to individual boards, they are also automatically added to the account team. When someone is removed from every board owned by an account, they are automatically removed from the account team as well.
As with public boards, described above, we are talking only about viewing, not changing: only people who are Board Admins or Team Members on a particular board’s team can make any changes to that board. (And, of course, the Account Owner who owns the board.)
If you use Kerika’s search function, you can find boards that are being shared with the account team, provided you are part of that particular account team.
A board can be kept private. This means that only the people who are listed on the board’s team — as a Board Admin, Team Member or Visitor — can view the board. (And, of course, the Account Owner who owns the board.)
This is appropriate for any sensitive projects, e.g. stuff related to personnel matters or confidential contracts.
Private boards can’t be found by Kerika’s search function either, and it doesn’t matter if you know the URL for the board: only the specific people listed on the board team can see anything related to that board.
For each board owned by an account, the Account Owner or Board Admins can manage the board’s team: decide who is part of the team, and what sort of role (Board Admin, Team Member, or Visitor) each person has.
Board Admins and Team Members can make changes to all the items on the board, including any documents attached to the board.
Visitors have read-only access to the board and all its documents.
A person’s role can be changed at any time by the Board Admin or Account Owner: the effect is immediate, and extends to all the documents associated with the board as well regardless of whether you are using Google or Box for your file storage, or whether you are storing your files with Kerika.
A board’s team and current privacy settings can be viewed by clicking on the Team button that appears on the top-right of the Kerika app, when viewing a board:
Board Team button
Clicking on this button brings up the Board Team dialog:
Board Team dialog
Each person who is part of the Board Team is listed in this dialog, in alphabetical order along with their role.
At the bottom of the dialog is the board’s current privacy setting: in the example shown above, the board is being shared with everyone who is part of this user’s account team. (We have obscured the URL in the screenshot for security reasons.)
If you are a Board Admin or the Account Owner, you can change the privacy of the board using the Change Privacy link that’s shown on the bottom of the dialog:
Board Privacy options
So, every board can have it’s own privacy settings: private, shared with account team, or public.
When you are viewing the boards in an account, Kerika shows clearly what the privacy setting is for each board:
Privacy settings, at a glance
If you are part of someone’s account, you will be able to create new boards in that account: you will automatically be a Board Admin on those new boards, but the owner will always be the account you are working in.
You can set your privacy preferences for each account; this will determine whether new boards you create are automatically shared with your coworkers or not:
Privacy preferences
All your preferences can be set at https://kerika.com/preferences. The default setting is Share with Account Team, which works well for most people, most of the time.
This website uses cookies to improve your experience. We'll assume you're OK with this, but you can opt-out if you wish.AcceptRead More
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
