Planes y cobros del equipo

Todo lo relacionado con precios viene de Weblabor Base: planes, precios por país e intervalo, complementos, límites, Stripe Checkout, el portal de facturación y los formularios del panel de administración. Ve Enciende planes y cobros y Crea y pon precio a un plan en el sitio de la base para todo eso. Esta guía cubre sólo lo que cambia cuando el cliente es un equipo.

El equipo es el cliente

El kit trae un segundo adaptador de cobros, packages/billing-team, junto al packages/billing-core de la base. La base le cobra a un User; este adaptador le cobra a un Team. Cada equipo tiene su propia fila BillingAccount, su propio cliente de Stripe, su propia suscripción y sus propios derechos de uso. Nada del cobro se guarda en la persona.

BILLING_TEAM_ENABLED=true
BILLING_USER_ENABLED=false

BILLING_TEAM_ENABLED registra el adaptador de equipos. BILLING_USER_ENABLED registra junto a él el adaptador de usuarios de la base, que sólo quieres cuando tu producto le vende a personas y a equipos al mismo tiempo. Tal como viene, el adaptador de usuarios está apagado, así que /account/plans y las demás páginas de cobros de la cuenta de la base no existen: las páginas del equipo las reemplazan.

Los interruptores de la base siguen aplicando encima: FEATURE_PLANS_ENABLED y FEATURE_ADDONS_ENABLED encienden o apagan los planes y los complementos para todos.

Dónde lo administra el equipo

Estas quedan fuera de la verificación de suscripción que protege el resto del espacio de trabajo, así que un equipo cuyo plan terminó, o que debe dinero, todavía puede llegar a ellas y pagar. El propietario y los miembros con manage plans en el guard team las ven; a todos los demás se les regresa al tablero del equipo con un mensaje que dice que le pidan acceso a un administrador del equipo, y el menú no les ofrece los enlaces en primer lugar.

Cada una de ellas le pertenece al equipo, no a quien la abre. Un miembro que además paga una cuenta personal propia nunca aterriza en sus propias páginas de cobros desde dentro de un equipo: los complementos, las páginas de detalle y el regreso de Stripe se quedan en el equipo activo.

El plan gratuito

Cuando los planes están encendidos y existe un plan gratuito, la primera visita del equipo a /team lo suscribe al plan gratuito sin preguntar. Por lo tanto un equipo siempre tiene una suscripción, y el middleware ensure.subscribed lo deja trabajar hasta que necesita más.

Límites contados por equipo

Los límites del plan se declaran y se les pone precio en el panel de administración como en la base. Lo que cuenta cada uno es app/Classes/TeamPlanLimits.php, la versión para equipos del PlanLimits de la base:

Agrega un método público por cada límite que tu producto necesite, con la clave como nombre y el equipo actual como argumento opcional, y una variante Daily cuando lo quieras en las gráficas de uso:

public function projects(?object $owner = null)
{
    $team = $owner ?? team();
    return $team ? $team->projects()->count() : 0;
}

El tablero en /team muestra cada límite con lo que el equipo ha usado. En código, team()->reachedLimit('users') responde si el equipo está en el límite; la policy de miembros lo llama antes de dejar que alguien agregue un miembro.

Vender miembros por encima del plan

Nada de esto necesita código. Un plan gratuito, un plan de pago con diez miembros incluidos y un complemento Miembro extra cobrado por unidad son tres registros que se crean en el panel de administración:

La clave del límite es users, no "miembros": el panel lista los nombres de los métodos de app/Classes/TeamPlanLimits.php tal como están escritos. Se vende por unidad es lo que hace que la cantidad importe — el equipo elige cuántas quiere, y el precio y los límites se multiplican por ella. Un complemento que se vende por unidad tiene que llevar al menos un límite, que es para lo que está la fila users; no necesita ninguna capacidad, así que deja Capacidad vacía.

Tal como viene el kit, el adaptador de equipos es el único registrado, así que el formulario del complemento no muestra el campo Contexto y el complemento llega al catálogo del equipo tal cual. Ese campo aparece sólo cuando el adaptador de usuarios de la base está registrado junto a él, como describe la última sección de esta guía, y ahí eliges el equipo.

Una vez que existen los tres registros, un equipo en el plan de pago con cuatro unidades de Miembro extra tiene catorce lugares. /team/members/create rechaza el decimoquinto, sea miembro o invitación, con "Has alcanzado el número máximo de Usuarios permitido por tu suscripción". El equipo lo supera comprando más unidades en /team/add-ons o pasándose a un plan más grande, y los lugares nuevos cuentan desde ese momento. Una invitación pendiente ocupa un lugar igual que un miembro activo, como dice la tabla de límites de la sección anterior, y quien creó el equipo ya ocupa uno — que es la razón por la que un equipo en el plan gratuito de este ejemplo no puede invitar a nadie hasta que compre una unidad.

El mecanismo de venta por unidad es de la base, y ahí está documentado: Vende complementos, en "Por unidad y por escalones".

Complementos y capacidades

Un complemento enciende una capacidad. Las capacidades que un equipo puede comprar se declaran como métodos públicos de app/Classes/TeamPlanFeatures.php, la versión para equipos del PlanFeatures de la base; el nombre del método es la clave de característica que el administrador elige en el formulario del complemento, y el método responde si la capacidad está liberada en el código. La clase viene vacía, así que declara una antes de crear un complemento para equipos:

public function advancedReports()
{
    return true;
}

Verifícala con team()->hasFeature('advancedReports'), un sinónimo permanente de team()->hasAddOn(). Una policy no la llama: declara protected $requiredFeature en la policy y App\Policies\BasePolicy revisa por su cuenta los derechos de uso del equipo para esa llave, antes de que corra cualquiera de los métodos de la policy. A quien no tenga equipo actual se le niega ahí: la guarda falla cerrada, porque sin equipo no hay derechos de uso que leer. La columna features del equipo es una caché que la cuenta de cobros mantiene al día; la decisión siempre son los derechos de uso de la cuenta, así que una compra de por vida sobrevive a un plan que deja de incluir el complemento.

Desde el panel de administración

/admin/teams muestra cada equipo con su plan y le permite a un administrador encender o apagar un complemento para él, desde el mismo panel que la base usa para los usuarios. Ve Equipos en el panel de administración.

Vender a personas y a equipos

Pon BILLING_USER_ENABLED=true para registrar ambos adaptadores. Las páginas de cobros de la cuenta de la base regresan para la persona, las páginas del equipo se quedan para el equipo, y cada plan y complemento declara en el formulario del panel de administración si es para usuarios, para equipos o para ambos.