Un forfait Xuda est un enregistrement à quinze champs, dont quatre sont lus par le backend.
Les sept paliers d'abonnement sont des enregistrements dans PLAN_OBJ : config.json:1820 free, :1850 pro, :1880 team, :1910 agency, :1940 enterprise_t1, :1969 enterprise_t2, :1998 enterprise_t3. Chacun porte une carte de fonctionnalités identique de quinze clés, cinq numériques et dix textuelles, et l'ensemble des clés est le même pour les sept, si bien qu'un palier privé d'une capacité l'indique par N/A plutôt que de supprimer la clé. Quatre de ces quinze clés sont lues par du code en exécution : projects et team_members par validate_user_plan (account_module:3932 et :3947), drive et ai_credits par get_effective_entitlements (:666-701). Les onze autres, y compris les huit chaînes de capacité Available et N/A, ne sont lues par rien. Ce qui décide si une méthode s'exécute relève d'un registre distinct : 30 des 1010 entrées de cpi_methods dans config.json portent un min_plan, et http_module compare les rangs de forfait à cette valeur à chaque requête (:542-547, appliqué à :868). L'abonnement n'est d'ailleurs que l'une des seize catégories de forfaits du même objet, 7 enregistrements sur 72, si bien que le reste du prix forme un ensemble d'échelles qui s'empilent à côté de lui plutôt qu'à l'intérieur.
Clés de fonctionnalités sur chaque enregistrement d'abonnement, le même ensemble pour les sept
Parmi ces quinze, celles que du code en exécution lit réellement
Sur 1010 cpi_methods portant un min_plan, le verrou qui refuse réellement
Catégories de forfaits dans PLAN_OBJ, dont l'abonnement fait partie
Les sept paliers et les cinq chiffres de chacun, tels qu'enregistrés.
Voici les cinq clés numériques de la carte de fonctionnalités de chaque enregistrement d'abonnement, reproduites telles quelles sans reformatage. Un champ nommé plan_category répartit les sept en 4 standard et 3 enterprise, et chaque enregistrement porte aussi un titre d'un mot : Try, Deploy, Colab, Sale, Sync, Host, Own. Un champ note n'est renseigné que sur deux enregistrements, pro affichant Best Value et team affichant Most Popular, tandis qu'agency porte une chaîne vide. Instances affiche 0 sur les trois paliers du bas plutôt que d'être laissé vide, car agency à 500 étant la première valeur non nulle est précisément l'intérêt de cette ligne. Seul enterprise_t3 utilise la chaîne unlimited, et il l'utilise dans les cinq cellules ; planFeatures.js:5-15 énonce la règle de lecture que la plateforme s'impose : un nombre est toujours un plafond réel et seule cette chaîne littérale signifie illimité, c'est pourquoi aucun grand nombre de ce tableau n'est retranscrit sous forme de mot. La limite honnête relève du même paragraphe : PLAN_OBJ ne porte aucun champ de période de facturation sur les sept enregistrements, si bien que la lecture mensuelle vient du moteur de rendu, pricing.vue:129 et :359, et non de l'enregistrement.
Projets | Membres de l'équipe | Instances | Go de Drive | Crédits IA | |
|---|---|---|---|---|---|
| Free, 0 $ | 5 | 1 | 0 | 15 | 30 |
| Pro, 49 $ | 50 | 2 | 0 | 50 | 600 |
| Team, 149 $ | 250 | 100 | 0 | 250 | 1600 |
| Agency, 399 $ | 1000 | 1000 | 500 | 1000 | 3500 |
| Enterprise T1, 1 999 $ | 5000 | 5000 | 2000 | 5000 | 10000 |
| Enterprise T2, 4 999 $ | 10000 | 10000 | 5000 | 10000 | 50000 |
| Enterprise T3, nous contacter | illimité | illimité | illimité | illimité | illimité |
Quinze clés entrent. Quatre en ressortent.
La carte de fonctionnalités n'est pas un objet de paramètres que la plateforme consulte. Ce sont quinze clés dont quatre ont un consommateur, et ces quatre ne se comportent pas de la même façon : deux d'entre elles refusent un appel avec un code, et deux se contentent de fournir un nombre que quelque chose d'autre dépense ou facture. Les onze restantes n'ont aucun lecteur, nulle part dans cpi, dashboard/src ou shared.
Deux des quinze peuvent vous arrêter, et les deux ne sont qu'un simple supérieur-ou-égal.
validate_user_plan (account_module:3891) n'appelle pas get_effective_entitlements et ne partage aucun code avec elle. Elle comptabilise les applications master du compte à partir d'une vue CouchDB, lit PLAN_OBJ[membership_plan].features directement sur l'enregistrement, puis compare. Les deux branches ne se déclenchent que lorsque app_obj.app_type vaut master, et le projet système propre au compte est exempté par !app_obj.is_account_project, si bien qu'un compte au plafond peut toujours se connecter plutôt que d'être bloqué hors de ce qui lui permettrait justement de passer à un forfait supérieur.
- Projects : la comparaison est ret_obj.master >= plan.features.projects à :3932, appelée depuis app_module:1282 et :1301, soit au moment de la création d'un projet.
- Team members : le comptage de la vue >= plan.features.team_members à :3947, appelé depuis team_module:265, :675 et :1280, si bien que chaque chemin de partage passe par la même ligne.
- Les campagnes publicitaires sont purement et simplement exemptées à :3894, et tout app_type autre que master contourne entièrement les deux plafonds. Quels types d'application empruntent réellement ce chemin n'a pas été tracé, et cela reste NON VÉRIFIÉ.
- Deux des chemins de partage d'équipe n'atteignent jamais un refus propre : team_module:271 et :1286 exécutent chacun return ret; avec un commentaire déjà présent dans le code indiquant ret not defined, si bien que le plafond de sièges déclenche une ReferenceError au lieu de renvoyer l'objet -9. Ce que l'utilisateur voit finalement sur ces deux chemins reste NON VÉRIFIÉ.
- Compter les applications masterÀ partir d'une vue CouchDB, à l'exclusion du projet système propre au compte
- Lire l'enregistrement du forfaitPLAN_OBJ[membership_plan].features, directement depuis la config, sans passer par l'assistant de droits
- Comparer, supérieur ou égalret_obj.master >= plan.features.projects, et l'appel de création s'arrête là
- Compter les partages d'équipe actifsLa seconde vue, la seconde comparaison, le second code de refus
Les deux refus de quota ne sont pas la phrase soignée que rédige le verrou de capacité.
Le verrou de capacité compose son message à partir du nom d'affichage de la méthode et des noms d'affichage de PLAN_OBJ (http_module:555-562) : il nomme donc la fonctionnalité, nomme le forfait et nomme la montée en gamme. Les deux refus de quota ne font rien de tout cela. Ce sont des littéraux de gabarit qui interpolent la clé interne du forfait plutôt que de la résoudre, ils sont mal formés grammaticalement, et ils n'indiquent aucun chemin de montée en gamme. app_module:1287 et :1306 renvoient l'objet à l'appelant sans modification, si bien que rien entre le contrôle et le client ne les réécrit. La ligne -8 ci-dessous est imprimée avec un jeu de valeurs concret, un compte agency à son plafond de 1000 projets ; partout ailleurs, les chevrons représentent un champ rempli au moment de l'appel, seule façon honnête d'imprimer une chaîne dont les valeurs n'existent pas avant l'appel.
Le mot unlimited est traité deux fois, et une seule fois délibérément.
Enterprise T3 est le seul palier dont les cinq quotas numériques sont la chaîne unlimited plutôt qu'un nombre, et deux fonctions distinctes rencontrent cette chaîne sur deux chemins de code différents. dashboard/src/lib/planFeatures.js:5-15 énonce le contrat que la plateforme entend respecter : un nombre est toujours un plafond réel, et seul le mot littéral unlimited signifie illimité. get_effective_entitlements respecte ce contrat délibérément. validate_user_plan le respecte par accident. Les deux voies ci-dessous répondent aux quatre mêmes questions dans le même ordre et arrivent au même résultat, ce qui explique précisément pourquoi la différence mérite d'être illustrée plutôt que simplement décrite.
Ce que cette page ne peut pas vous dire sur les chiffres ci-dessus.
- Tout ce qui précède a été lu dans le code source du dépôt, sur la branche main avec des travaux non validés dans l'arborescence, et rien ici n'a été exécuté contre un compte réel. Là où le dépôt et une machine en production divergent, cette page a tort et la machine a raison.
- PLAN_OBJ ne porte aucun champ de période de facturation sur les sept enregistrements. La lecture mensuelle vient du moteur de rendu, website-nuxt/pages/pricing.vue:129 et :359, plutôt que de l'enregistrement, si bien que chaque prix ci-dessus n'est mensuel que parce que la page qui l'affiche le dit.
- Aucun tarif annuel n'existe où que ce soit dans PLAN_OBJ. pricing.vue:476 indique que l'offre annuelle est réduite et invite à contacter les ventes, si bien qu'aucun chiffre annuel ni aucun pourcentage annuel n'apparaît nulle part sur cette page. Une remise que nous ne pouvons pas lire dans un enregistrement est une remise que nous n'imprimerons pas sur une carte.
- Que les sept chaînes price_id correspondent à des prix Stripe réels à ces montants n'a pas été vérifié. Seules les chaînes de la config ont été lues. Le price_id diffère aussi selon l'environnement, ce pourquoi aucune page ne devrait jamais en afficher un.
- La mémoire indique que config.json diverge de la config master en production, laquelle n'a pas été lue ici. Chaque chiffre ci-dessus fait autorité uniquement au niveau du dépôt, et les copies du dépôt et de dev s'accordent sur les sept enregistrements, à l'exception des identifiants Stripe.
- L'application décrite ci-dessous n'a été tracée que jusqu'à la frontière HTTP. Que deploy_module revérifie plus loin l'éligibilité au datacenter ou au load balancer pour un compte Pro reste NON VÉRIFIÉ ; lisez donc le bloc suivant comme ce que décide la porte d'entrée.
Le verrou qui refuse réellement une fonctionnalité n'ouvre jamais la carte de forfait.
La carte de fonctionnalités d'un enregistrement d'abonnement est une description d'un forfait, pas un mécanisme. Le mécanisme est un tout autre registre, cpi_methods dans config.json, lu à chaque appel entrant par http_module. Il ne consulte jamais la carte de fonctionnalités : il consulte un champ optionnel de la méthode appelée, et décide au moyen d'une simple comparaison de rang.
Huit chaînes de capacité, cinq appliquées ailleurs, trois appliquées par rien.
Dix des quinze clés de fonctionnalités sont des chaînes, et huit de ces dix sont binaires : N/A jusqu'à ce qu'un palier les active, puis actives pour tout palier supérieur, l'échelle étant strictement monotone, si bien que rien d'actif au rang N n'est inactif au rang N+1. Comme agency en active deux et enterprise_t1 en active deux également, les huit verrous se répartissent sur six paliers distincts plutôt que huit. Aucune des huit chaînes n'est lue par le moindre code. Voici ce que chacune vaut réellement.
Ce qu'affirme la carte de forfait | Ce qui l'applique réellement | Verdict | |
|---|---|---|---|
| deploy | N/A sur Free, Available à partir de Pro | min_plan pro sur deploy_spa, deploy_mpa, deploy_pwa, deploy_embed, deploy_api, deploy_cron, deploy_emitter, deploy_preview, deploy_user_group et deploy_another | Concordant, sauf que deploy_mini_app porte min_plan free |
| marketplace | N/A jusqu'à Agency | min_plan agency sur deploy_marketplace, deploy_instance, create_marketplace_listing, update_marketplace_listing et update_marketplace_listing_stat | Concordant |
| upload plugin | N/A jusqu'à Agency | min_plan agency sur upload_plugin | Concordant |
| datacenter sync | N/A jusqu'à Enterprise T1, 1 999 $ | min_plan pro sur deploy_datacenter, soit 49 $ | La carte est plus stricte que le code, et c'est le code qui s'exécute |
| load balancer | N/A jusqu'à Enterprise T1, 1 999 $ | min_plan pro sur deploy_load_balancer, soit 49 $ | La carte est plus stricte que le code, et c'est le code qui s'exécute |
| outsourced server | N/A jusqu'à Enterprise T2 | Rien. Aucun résultat dans cpi, dashboard/src ou shared, sous aucune orthographe | Une promesse, pas un verrou |
| xuda sdk | N/A jusqu'à Enterprise T3 | Rien, selon la même recherche exhaustive | Une promesse, pas un verrou |
| ai priority | N/A jusqu'à Team | Rien, selon la même recherche exhaustive | Une promesse, pas un verrou |
Trente méthodes sur 1010 portent un plancher de forfait, et aucune ne dépasse Agency.
Le registre des verrous est cpi_methods dans config.json : 1010 entrées, dont 30 portent un min_plan et une porte un min_support_plan. Les planchers sont pro pour 19, agency pour 6, team pour 4 et free pour 1. Aucune méthode nulle part ne porte un min_plan supérieur à agency, si bien que les trois paliers enterprise ne débloquent rien à ce verrou, et ce qu'ils modifient, ce sont les cinq chiffres. Un plancher de la config est tout simplement erroné : set_credit_rules lit min_plan pro alors qu'account_module:9339 refuse tout ce qui est en dessous de Team avec les mots Credit management is available on the Team plan. Le code est le verrou le plus strict.
- Pro, 19 méthodes. Dix appartiennent à la famille deploy : deploy_spa, deploy_mpa, deploy_pwa, deploy_embed, deploy_api, deploy_cron, deploy_emitter, deploy_preview, deploy_user_group et deploy_another. Les neuf autres sont deploy_datacenter, deploy_load_balancer, app_visibility_off, set_login_screen, generate_login_screen, change_under_attack_mode, enable_app_branding, create_stripe_account_link et set_credit_rules.
- Team, 4 méthodes : add_developer_member, add_admin_member, add_login_sponsor et list_sponsored_users. Ainsi, le droit d'inviter un développeur dépend du rang, et le nombre d'invitations possibles dépend du chiffre team_members. Deux mécanismes sur un seul écran.
- Agency, 6 méthodes : upload_plugin, deploy_marketplace, deploy_instance, create_marketplace_listing, update_marketplace_listing et update_marketplace_listing_stat.
- Free, 1 méthode : deploy_mini_app. Un plancher qui admet tout le monde, et la raison pour laquelle la carte de fonctionnalités indiquant deploy N/A sur Free ne dit pas tout.
- free1 méthode, deploy_mini_app, verrouillée à un plancher que tout le monde atteint déjà
- pro, rang 119 méthodes, la famille deploy plus neuf contrôles d'application et de compte
- team, rang 24 méthodes, toutes relatives à l'ajout d'une personne au compte
- agency, rang 36 méthodes, publication sur le marketplace et de plugins, et le plancher le plus élevé du fichier
Seize échelles partagent un même objet, et exactement deux d'entre elles modifient votre allocation.
PLAN_OBJ contient 72 enregistrements de forfait répartis sur 16 catégories, dont 7 pour l'abonnement. Une seule fonction répond à ce à quoi un compte a réellement droit, et elle lit trois champs de forfait sur les seize : membership_plan, ai_workspace_plan et drive_plan. Tout le reste de cet objet verrouille son propre module sur son propre axe et ne touche jamais à vos crédits ni à votre stockage.
Les seize échelles, leurs paliers et leurs plafonds.
PLAN_OBJ contient 72 enregistrements de forfait répartis sur ces seize catégories, dont seulement 7 pour l'abonnement. Les quinze autres comptent 65 paliers à elles toutes, et chacune des quinze possède un palier à 0 $, si bien que chaque échelle est un choix plutôt qu'un mur auquel on se heurte. Les prix ci-dessous correspondent au champ price des enregistrements, des prix catalogue mensuels en USD dans la config du dépôt. La troisième colonne est le cœur du propos : exactement deux des quinze modifient la valeur de votre allocation d'abonnement, car get_effective_entitlements ne lit que membership_plan, ai_workspace_plan et drive_plan, et ne renvoie que ai_credits et drive_gb. Les treize autres verrouillent leur propre module, leurs propres produits, boîtes mail, tickets et commissions, et ne touchent jamais à vos crédits ni à votre stockage. Xucode est le seul produit verrouillé par le rang d'abonnement plutôt que par sa propre échelle : xucode_entitlement (deploy_module/xucode.mjs:32-66) compare le rang du compte à config.json:414 min_membership pro, et un identifiant d'abonnement non reconnu échoue fermé, c'est-à-dire aucune machine plutôt qu'une machine gratuite.
Paliers | Prix mensuel le plus élevé | Modifie votre allocation d'abonnement | |
|---|---|---|---|
| membership | 7 | 4 999 $, et le palier le plus haut est le mot call | C'est l'allocation elle-même |
| ai_workspace | 8 | 230 $US | Oui, crédits et stockage, uniquement sur un abonnement payant |
| drive | 4 | 39 $US | Oui, stockage, sur chaque palier, y compris free |
| profile_phone | 6 | 39 $US | Non |
| support | 4 | 4 500 $US | Non |
| trust_center | 4 | 299 $US | Non |
| commerce | 4 | 149 $US | Non |
| shipping | 4 | 149 $US | Non |
| tickets | 4 | 149 $US | Non |
| marketplace | 4 | 149 $US | Non |
| finance | 4 | 79 $US | Non |
| bot_protection | 4 | 59 $US | Non |
| xucode | 3 | 59 $US | Non, et c'est la seule échelle avec un plancher d'abonnement |
| 4 | 49 $US | Non | |
| auto_response | 4 | 49 $US | Non |
| static_website | 4 | 39 $US | Non |
Cinq choses sur les quinze autres échelles que cette page n'imprimera pas.
- Deux paliers ai_workspace divergent entre config.json et config_dev.json de deux ordres de grandeur, et ce sont les deux seuls écarts de prix parmi les 72 enregistrements, si bien qu'aucun chiffre pour l'un ou l'autre n'apparaît nulle part sur cette page.
- Chaque palier payant de email, tickets, trust_center et auto_response ne porte aucun price_id, et trois des cinq paliers payants de phone non plus. stripe_module:251-258 traite un price_id manquant comme de l'argent qui n'est pas une ligne d'abonnement, et désigne phone comme facturé par numéro et email par boîte mail. Aucune facturation par ressource de ce type n'est désignée pour tickets, trust_center ou auto_response, si bien que leur facturabilité actuelle reste NON VÉRIFIÉE.
- config.json:414 fixe xucode.enabled à false aux côtés de min_membership pro, si bien que Xucode possède trois paliers tarifés, un plancher Pro, et n'est peut-être pas achetable du tout à l'heure actuelle.
- L'avantage membre est une simple substitution de prix sur une seule catégorie. Chaque enregistrement ai_workspace payant porte un member_price_id, et aucune autre catégorie ni aucun palier d'abonnement n'en possède. Le commentaire du code source à stripe_module:211-223 le décrit comme 10 % de réduction, portée comme un prix à 90 % sur le même produit Stripe. Les montants résident dans Stripe plutôt que dans le dépôt, si bien qu'aucun chiffre en dollars pour les membres n'apparaît ici.
- De nombreux paliers de complément portent un price_id provisoire, et stripe_module:226-300 génère désormais un prix Stripe réel à partir du champ price propre à l'enregistrement du catalogue, lors de la première vente, avec une clé de recherche déterministe pour qu'un redémarrage ou une autre région retrouve le même prix plutôt que d'en générer un second. C'est pourquoi le chiffre de la config est le chiffre effectivement facturé pour ces échelles. Lu depuis le code source, jamais testé contre Stripe en production.
Une montée en gamme encaisse l'argent avant d'accorder le forfait.
Chaque compte démarre sur l'article d'abonnement free, si bien qu'acheter un palier revient à retarifer cet unique article d'abonnement plutôt qu'à créer un nouvel abonnement, et stripe_update_plan détermine la direction en comparant le rang à l'intérieur de la catégorie (:1770-1787). Ce qui suit n'est pas un changement de forfait qui vous facture ensuite. C'est une charge qui, une fois seulement qu'elle est acquittée, devient un changement de forfait.
Le chiffre sur le bouton est le chiffre facturé.
stripe_get_proration renvoie une enveloppe normalisée plutôt qu'une facture Stripe brute, portant direction, plan_name, currency, renewal_amount, renewal_date, amount_due_now et des proration_lines détaillées (:446-500), et le récapitulatif de paiement affiche exactement cela, rien de plus. Le commentaire du code consigne le bug ainsi corrigé : l'ancienne version affichait la prochaine facture entière alors qu'elle ne facturait que l'écart.
Une carte refusée bloque le compte avant de suspendre quoi que ce soit.
Deux indicateurs du document de compte portent l'essentiel de ce mécanisme, account_billing_hold_status et account_suspension_status. Les deux sont activés par le webhook invoice.payment_failed, et les deux sont désactivés par un webhook différent plutôt que par une action manuelle d'un agent support. L'écart entre le premier et le second représente trois tentatives supplémentaires sur la même facture, et seul le second interrompt le service de vos applications.
- 01
Premier échec : un blocage de facturation
account_billing_hold_status passe à 1 avec un horodatage et une entrée de journal du compte (stripe_module:1945-1949), et le même gestionnaire envoie un courriel au client. Le tableau de bord affiche une bannière listant les factures impayées et le total dû avec un bouton Tout payer, et indique que certaines actions du compte sont bloquées, formulation honnête car la liste complète n'est énumérée nulle part en un seul endroit. Le marketplace refuse purement et simplement un achat tant que le blocage est actif (marketplace_module:1252-1254).
- 02
Quatrième tentative : suspension
Lorsque webhook_data.attempt_count atteint 4, le même gestionnaire active aussi account_suspension_status (:1953-1958). Celui-ci n'a rien de cosmétique : router_module:5697 lève Account suspended et cesse de servir les applications du compte. Le calendrier de nouvelles tentatives derrière attempt_count relève de la configuration du tableau de bord Stripe et ne figure pas dans le dépôt, si bien que le délai calendaire jusqu'à la suspension ne peut pas être établi à partir du code source. NON VÉRIFIÉ.
- 03
Le paiement réussit : les deux sont levés
customer.subscription.updated désactive les deux indicateurs dès qu'aucun abonnement de ce client ne se trouve dans un état non actif (:1806-1822). Deux exemptions échappent totalement à tout cela : la facture de proratisation ponctuelle de montée en gamme est marquée pour qu'une montée en gamme refusée laisse le forfait actuel intact, et une liste d'autorisation de propriétaires et de superutilisateurs n'est jamais bloquée ni suspendue automatiquement.
Pourquoi cette fonctionnalité n'est-elle pas dans mon forfait ?
Six endroits où la carte de forfait et le code divergent, avec des réponses tirées du code, et les points non tranchés signalés comme tels.
Cette page explique la structure. Ces trois liens répondent au prix.
Tout ce qui précède cette ligne est mécanisme : quelle comparaison peut vous refuser, quel registre décide d'une capacité, lesquelles des quinze échelles de complément touchent votre allocation et lesquelles n'y touchent pas parmi les treize autres. Rien de tout cela ne vous dit sur quoi cliquer. Trois liens le font. Le premier est le sélecteur de paliers, avec le parcours de paiement derrière, l'unique question que cette page ne répond délibérément pas : une page qui soutient que la carte de forfait n'est pas la couche d'application ne devrait pas aussi être la page qui vend la carte de forfait. Le second est la lecture sœur sur l'unique complément qui fait varier votre chiffre de crédits. Le troisième est votre propre compte, où les chaînes citées plus haut s'affichent contre vos données plutôt que contre un exemple. Cette entrée est la sentinelle @dashboard plutôt qu'une URL, et elle passe par le même résolveur que tous les autres liens ici, si bien qu'elle atterrit là où votre tableau de bord se trouve réellement.
Les sept paliers côte à côte, 0 $, 49 $, 149 $, 399 $, 1 999 $, 4 999 $ et un septième dont le champ price est le mot littéral call plutôt qu'un nombre, avec le parcours de paiement derrière chacun.
Comparer les paliersHuit paliers, ce qu'est réellement un crédit, et pourquoi le solde affiché à côté de votre palier est un chiffre distinct du palier lui-même. Le palier relève un droit affiché ; le solde est un registre de crédits accordés moins l'usage enregistré, et aucun palier d'espace de travail n'y émet jamais de crédit. Cette page nomme aussi les deux paliers dont les chiffres divergent entre les deux fichiers de config.
Consulter l'échelleUn abonnement consolidé unique portant membership, support et AI Workspace comme trois articles sur une seule facture, les lignes de forfait en dessous, et tout changement planifié affichant sa date d'effet à côté d'un bouton Annuler qui libère le calendrier Stripe et vous laisse renouveler exactement là où vous êtes déjà.
Ouvrir la facturationLes écrans de facturation, en mouvement.
Voici l'enregistrement que le précédent document membership-plans portait déjà dans son champ youtube, conservé ici plutôt qu'abandonné. Une page assemblée à partir de clés de config, de comparaisons de rang et de chaînes de refus est un piètre moyen de regarder un écran de facturation évoluer, et cette démonstration est la partie de l'ancien document que rien dans cette refonte ne remplace. Deux règles pour la regarder. Là où la démonstration et cette page divergent sur un chiffre, c'est la page qui fait foi, car construite à partir du code source : les sept enregistrements d'abonnement dans PLAN_OBJ, les trente planchers de méthode dans cpi_methods, et les chemins d'application dans account_module, http_module et stripe_module. Et là où la démonstration montre une carte de forfait listant une capacité, gardez à l'esprit ce dont toute la page ci-dessus a parlé. La carte est un ensemble de chaînes de config qu'aucun code ne lit, le verrou qui s'exécute réellement est une comparaison de rang contre un plancher de méthode, deux des huit chaînes de capacité sont verrouillées plus bas que ne le prétend la carte, et trois sont verrouillées par rien de trouvable nulle part dans cpi, dashboard ou shared. Une visite guidée des écrans ne peut rien montrer de tout cela, car un enregistrement d'écran ne peut jamais montrer que la carte. Il se place après le mécanisme plutôt qu'à sa place pour cette raison, et il mérite d'être regardé pour la forme du parcours, où se situent les lignes de forfait, à quoi ressemble un changement planifié lorsqu'il est en attente, et ce que l'aperçu de paiement met devant vous avant de facturer quoi que ce soit.
Enregistrée avant la rédaction de cette page, donc tout chiffre affiché à l'écran doit être considéré comme exact à sa date d'enregistrement plutôt qu'à la lecture de config ci-dessus. Chaque chiffre de cette page provient de config.json et du code source cpi qui l'accompagne, et non de cette vidéo. Il est également établi que les copies dans le dépôt de config.json et config_dev.json divergent de la config master en production, si bien qu'un prix prononcé dans la démonstration, un chiffre des tableaux ci-dessus et le montant réellement facturé à un compte sont trois affirmations distinctes. Seule la médiane a été vérifiée ici.
Ouvrez l'écran de facturation et lisez votre propre enregistrement.
Votre abonnement tient en une chaîne sur le document de votre compte, membership_plan, qui porte la clé de l'un des sept enregistrements, et tout ce qui précède décrit ce à quoi cette chaîne est comparée. Deux comparaisons peuvent purement et simplement vous refuser, et ce sont deux simples tests numériques sur la carte de fonctionnalités : votre nombre de projets contre features.projects et vos partages d'équipe actifs contre features.team_members, à account_module:3932 et :3947. Les deux affichent une phrase nommant le plafond, renvoyée sous le code -8 et le code -9, et les deux nomment la clé interne du forfait plutôt que le nom d'affichage. Chaque capacité est décidée ailleurs, entièrement, par un registre de trente planchers de méthode dans cpi_methods comparés par rang à http_module:868, et cette comparaison ne lit jamais la carte de forfait. Deux des quinze autres échelles modifient votre allocation, AI Workspace et Drive, et treize non, car get_effective_entitlements lit exactement trois champs de forfait et renvoie exactement deux nombres. Quatre choses sont désormais vérifiables sur votre propre écran plutôt que sur une promesse. La ligne de forfait montre le palier réellement détenu par votre compte. Un changement planifié affiche sa date d'effet et le bouton Annuler qui le libère, jusqu'au moment où il prend effet. L'abonnement consolidé affiche membership, support et AI Workspace comme des lignes sur une seule facture plutôt que comme trois factures distinctes. Et le solde de crédits affiché à côté du palier est un chiffre de registre, ce qui explique précisément pourquoi ce n'est pas le nombre figurant sur la carte de forfait. Rien n'est facturé par la simple consultation. Si votre abonnement est free, notez au passage la règle d'empilement unique : le complément AI Workspace n'est comptabilisé que lorsque l'abonnement est défini et différent de free, si bien qu'un palier d'espace de travail payant sur un abonnement free n'ajoute ni ses crédits ni son stockage. Que le paiement empêche ou non cet achat de se produire n'a pas été tracé, et cette page le dit plutôt que de le supposer.