leepa

Key Per Tier Fulfilment — Implementation Plan

Context

The current fulfilment system only supports "key per product" — each product in a tier maps to a Keystone key group, and one key is extracted per product at order time. Software bundles need a "key per tier" mode where a single activation key represents the entire tier (all products in it), rather than individual product keys.

Design Decisions

• No enum: There is no fulfilment_type field. Both product-level (ProductKeyGroupMappingConfig) and tier-level (TierKeyGroupMappingConfig) key mappings are optional on any tier. The system simply extracts keys from whatever is configured.
• Validation at publish time: When a bundle goes on sale, validate that every tier has at least one key mapping (product-level OR tier-level). This prevents misconfiguration without over-constraining the admin during setup.

leepa

Key Per Tier Fulfilment — Implementation Plan

Context

The current fulfilment system only supports "key per product" — each product in a tier maps to a Keystone key group, and one key is extracted per product at order time. Software bundles need a "key per tier" mode where a single activation key represents the entire tier (all products in it), rather than individual product keys.

Design decision: fulfilment_type lives on BundleTierConfig (per-tier, not per-bundle) so that individual tiers within the same bundle can use different fulfilment strategies. For example, a bundle could have Bronze (KEY_PER_PRODUCT: 3 games, 3 individual keys) and Gold (KEY_PER_TIER: 1 license key covering all Gold content). A single order can contain both GameKey and TierKey objects.

Design Decisions

leepa

Analysis: Frontend-Only Sub-Products vs Key Per Tier

Context

The Key Per Tier plan proposes adding fulfilment_type at the BundleCommerceConfig level with a new TierKeyGroupMappingConfig model, new DTO (TierKey), service-layer branching, admin UI, and claim page updates.

An alternative idea was proposed: create "sub-products" that only exist on the frontend, so the OMS still treats everything as one product and doesn't need changes.

This document walks through what the current code actually does and where that approach runs into problems.

leepa

Key Per Tier Fulfilment

Context

The current fulfilment system only supports "key per product" - each product in a tier maps to a Keystone key group, and one key is extracted per product at order time. Software bundles need a "key per tier" mode where a single activation key represents the entire tier (all products in it), rather than individual product keys. This is a substantial schema departure requiring changes across models, DTOs, services, admin UI, and frontend display.

Design Decisions (confirmed with user)

• Scope: fulfilment_type lives on BundleCommerceConfig (bundle level, not per-tier)
• Cumulative: Config boolean cumulative_fulfilment controls whether customer gets keys for all tiers up to purchased (True) or just the purchased tier (False)

leepa

version: 0.2

phases:
  install:
    runtime-versions:
      docker: 19
    commands:
      - docker version
      - curl -JLO https://github.com/docker/buildx/releases/download/v0.4.2/buildx-v0.4.2.linux-amd64
      - mkdir -p ~/.docker/cli-plugins

leepa

SSO Sync

Helping you populate AWS SSO directly with your Google Apps users

Runs on any platform that Go can build for.

Why?

As per the AWS SSO Homepage:

leepa

    const cluster = new bottle.BottlerocketCluster(this, 'Cluster');

    const ami = ssm.StringParameter.valueForStringParameter(this, '/aws/service/bottlerocket/aws-k8s-1.15/x86_64/latest/image_id');

    cluster.node.findAll().forEach(s => {
      if (s instanceof asg.CfnLaunchConfiguration) {
        const asg = s as asg.CfnLaunchConfiguration;
        asg.imageId = ami;
      }
    });

leepa

import cdk = require('@aws-cdk/core');
import autoscaling = require('@aws-cdk/aws-autoscaling');
import ec2 = require('@aws-cdk/aws-ec2');
import eks = require('@aws-cdk/aws-eks');
import iam = require('@aws-cdk/aws-iam');

import fs = require('fs');
import path = require('path');
import { safeLoadAll, safeLoad } from 'js-yaml';

leepa

extern crate lambda_runtime as lambda;

#[macro_use]
extern crate log;

extern crate simple_logger;
extern crate serde_derive;
extern crate chrono;

use lambda::{error::HandlerError, lambda};

leepa

#[derive(Deserialize, Debug)]
struct S3Event {
    #[serde(rename = "Records")]
    #[allow(dead_code)]
    records: Vec<S3EventRecord>,
}

#[derive(Deserialize, Debug)]
struct S3EventRecord {
    #[serde(rename = "eventVersion")]