Which apps your organisation can install, and how the launcher finds out

Every Rutba app has a launcher. It is the switcher at the top of the screen, the apps directory on the ribbon, the list in the footer and the page the suite’s sign-in opens on. Until now it was built from two things: the full list of apps the suite ships, and the roles a person holds. It had no way to know what their organisation had actually taken.

From the next release, Rutba tells each organisation’s instance which apps it may install, and the launcher follows the list. The console’s Modules page shows the same list, app by app. Both halves are built and wait only for the release.

What your instance is told

Each organisation on Rutba has an instance of its own: its own database, which the suite’s apps read and write on its behalf. Rutba keeps the record of what the organisation holds, meaning its licence and any change somebody at Rutba has made by hand. From that record it works out a list for the instance. The list names every app in the suite, and for each one it says:

• Whether it is installed. In other words, whether the organisation may install it at all.
• Who decided. Either the licence or a person at Rutba. A decision made at Rutba wins over the licence in both directions: an app can be switched on for an organisation partway through a conversation about buying it, or switched off because the organisation asked.
• Seats. The number the licence was sold with, or none when nothing caps it.
• The keys that grant it, in the names the suite’s own checks already use.

The list is complete every time. An app it leaves out counts as not installed. We built it that way on purpose, because a list that could only add apps would have no way to take one back, and an app would sit on somebody’s launcher long after the licence that granted it had gone.

Each list also carries a number, one higher than the last one sent to that instance. The instance applies a list only when its number is above the one it already holds. A list delivered twice, or one that turns up after a newer one has landed, is turned away and changes nothing. When the instance answers, Rutba takes down the number the instance says it now holds, and makes a note of any difference between the apps it sent and the ones the instance says it installed.

Rutba sends a new list whenever a subscription issues a licence, and whenever somebody at Rutba changes what one organisation may use. An instance that does not answer is tried again on Rutba’s daily check.

What the launcher does with it

Once the list has arrived, the launcher shows an app only if Rutba has installed it for your organisation and your administrator has it switched on. Your roles still apply on top of that, as before. The switcher’s short list and the page the sign-in opens on show only what your roles let you open. The full directory, in the footer and behind All apps in the switcher, has always shown the apps you hold no role in as well, dimmed with a lock, and it still does for installed ones.

An app that is not installed appears in none of them, the full directory included. A dimmed tile for an app your organisation has not taken would only be advertising it to you, so there is no tile.

Four apps are installed whatever the list says: the sign-in, the console, Seed (where an administrator loads starter records) and the Assistant. Nothing sells them, so there is nothing to withhold, and an administrator who lost the console would have no way back in to put it right. Rutba keeps that rule when it builds the list and the instance keeps it again when the list arrives. A mistake on one side still cannot take the console away.

Until the first list reaches an instance, nothing changes there. The launcher goes on following roles alone, exactly as it does today. An instance that has never been told anything is kept apart from one that has been told nothing is installed, so a list that is late or never arrives cannot empty anybody’s launcher. Once lists are arriving, a change shows the next time you sign in or open an app.

The Modules page in your console

The console your organisation’s administrator uses, at admin.rutba.io, has a page under Apps called Modules and packages. It lists every app in the suite with what it requires and the package that sells it. Once the first list from Rutba has arrived, it gains an Installed column:

A decision made at Rutba is worded as Rutba’s on purpose. An app somebody here switched on as a favour should not look like something you bought, and one switched off at your request should not look like a licence that ran out.

The column beside it, Switched on here, is still your administrator’s. An app that is not installed cannot be switched on from this page, though one that is on anyway can always be switched off. Nothing Rutba sends touches that switch. The list carries no on or off for your side, so a licence being issued again can never turn back on an app you turned off.

What the list does not do

The list decides what the launcher offers and what the Modules page lets your administrator switch on. That is all it decides. Being installed gives nobody access to an app: each person’s roles still say what they may open and do there.

Licences are not enforced on requests yet. Requests to an app pass an entitlement check, and in production that check lets every app through for now. The list follows the same rule for now: every app we sell arrives as installed, whether or not your licence is on record yet, and only a decision somebody at Rutba took can withhold one. We will switch licence enforcement on later, for the list and the requests together, once every organisation’s licence is on record with us.

The seat figure on the Modules page is there to read. The list does not turn anybody away when it is reached. Going past a seat count is recorded in our register of every deployment, and the app keeps working.