We have made a change to the Card and Board Attachments feature to prevent users from changing the extension of a file they have already added: for example, a “.xlsx” file can’t be renamed as a “.docx” file.
We did this because changing the file type often had unpredictable consequences when a Team Member tried to upload an attachment.
This restriction applies to the most common file types, not all. Here’s how it works:
In the example above, an image has been added as an attachment to this card, and it has the .PNG file type/extension.
When you hover your mouse over any attachment, Kerika will show you the actions that are possible with that attachment, one of them being Rename.
If you select Rename, Kerika will make sure you only change the file name, not the file type/extension (.PNG in this example):
We added a feature recently (or did we actually a bug?) for our direct login users: when you reference a file that’s attached to a Kerika card, canvas or board, from another place in Kerika — e.g. another card’s details or chat — we now show the file’s name instead of just the URL.
This makes it easier to cross-reference file attachments from within different Kerika cards or boards, where different work items or conversations refer to the same shared file.
We have long had a deep, excellent integration with Google Apps: you can sign up with your Google ID and have all your Kerika-related files stored in your own Google Drive, where you can access them independently of the Kerika app.
We are now taking that one step forward, with seamless integration with Google Team Drive.
Google Team Drives are shared spaces where teams can easily store, search, and access their files anywhere, from any device.
Unlike files in My Drive, files in Team Drive belong to the team instead of an individual. Even if members leave, the files stay exactly where they are so your team can continue to share information and get work done.
You don’t need to do anything different: the integration is built-in with the latest version of Kerika (and, since we are software-as-a-service, everyone always uses the latest version of our product!) and the integration is seamless.
Thanks to our users at Oxbow Farm, we have found and fixed a bug that affected users who signed up directly with Kerika: clicking on an attachment in the card details was downloading the original version of a file, not the latest.
Here’s what was happening: when you add a file to a card or canvas, Kerika checks to see if that file was already being used on that particular card or canvas. If so, Kerika automatically handles your latest upload as providing a new version of the old file, so you see just one entry in your card attachments view:
The bug that we recently discovered, and fixed, resulted in Kerika downloading the original version of the file when you used the download option that appears after you select an attachment from the list of attachments on a card.
If you clicked on the attachment’s thumbnail to open a preview of the file, Kerika was correctly opening the latest version of the file. The bug was only in the download action, and that’s been taken care of now.
People usually don’t pay attention to the question of who owns a particular board, but it is an important question to consider when you create a new board: the Account Owner owns not just the board, but also all the files attached to cards and canvases on that board.
This is not always important (and often not important in day-to-day use of Kerika): our deep integration with Google and Box ensures that everyone who is part of the board team has automatic access to all the files needed for that board, with access permissions managed according to each individual’s role on the board: Board Admins and Team Members get read+write access; Visitors get read-only access.
(And, as people join or leave board teams, or their roles on a particular board’s team changes, Kerika automatically manages their access to the underlying project files, regardless of whether these are being stored in Google or Box.)
But when someone is planning to leave an organization, the question of ownership can suddenly become important: you don’t want an ex-employee to continue to own critical project files.
Changing ownership of boards was not something that was easily done in the past — there were workarounds, but they were fairly cumbersome and obscure — and we mostly handled these as special requests, on a case-by-case basis.
With our newest update to Kerika, this is no longer the case: changing the ownership of a board is a simple process that can be initiated at any time by the current owner of a board:
You can ask any other Kerika user, who has signed up the same way as you did (i.e. either as Kerika+Google, Kerika+Box, or by directly signing up) to take ownership of a board. Because this is a consequential action, not something you should rush into, you are asked to confirm your intention by typing the word “YES”:
Once your request is sent off to the other user, the board is in a frozen state: existing members of the board team can continue to view the board, but no one can make any changes:
If you change your mind, you can cancel the request before it has been accepted. This can be done by selecting the board from your Home Page:
You can also find your pending request in your Sentbox, and cancel it from there:
Note: once a board’s transfer is complete, it can’t be undone by you. If you really need to get ownership back of a board, you will need to ask the new owner to transfer the board to you.
An important caveat for Kerika+Google users
We try to ensure that files attached to a Kerika+Google board have their ownership changed at the same time as the board itself is transferred, but there are some limits to how Google will allow for a change in ownership:
All Kerika-related files are stored in a set of folders in a user’s Google Drive, organized by account and board.
Google let’s us change the owner of a folder, so we can make sure that when a board is transferred the ownership of the associated Google Drive folder is also changed.
However, for the individual files contained within the folder, Google only allows for a change of ownership of files that are part of Google Docs: documents, spreadsheets, presentations, forms, etc.
Files like images (.jpg, .png, .gif), zip files, and PDFs, for example, retain their old ownership between the Google API doesn’t let Kerika change the ownership of these “non-Google-formatted” file types.
If you have signed up directly with Kerika, we use the Box Platform to store your files for you — Box is a secure, reliable cloud service and we have been a partner with them for several years.
But we do all this for you: efficiently, quietly and behind the scenes.
Which means you may never notice (and, really, you shouldn’t have to…)
However, we found that some users automatically block third-party cookies (this is a browser setting available in all types of browsers).
This was causing problems for the preview function for these users: when a user clicks on a file attached to a card or canvas, that’s getting stored in Box by Kerika for that user, we use Box’s Preview function in the form of an IFRAME.
Using an IFRAME enables us to add some Kerika-specific features, like automatic version tracking, to the standard Box Preview function.
This, however, requires users to allow Box.com to set a cookie, and this can fail if the user has never permitted Box.com to set cookies, or is automatically blocking all third-party cookies in their browser: when you are using Kerika.com, Box.com is effectively a third-party to the connection.
We want to make sure people understand this can be a problem, so we have added some smarts to Kerika to detect when people who have signed up directly are blocking Box.com.
If this is the case, a pop-up dialog box will appear explaining why the Preview function won’t work correctly without allowing Box.com’s cookies to be stored in the browser.