We are still working with Google on fixing the problem with the G Suite Marketplace that caused the Kerika product listing to disappear unexpectedly about 2 weeks ago.
Progress was slow over the holiday season because many Googlers were out of office, but folks are back in town and working with us on debugging the problem — which, as far as we can tell, is entirely on Google’s end and has to do with their back-end systems for managing listings on the G Suite Marketplace.
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…
About a week ago, the Kerika listing on the G Suite Marketplace disappeared for reasons we still don’t understand. We have been working actively with Google’s engineers to fix this, and are confident they will soon deliver a solution — the problem is on their end, not ours — and in the meantime we would like to apologize to anyone who is affected by this.
The underlying problem is that G Suite Marketplace is transitioning, and right now there are some overlapping systems in place that are creating problems for Kerika (and possibly other third-party apps).
Historically, if you wanted to publish your app on the G Suite Marketplace, you did so using the Chrome Web Store — which is where you also published your app for the Chrome Web Store, obviously.
This always led to to some confusion from our perspective: we had to maintain two identical product listings using the same Chrome Web Store Developer Dashboard. And since this process has been in place, for the past several years, Google itself has been deprecating the use of the Chrome Web Store to distribute browser-based apps through this store.
Meanwhile, the Chrome Web Store Dashboard itself is getting a much-overdue UI makeover, and while this is underway the dashboard doesn’t have all the functionality that the old dashboard does, and there, of course, some bugs remaining in the new dashboard that Google needs to iron out.
(While the old Chrome Web Store Dashboard was ugly as sin, it was old and stable. The new Dashboard is much nicer, but not quite, quite ready yet.)
And there’s also the Google Cloud Platform API Dashboard: newer than the Chrome Web Store Dashboard, and with a completely different user interface and functions, since it manages an app developer’s use of many different cloud services from Google.
This has become another place to maintain your app’s product listing, and this seems to be where our problems originated: the G Suite Marketplace currently takes some information from the Cloud Platform Dashboard, and some information from the Chrome Web Store, to define your product listing.
We have been actively working with Google’s engineers, support and product management to try to resolve this problem — and we are grateful for the attention they have been giving us — and we hope to be out of the woods soon. One unexpected benefit of these problems has been the opportunity to talk to Google about our experience as third-party app developers: hopefully our feedback can help them make the G Suite Marketplace more useful to both Google’s customers and ours 🙂
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.
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.