A Flask Mega-Tutorial: Intermezzo II

I now have a bit more information on what it is I will be achieving, and I wanted to share the roadmap and horizon of the project I’m undertaking.

The software development project is called PACK — a portal or panel for administration of Kolab Groupware. For our current most important deployment, Kolab Now, this involves customers and accounting features. This would include, for example, a Web Administration Panel and a Customer Control Panel.

For the purpose of this intermezzo, we’ll simply state that some parts of the overall application suite address different needs for different audiences in different deployments. To illustrate, an on-premises installation likely has little need for third parties to be able to autonomously register themselves as customers. However, depending on the internal accounting practices of such organization, a department may need to fork over part of its budget to the IT department for providing them with collaboration services.

That being said, I’m in for quite a lengthy and complex project. On the horizon may be a rather complete encapsulation of quite a few too many things to include in a first few milestones.

As I’ve mentioned before, I’m following my own learning curve. There’s some troublesome areas in Flask and its extensions, where modelling of the applications to include multiple features based on multiple extensions is tricky. One such example is including localization (l10n), internationalization (i18n), themes, assets and caching in to one application.

Furthermore, the extent to which we wish to include features makes it very difficult to come up with a data model and database design that encapsulates everything.

So, where do we get started? Well, the use-cases that are top of mind are limited to those we have for Kolab Now and Kolab Enterprise. This means we let individual users register or sign up, and subscribe to entitlements on product offerings. This includes a nice little range of offerings, such as;

  • Knowledge base articles, some of which may be open to the public, some of which may be open for logged in users with no further entitlements on any product, some of which may be available only to users with particular entitlements. These articles form an extra on top of any amount of entitlements.
  • Subscription Management, for those on-premises installations of Kolab Groupware with long-term support and add-on software channel entitlements.
  • Individual User Accounts, which are the equivalent of the current singular @kolabnow.com groupware account.
  • Group Manager Accounts, where you register with a domain name you own, and get to create however many accounts you wish.
  • Colocated Kolab deployments, where you register with a domain name you own, and in return you get your own, managed installation of Kolab Groupware — with the intention to allow for a lot more customization and integration compared to the two former hosted account types.

Compared to how you sign up to a hosted Kolab account today, these individual entitlements should be separate from your base account. With this I mean that you should be able to create an account that holds no entitlements and requires no payment, and then subscribe to entitlements some of which may require payment right-away or at some point in the future. This parts with the current registration process, where you subscribe directly to one entitlement and one entitlement only, and the entitlement you register for will continue to be a different account for each entitlement.

To illustrate why we part with that process, we only have to look at a family situation. A couple of parents may wish to use Kolab Groupware, but would logically like to avoid two different administration accounts being issued two different invoices for the two different accounts.

Another reason to part with the current process of registration directly to individual entitlements is to encourage users to try different Kolab offerings before they commit to buying either of the forms that Kolab comes in. This immediately draws the need to be able to clearly distinguish between an account on the access portal and the accounts registered once access to the portal is obtained.

The  easiest way to let people “sign up” and explore is to allow them to identify themselves with one of their existing identities — a Twitter, Facebook or Google account is what we have currently included. However, I have since learned that that is not secure enough. I have added on top of that four second factor authentication mechanisms: Passwords, TOTP, HOTP and TAN via SMS. I have since also added registration with email and password, where we would not require you to confirm ownership of or access to the mailbox of the email address you enter before we consider it a valid login name to the portal — remember we are not issuing any entitlements to this initial registration.

We intend to then let you restrict access to your account further by at least adding the second factor, and once you subscribe to product entitlements, switch over to that new account as the canonical account for access to the portal. This scenario would be applicable should you opt for, say, an @kolabnow.com individual account, to which you could switch over the primary login, and void the third-party access. For support subscription entitlements however, this would not apply equally as much — since you would not have another account with Kolab Now to switch over to.

Suffice it to say I have learned too much to continue the Flask Mega-Tutorial in the same way I originally envisioned I would.

I’m going to have to scratch my head for a little while, to figure out what it is I want, need and require, and perhaps start over with the mega tutorial taking in to account the various things I’m going to be doing, and the seemingly iterative process of restructuring the example code layouts.