Changelog
Was ist neu?
Jede Verbesserung an der Plattform, wie sie geliefert wird.
· kamo-shared-library
Textnachrichten-Anhänge anzählen
MMS-Anhänge werden gespeichert und nicht gezählt. Sie sind auch nicht das, was sie sehen wie: VoipMessageService kodiert den Anhang als Daten: URI und schreibt es inline in VOIP_MESSAGES.ATTACHMENT_URL, so dass sie nie MinIO Objekte werden und es gibt keine Datei zu stat - die Messung ist die gespeicherte Zeichenlänge, über die Org des Gesprächs. Base64 läuft etwa ein Drittel größer als die Bytes, die es kodiert, und das aufgeblasen form ist wirklich das, was die Datenbank besetzt, so dass das ist, was gezählt wird.
· kamo-internal
Jede Speicherkategorie separat anzeigen
Anrufaufzeichnungen, Voicemails, Chat-Anhänge, HR-Ressourcen und Marketing Materialien erhalten jeweils ihre eigene Linie, anstatt eine "Dokumente und Bilder" zu teilen Reihe mit allem, was passiert, um in der gleichen Tabelle zu leben. Zwei Folgen für die Optik. Vierzehn Kategorien überschreiten, was eine kategorische Palette kann encodieren - Vergangenheit etwa acht, hinzugefügte Farbtöne aufhören zu sein separable für farbenblinde Leser und zur Dekoration werden - so Identität ist getragen von dem Etikett und der Share Bar verwendet einen Farbton rein als Größenhinweis. Und der Trend ist jetzt eine einzige Gesamtserie und nicht mehr ein Vierzehn-Wege-Stack: die Frage ein Trend beantwortet ist "ist mein Speicher wächst", und welche Kategorie es wuchs in ist die Aufgabe der Tabelle, die die Tabelle genau tut.
· kamo-shared-library
Zählen Sie jede Art von gespeicherten Datei als eigene Kategorie
Anrufaufzeichnungen, Voicemails, Chat-Anhänge, HR-Ressourcen, Marketing Materialien, Tagungsaufzeichnungen und alle Arten von Dokumenten sind alle Zeilen in imgs, nur durch ImageAssocType und alle teilen sich einen Eimer ausgezeichnet, weil Assoziation ist Metadaten und keine Speichergrenze. Melden sie als ein Single-Linie war präzise und nutzlos: für eine Produktionsorganisation versteckte sie dass 5.08 GB eines 5.09 GB Fußabdrucks Chat-Anhänge waren. Jeder Verein gehört nun zu einer Domain, so dass eine Organisation sehen kann, was ist tatsächlich verbrauchen seine Lagerung statt einer undifferenzierten Summe. StorageDomainCoverageTest macht eine Auslassung zu einem Baufehler: jeder ImageAssocType muss von genau einer Domain beansprucht werden. Unclaimed bedeutet Uploads werden gespeichert und nie in Rechnung gestellt, beansprucht zweimal bedeutet zweimal abgerechnet. Verifiziert durch probe: Entfernen HR_RESOURCE aus seiner Domain versagt der Build mit dem Grund, anstatt leise zu gehen. MEETING_RECORDINGS fasst sowohl seine Quellen, die Sitzung_mittschriften Tabelle und die MEET_RECORDING Verein. MeetRecordingService schreibt nur die ehemalige, so Sie überschneiden sich nicht.
· EmailService
Messen Sie die eigenen KamoMail-Postfächer
Gängt jede Mailbox Kamo Host und Aufzeichnungen, pro Ankunftstag, die RFC822 Bytes es hält - Kopfzeilen, Körper und kodierte Anhänge, über jeden Ordner, einschließlich Trash und Junk, da eine Nachricht im Papierkorb immer noch auf der Festplatte ist. Eine Rundfahrt pro Ordner: der Jakarta Mail IMAP-Provider erweitert FetchProfile.Item.ENVELOPE ENVELOPE INTERNALDATE RFC822.SIZE, so Größe und Ankunftsdatum kommen zusammen. Was zählt, wird entschieden, ob Dovecot Bescheinigungen für die Adresse hat, nicht durch Lesen der Provider-Einstellung. Präsenz in virtual_users IS die Definition von "Kamo speichert diese Mailbox", während eine Anbieter-Spalte abgestanden sein kann, vererbt von einem Elternteil, oder Mitte der Migration. Eine Mailbox von Microsoft oder Google ergibt keine Anmeldeinformationen und wird übersprungen, so dass seine Organisation nichts berechnet. Für wen es zählt, kommt von jeder Mailbox aus dem eigenen org_id. KamoMail ist kein einziges Mieter - Produktion hat 18 Briefkästen unter einer Organisation und 41 unter eine andere, über vier Domains vermischt - so summieren eine Domain oder die maildir würde eine Organisation für die Post eines anderen in Rechnung stellen. Adressen sind abgesenkt abgeglichen. Dovecots Benutzertabelle und maildir Pfade sind Kleinbuchstaben, während der Briefkastentisch das Gehäuse aufbewahrt, das die Mailbox erstellt hat mit, und ein Fall Mismatch hier hat bereits einmal geteilt Lieferung und Abruf über zwei verschiedene Maildir. Schützt auch /api/internal als Ganzes statt Endpunkt durch Endpunkt. Die Filter mit den Namen /api/internal/calend und /api/internal/leadcomms einzeln, so der nächste Controller, der unter diesem Präfix montiert ist - dieses - gewesen wäre erreichbar ohne Geheimnis, still und in Richtung Exposition. 6 neue Prüfungen für die Ortung, die Bearbeitung von Fällen und den nicht gehosteten Fall; 152 total, alle vorbei.
· InitializerService
Schema für die Speicherung per Postbox
************ hält, pro Briefkasten und pro Ankunftstag, die RFC822 Bytes, die Briefkasten hält. Speicherbuchhaltung hatte keine ehrliche Quelle für Mailbox-Beite: Der Suchindex umfasst nur Nachrichten, die indiziert wurden, und deckt sie unabhängig davon, wer sie speichert. ORG_ID ist denormalisiert von email_provider.mailboxes so pro Organisation Aggregation ist eine indizierte Summe, und so die Namensnennung bleibt pro Mailbox . Organisationen können auf KamoMail auf einmal und eine Domain maildir halten kann Briefkästen, die verschiedenen Organisationen gehören. Run gegen Produktion 2026-08-08; Tabelle und Indizes überprüft.
· kamo-shared-library
Messen Sie die Mail, die Kamo tatsächlich hostet, pro Mailbox
EMAIL wurde von email_metadata.search_index bezogen, was in beiden falsch war Richtungen. Es verpasste KamoMail völlig - ein Org auf KAMO_MAIL hat seine Nachrichten und Anbaugeräte im hauseigenen Dovecot maildir, 62 MB davon in Produktion, gezählt als Null. Und es hätte eine Org auf Microsoft 365 oder Google geladen haben Arbeitsraum für Post, die auf den Festplatten dieses Anbieters sitzt, wo Kamo nichts hält aber ein eigenes Suchindex. **************** ersetzt es: pro Briefkasten, pro Anreisetag, insgesamt RFC822 Bytes - Header, Body und codierte Anhänge, was ist, besetzt den maildir. Eimer am Tag statt pro Nachricht hält den Tisch proportional zu Tagen-mit-Mail, während immer noch ein beliebiges Abrechnungsfenster erlaubt wird genau statt gerundet auf ganze Monate zusammengesetzt werden. Attribution ist per mailbox über seine eigene org_id, nie pro Domain und nie pro maildir. KamoMail ist kein einziger Mieter: Die Produktion hat bereits 18 Briefkästen unter einem oder einem oder einer oder 41 unter einer anderen, in einer Tabelle über vier Domains vermischt. Eine Domain zusammenzufassen, oder die Maildir als Ganzes, würde eine Org für eine andere in Rechnung stellen Post. Schema in der Produktion überprüft, bevor diese gelandet: email_provider .mailbox_storage_days existiert mit seiner Einzigartigkeitsbeschränkung nach einem KI-Lauf.
· kamo-internal
Sagen Sie, warum Briefkastenspeicher Null lesen kann
Mailbox Bytes zählen nur die Mails, die Kamo tatsächlich hostet. Eine Organisation auf Microsoft 365 oder Google Workspace hat seine Nachrichten auf den Festplatten dieses Anbieters, so seine Mailboxes Reihe ist legitimerweise 0 - die, unerklärt, liest sich als eine gebrochene Zahl und nicht eine richtige.
· BillingService
Lassen Sie eine Plattform Admin laufen die Schnappschuss-Sweep auf Anfrage
Der Sweep ist, was macht Periode Entfernungen und Lebensdauer Summen für die hart-löschen Domains verantwortlich überhaupt, so Tage verloren, um einen Ausfall verloren gehen Dauer, es sei denn, die Lücke wird gefüllt. Warten auf den nächsten 04:20-Lauf ist kein Sanierungsplan. Der Sweep holt bereits 14 Tage auf und ist idempotent per (Org, Tag, Domain), so wiederholte Anrufe zu begleichen, anstatt doppelt zählen. Das entlarvt es nur, hinter @PlattformAdminOnly, und gibt die Zeilenzahl zurück, so dass der Anrufer sehen kann, dass es funktioniert hat.
· kamo-internal
Speichernutzung auf der Registerkarte Kontostatistik anzeigen
Auf der Registerkarte stand "Keine Nutzungsdaten für diesen Zeitraum" für jede Organisation. billingApi.getCurrentUsage() ist ein Stummel zurück { Meter: [], und UsageMeters macht seinen leeren Zustand bei null Metern - so war die Nachricht, dass der Stub berichtete, nicht die Daten. StorageUsagePanel liest den echten BillingService Endpunkt und zeigt die beiden Zahlen, die leicht nebeneinander zu verschmelzen sind: Was die Organisation hält jetzt, die fällt, wenn Dateien gelöscht werden, und was es über seine hinzugefügt hat Lebensdauer, was nicht. Neben ihnen, was diese Zeit bewegt, und ein pro-Domain-Aufschlüsselung über Dokumente, Mailboxen, Wissensbasis Medien, Treffen Aufzeichnungen und Enthüllungen. Wo eine Figur ist ein Boden und nicht eine Messung, sagt es so - eine Entfernung insgesamt ohne Öffnungs-Schnappschuss dahinter, oder eine Lebensdauer insgesamt für einen Speicherplatz das hart-deletiert seine Aufzeichnungen. Ein Chip erklärt die Rekordbasis: ein Org ist gezählt für jede Datei, die sie enthält, obwohl Kamo eine Kopie pro hash speichert. Der Trend macht nur einmal zwei Tage Geschichte existieren; ein Punkt ist kein Trend, und es zu zeichnen würde eine Geschichte bedeuten, die noch nicht gesammelt wurde. Serienfarben sind die validierte kategorische Reihenfolge - am schlechtesten neben CVD .E 9.1, am schlechtesten angrenzenden Normalsicht E 19.6 auf dieser Oberfläche. Drei sitzen unten 3:1 Kontrast, so dass die Aufschlüsselung Tabelle ist nicht dekorativ: es ist die nicht-farbige Lesung aus den gleichen Daten. Byte zählt bleiben Strings Ende to end (BillingService serialisiert Long via ToStringSerializer) und werden nur dort ausgebreitet, wo die Magnitude nachweislich sicher ist.
· BillingService
Bericht, was eine Organisation speichert
Die Registerkarte Kontostatistik hat immer gesagt: "Keine Nutzungsdaten für diesen Zeitraum", für jede Organisation, denn getCurrentUsage() in kamo-internal ist ein Stumpf Rückgabe von Null Metern und nichts dahinter jemals aggregiert Speicher. Serviert drei verschiedene Zahlen pro Speicherfläche, plus eine Gesamtzahl: - was die Organisation jetzt hält, was fällt, wenn Dateien gelöscht werden - was sie im Laufe ihrer Lebensdauer hinzugefügt hat, was nicht - was sich während der aktuellen Abrechnungsperiode bewegte Entfernung ist abgeleitet - keine Tabelle Zeitstempel eine Deaktivierung, da EmbRecordState.DATE_UPDATED ist einfügbar=false und nie aktualisiert . Eröffnung + hinzugefügt - Strom gegen die Periode Eröffnungsschnappschuss. Mit nein Eröffnungsschnappschuss fällt es zurück zu Müll Zeitstempel und meldet sich als ein Boden, anstatt eine Vermutung als Maß zu präsentieren. Lifetime ist genau, wo entfernte Reihen überleben und sammelt sich von Schnappschüssen, wo sie nicht; beide sagen, was sie sind, so kann die Benutzeroberfläche auch. BillingPeriodResolver bevorzugt die Zeit eines Live-Abonnements und fällt auf der Kalendermonat in der Zeitzone der Org. Das Fallback ist das ganze Feature in Produktion: Jedes Abonnement dort führt NULL aktuell_period_start und current_period_end, ohne sie wären die Periodenzahlen für jeden leer Organisation, die existiert - die gleiche Klasse von Bug wie der Stub, den es ersetzt. StorageSnapshotSweep schreibt die tägliche Position, von der die Geschichte jedes Orgs abhängt, Aufholen von bis zu 14 verpassten Tagen und Aussaat eines ersten Schnappschusses aus dem fragwürdigen Lebensdauer so Tracking nicht bei Null neu starten. Die Plattform Endpoint-Berichte gegen physisch gespeicherte Bytes abgerechnet. Kunden werden pro Datensatz in Rechnung gestellt; img_dats hält eine Kopie pro hash, wie viele Orgs auch immer haben Diese Datei, und Miniaturansichten und Konvertierungen kosten Bytes niemand wird in Rechnung gestellt. Beide Lücken sind Kamos Wirtschaft, also sitzen sie hinter @PlatformAdminOnly. 21 neue Tests, 113 insgesamt, alle bestanden.
· InitializerService
Schema Läufer für org_storage_snapshots
Spiegel OrgStorageSnapshot als explizite DDL, nach dem Hausstil erstellt die Tabelle zuerst, so dass die CREATE ist ein Fallback und die SET DEFAULTs sind was tatsächlich machen es von einfach SQL nutzbar (Hibernate emittiert keine Spalten-Standards für Werte, die das Unternehmen in Java ausfüllt). Auch Indizes imgs auf (ORG_ID, DATE_CREATED) und (ORG_ID, DATE_TRASHED). Lagerung Aggregation liest sowohl auf jeder zusammenfassenden Anfrage und die bestehenden Indizes sind alle assoc- und ordnerförmig. Run against production 2026-08-08; org_storage_snapshots verifiziert mit allen 16 Spalten und seine Einzigartigkeit Beschränkung, bevor die Shared-lib-Entität geschoben wurde.
· kamo-shared-library
Per-Organisation Speicher-Nutzungsmodell
Nichts hat jemals die Lagerung pro Organisation summiert. Sechs Einheiten tragen ein Byte Zählung pro Datei, und kein Code aggregiert einer von ihnen, weshalb das Konto stats tab rettet "Keine Nutzungsdaten für diesen Zeitraum verfügbar" für jede org. Fügt das gemeinsame Modell hinzu, das Aggregation benötigt: - StorageDomain - die fünf org-zurüchen Speicherbereiche, die jeweils deklarieren ob seine entfernten Aufzeichnungen überleben. Dokumente und KB Medien Soft-Löschen, so eine lebenslange Summe ist eine direkte Abfrage; Mailboxen, Aufzeichnungen und Offenlegungen hart-löschen, so dass ihre können nur nach vorne ansammeln. - OrgStorageSnapshot - eine Zeile pro (Org, Tag, Domain). Es existiert für drei Zahlen, die im Nachhinein unwiederbringlich sind: Lebenssummen für die hart-löschende Domains, die Öffnungsposition, die Periode Entfernungen sind Differenziert gegen (keine Tabelle Zeitstempel eine Deaktivierung - EmbRecordState's DATE_UPDATED ist einsteckbar=falsch und nie aktualisiert), und eine Periode-Nähe Nummer festgelegt, wann der Zeitraum endete. - OrgStorageAggregator - jedes pro Domain-Aggregat in einer Klasse. Totals sind summed über Datensätze, nie über gespeicherte Objekte: img_dats hält ein physisches kopieren Sie per hash jedoch, halten diese Datei, und diese Speicherung ist Kamo's. Der Aggregator trägt absichtlich kein Stereotyp. Jeder Service läuft @ComponentScan("com.kamo"), so annotieren würde es in allen .40 von sie; BillingService erklärt die Bohne. Fügt auch die Such-Index Abfragen der E-Mail-Größe Backfill benötigt . size_bytes wurde als Hardcode-0 geschrieben, da der Index erstellt wurde, so Mailbox-Speicher liest sich als Null-Bytes plattformweit, bis diese Zeilen repariert sind. Schema in der Produktion vor der Landung verifiziert: org_storage_snapshots existiert mit allen 16 Spalten nach einem KamoInitializer-Lauf.
· InitializerService
Die ************ App-Split anmelden
Die Verfüllung füllte immer nur eine Planreihe, die fehlte - absichtlich, so konnte es nicht still bewegen Sie eine Ebene - die verlassen Apps, die nie Preis hatte, wo sie zuerst setzen. Point of Sale und Marketing-Tools landeten auf Free auf diese Weise, das ist nicht das, was Free verkauft wird. Verankert, was jeder Plan bereits verspricht auf der Preisseite, so dass die Matrix und die Marketing-Kopie kann nicht driften: Free ist Evaluation (CRM, Chat, Docs, Notizen, KB, Taschenrechner); Starter fügt die Apps ein Unternehmen handelt mit (Unterstützung, Handel, Marketing); Business fügt die Premium-Set plus Telefonie, Inventar und Clubhaus; Enterprise fügt Legal hinzu. E-Mail-Hosting und die beiden Ursprungssysteme gehören zu keinem Tier - E-Mail wird pro Sitzplatz auf jedem Plan berechnet, die Ursprungssysteme werden pro Kreditgeber ausgehandelt. Im Gegensatz zum Verfüllen versöhnt dies Lücken, anstatt zu füllen, was der Punkt der Seins Quelle ist Wahrheit: eine Stufenänderung gehört hier, im Test, nicht in einer UI-Bearbeitung würde der nächste Run zurückkehren. Auf Prod angewendet: 11 Reihen geändert. POS und Marketing off Free, und die vier unveröffentlichten Apps gegeben Ebene werden sie auf landen, wenn sie versenden, so dass die Veröffentlichung eins ist eine Stufe Flip und nicht eine Datenänderung. Ein zweiter Lauf berichtet von Null Änderungen.
· kamo-internal
Split Apps & Features in Verfügbar / Nicht verfügbar / Veraltet
Eine flache Liste gemischt Apps die Plattform bietet mit denen, die es nicht und diejenigen, die es hat sich zurückgezogen, so dass der Bediener jeden Chip lesen musste, um sie auseinander zu setzen. Die Eimer sind exklusiv und Abschreibung wird zuerst getestet: eine pensionierte App ist im Ruhestand, was auch immer seine Verfügbarkeit Flagge noch sagt, so scheint es nur unter Veraltet. Das macht auch die pro-Reihe "Deprecated"-Chip und die Dimmung redundant - jede Zeile in dieser Registerkarte ist ausgeschieden - also sind beide weg. Partitionierung liest Server-Staat statt der Entwurf, so tickt die veraltet Schalter lässt die Zeile an Ort und Stelle, bis die speichern landet, anstatt es heraus zu reißen von unter der Bearbeitung.
· SecurityService
Ein Mieter-lesbarer App-Katalog für Branch-Typen
Branch Types -- Allowed Apps begannen das Laden seiner App-Liste von /platform-config/app-katalog, die benötigt einen Top-Level-Org-Besitzer. Die Host-Seite ist stattdessen auf CONFIGURE_SYSTEM abgesperrt, so dass für jeden Pant der GET 403'd: der Editor gerenderte Null-Apps und der Speicher-Handler weigerte sich dann, die zu speichern Sicherheitsmodell überhaupt - Blockierung seines Namens, Altersklassen, Rollen und Handelstypen, von denen keines davon den Katalog einbeziehen. Es scheiterte auch bei einem KamoCRM Admin ohne ist OrganizationOwner. **************** bedient den gleichen aufgelösten Katalog unter CONFIGURE_SYSTEM, als bewusst schmalere Projektion: Typ, Anzeigename, Beschreibung, Bühne, verfügbar, veraltet. Kein Operator Note, keine enum Standardwerte, keine Berechtigungsdiagnosen - diese beschreiben, wie die Plattform ist laufen, und die schreibt bleiben Plattform-Besitzer-nur.
· kamo-internal
Fügen Sie eine Apps & Features Registerkarte und beheben Sie die erlaubte Apps Liste
Die neue Registerkarte, rechts von Organisationen, kontrolliert, was jede Organisation angeboten wird: Verfügbarkeit, Entwicklungsstufe, Anzeigename, Beschreibung, Operator Hinweis, und Verungerung. Verfügbarkeit ist nicht mehr von der Stufe abgeleitet, so eine App veröffentlicht werden kann, während noch in der Prüfung oder zurückgehalten werden, nachdem es ist fertig; Stufe fährt jetzt nur noch die Plakette und die Bar. Überlastete Felder sind individuell markiert und zurückgedreht, und Verungerung, die eine App aus versteckt jeder Mieter mit ihm benötigt den Namen der App, um dies zu bestätigen. Erlaubte Apps im Sicherheitsmodell-Editor war ein handgewartetes TypeScript Kopie von ServiceType.java, mit einem Kommentar, der Redakteure auffordert, es auszurichten. Es hatte sich abgedriftet, unsichtbar: - MLOS fehlte völlig, so dass kein Sicherheitsmodell Hypothek gewähren konnte Ursprung überhaupt. - LOS wurde als "Hypothekendarlehen Origination System" bezeichnet - es bedeutet persönlich Darlehen seit dem 2026-08-08 umbenannt, so schrieb der Herausgeber eine persönliche Kredite Zuschuss für einen Betreiber, der dachte, sie würden Hypotheken gewähren. - POS und ESIG zeigten PLANNING lange nach der Verschiffung. Das Hinzufügen von Verfügbarkeitsindikatoren zu dieser Liste hätte es nur geschafft Zuversicht falsch, so liest es jetzt den gleichen Katalog der neue Register Tab schreibt und kann nicht damit nicht einverstanden sein. Das Speichern wird blockiert, bis der Katalog lädt: jeder appConfigs Builder iterates iterates iterates iteling Zuschüsse des Modells.
· SecurityService
Servieren Sie den App-Katalog und lesen Sie Funktionen durch sie
FeatureController abgeleitet "ist diese App angeboten" von der Enum-Phase in vier getrennte Orte, so dass die Antwort nur durch die Verlegung der Plattform. Jeder von ihnen liest jetzt AppCatalogService, zusammen mit der Name, Beschreibung und Verkündung anzeigen. Die einzige Verhaltenstilität ist das Root-Ordn-Tor. Früher hieß es "Bühne ist nicht KOMPLETT, so dass Kind orgs kann nicht ermöglichen, dies" - die Dogfooding-Pfad. Es liest nun "die Plattform bietet dies derzeit nicht an". Während kein Override existiert, die sind die gleichen Satz, weil unset Verfügbarkeit löst zu Bühne == KOMPLETT. Sobald ein Operator eine App veröffentlicht, die sich noch in TESTING, nur die neue Form tut das Richtige: Ohne sie würde die App die App Bleiben Sie still für jedes Kind blockiert. PlatformAppCatalogController ist für Top-Level-Or-Besitzer gated, die gleiche Publikum als benachbarte Plattform Tabs, und berichtet, ob eine verfügbare App ist tatsächlich in der Plan-Matrix - eine App kein Plan erwähnt löst durch die ausfallende Einstellung und nicht durch alles, was der Betreiber gewählt hat.
· kamo-shared-library
App-Verfügbarkeit und Schritt zur Laufzeit editierbar machen
Jedes Attribut der Apps-Einstellungen Seite macht - Anzeige Name, Beschreibung, Bühne, Abschreibung - war eine Compiler-Zeitkonstante im ServiceType enum, und "Verfügbarkeit" wurde überhaupt nicht gespeichert: es wurde als Bühne abgeleitet == COMPLETED in der Benutzeroberfläche und an drei Stellen serverseitig. Irgendetwas davon zu ändern bedeutete Bearbeitung die gemeinsame Bibliothek und die Verlegung der Plattform. PLATFORM_APP_CATALOG hält mit jeder Override-Spalte eine Zeile pro App nullable, und AppCatalogService löst Override ?? enum. Eine fehlende Reihe bedeutet das enum wörtlich, also ändert die Installation keine Verhaltensweisen. Verfügbarkeit wird zu seinem eigenen Wert, das ist, was macht einen weichen Start (offered während immer noch TESTING) oder eine zurückgehaltene COMPLETED App ausdrückbar. Sein Fallback liest die RESOLVED-Bühne statt der enum's, also ein Operator, der sich nur bewegt eine App für COMPLETED erhält Verfügbarkeit, ohne auch den Schalter umzulegen.
· InitializerService
Eine richtig kategorisierte Katalogreihe pro App, auf jeder Anspruchswurzel
Neun Apps - POS, Marketing Tools, Rechner, Club, Inventar, Legal, Spiele und die beiden Ursprungssysteme - hatten überhaupt keine Katalogdarstellung: keine Preisreihe, keine Kategorie, keine Ebene. Zwölf weitere wurden bereits durch eine Marketing-Reihe beschrieben, so dass diese zu binden und eine parallele hinzufügen APP_*-Reihe hätte eine ServiceType-Zersatzreihen gegeben und planFeatureIncluded on by iteration Reihenfolge. Der Läufer konvergiert nun stattdessen den Katalog: - bindet eine veröffentlichte Marketing-Reihe an die App, die sie beschreibt (VIDEO_CONF ist Meet, MESSAGING is Chat), Beibe Behalten von Code, Name, Kategorie und Tierwerte, damit sich die veröffentlichte Matrix nicht bewegt; - erstellt eine Zeile für eine App, die der Katalog nicht beschreibt, in einer echten Kategorie - inklusive einer neuen Kategorie Handel & Herkunft; - fördert jeden früheren APP_* Platzhalter zu seiner wirklichen Identität und löscht die Flat Applications Eimer einmal leer; - entfernt doppelte Zeilen für die gleiche App, bevorzugt die Marketing-Reihe. Es gibt keine APP_ Fallback links: jede App hat einen lesbaren Code, und Apps der veröffentlichten Katalog bereits Namen verwenden, dass genau Code so ein org mit einer eigenen Matrix und eine ohne beschreiben gleiches Produkt identisch. Das zählte - sign.pink hat keine Marketing-Matrix und wurde mit links elf Reihen, die nach Enum-Konstanten benannt sind. MLOS und Persönliche Darlehen sind Unternehmen ausgehandelt, nicht pro Sitz: Null Preis, FLAT Preismodell, nur mit CUSTOM-Planen (Enterprise), gebündelt in keiner Stufe. Sie sind auf der Plattform org nur - ein White-Label-Produkt org nicht weiterverkaufen, und die beiden erstellt auf sign.pink durch einen früheren Pass werden deaktiviert. Gegen prod nach dem Auslaufen überprüft: 0 APP_* Codes links, 0 duplizieren service_type Zeilen, 21 Apps auf jede Wurzel, 0 aufgedeckte Plan-für-App-Kombinationen und eine Neuauflage ist eine No-Op.
· kamo-internal
Server-paginierte Organisationen-Konsole
Der Reiter lud jede Organisation in einer Anfrage und machte jeweils eine Karte, mit dem Backend-Fanning out per org, dann pro Konto, dann pro Abonnement. Suchen, sortieren, filtern und paging führen jetzt Server-Seite gegen den gesamten Nachlass, so die Seite Kosten ist flach, egal wie viele Organisationen existieren. Die Zeile ist jetzt auch das richtige Objekt. Ein Abonnement ist auf einem Konto HELD und TARGETS an org, so dass die alte Karte -- auf dem Halter -- hatte die drucken Name des Ziels in einem verschachtelten Tisch, und Kunden-Oggen erschien als Strings innerhalb anderer Orgs-Reihen und nicht als Reihen. Jede Reihe hat nun Anspruch (inbound: Was regelt diese Org) und Abrechnung gehalten (outbound: was es abrechnet andere) als separate Facetten. Design: eine Statusschiene auf den linken Rand jeder Reihe und eine proportionale Kombi-Bar, so eine Seite liest sich als ein Farbhitogramm der kommerziellen Gesundheit, bevor ein Wort ist gelesen; tabellarische Ziffern mit Nullen gedämpft, da die meisten Zellen auf einem Abrechnungsgut sind Null. Tabellenzustand lebt in der URL, so dass eine gefilterte Ansicht verlinkbar ist -- geschrieben durch eine Kopie, die "Tab" bewahrt, und ohne zu veröffentlichen activeTab, die gehört zu tabSync.
· SecurityService
Fail geschlossen auf Apps ein Plan nie erwähnt
Turns kamo.entitlement.fail-open off jetzt, dass AppEntitlementCatalogMigration gegen prod und jeder aktive Plan auf beiden Anspruch Wurzeln (KamoCRM, Sign Pink) trägt eine explizite -Reihe für alle 21 Nicht-Kern-Apps - verifiziert Null aufgedeckte Plan-by-App-Kombinationen, so gibt es nichts links für eine Verweigerung-durch-Standard zu fangen, außer einer wirklich unpreislichen App. Dies ändert nichts daran, was irgendein Org heute verwenden kann: ausgelieferte Apps sind explizit enthalten, und MLOS und die persönliche-Darlehen App wurden bereits durch explizite isIncluded=falsche Zeilen verweigert, die binden unabhängig von dieser Flagge. Was es schließt, ist eine App rutscht durch unpreislich durch nie erscheinen in der Matrix eines Plans überhaupt. Flip zurück zu true, wenn eine neue Anspruch Wurzel hinzugefügt wird, bevor die Migration für sie ausgeführt hat.
· BillingService
Servieren Sie das org-Verzeichnis als gefilterte, sortierte, paginierte Seite
GET /orgs nimmt Seite/Größe/q/sort/dir plus sieben Filter und gibt das Haus zurück Seitenumschlag mit gebietsweiten Aggregaten. GET /orgs/{orgId' dient im Detail für die Bohrer-in-Ziehung der Konsole, wo der pro-Konto-Fan-out in Ordnung ist, weil es ist an eine org gebunden. listAllOrgs() wird ersetzt und nicht als abkürzlicher Delegierter gehalten: es hatte genau ein Anrufer (dieser Controller), und die Liste des Frontends hatte genau eine (die Registerkarte wird umgeschrieben), so dass eine Kompatibilität shim hätte nur eine silent-truncation Risiko mit nichts abhängig davon.
· BillingService
Batched Seite Hydratation bei einer konstanten Abfrage-Zählung
Elterntitel, Primärdomäne, der Plan/Markt hinter dem Anspruch und die Abonnement-Katalog-Flagge sind jeweils ein Chargen IN (:ids) über die gesamte Seite, so kostet eine 100-Rench-Seite die gleichen sechs Anweisungen wie eine 1-Reihe-Seite. Der Test behauptet, dass Gleichheit direkt -- die Umsetzung, die dies ersetzt, punkten würde 6 gegen 600. Das Regierende Abonnement wird von EntitlementModeResolver ausgewählt, dem gleichen Code die den Modus der Reihe entschied, so dass der gezeigte Plan immer dem Staat gehört gezeigt. Anfragen gehen durch EntityManager anstatt neue Repository-Methoden so Kamo-shared-Bibliothek, von der jeder Dienst abhängt, muss sich nicht ändern.
· BillingService
Directory row/page DTOs und das native Abfrage-Repository
PlatformOrgRow trägt die beiden Facetten getrennt: Anspruch (inbound subs Targeting der Org -- was es regiert) und Abrechnung gehalten (rekont die Org besitzt -- nicht Null nur für die Plattform org und Wiederverkäufer). Aggregate beschreiben die ganze gefilterte Sets, nicht die Seite, so dass der KPI-Streifen die Bedeutung nicht ändert die Betreiberseiten. Jeder Fahrerwert wird durch Number/Boolean anstatt durch gegossen gezwungen: ein koesce(...,0), das keine Zeilen entspricht, gibt Integer zurück, wo die gleiche Spalte mit Reihen kehrt Long, die in dev und werfen in prod passieren würde. Geld überquert die Draht als Dezimalstring.
· BillingService
Org Verzeichnis SQL mit profacet CTEs
Ausgebuchte Konten, Inbound-Abonnements, Mitglieder, Lizenznehmer und Kinder agg. in ihrem eigenen CTE, bevor sie zu orgs beitreten. Mit ihnen in einem Pass würde Reihen multiplizieren und jede SUM aufblasen. Rein und gerätegeprüft (26 Tests): keine '::'-Abschlüsse, jeder Wert gebunden, Schlüssel sortieren Whitelisted durch OrgSort. Zwei Dinge die Tests Pin, weil sie einfach sind "ordentlich" in Bugs -- ORDER BY und die abgeleiteten Prädikate (mode_rank, hat_stripe) müssen die projizierten Spalten der Basis von CTE benennen, da der Alias Alias nicht in den Rahmen fällt in der äußeren Abfrage; und eine PENDING-Studie berichtet keine Frist statt der Zuletzt abgelaufen ein. Geprüft gegen den Live-Cluster: Beide Aussagen ausführen, die Zählung stimmt zu mit den Zeilen, und Filter/Aggregate gelten. Index-Nutzung wird NICHT demonstriert -- bei 12 orgs / 9 subs CockroachDB Full-Scans unabhängig davon, richtig.
· BillingService
Validierte, geklemmte Org-Verzeichnis-Anfrage
Größe klammert sich an [1,100] und eine unerkannte Art fällt zurück zum Titel, so ein Handbenachrichtigende URL kann weder den gesamten Nachlass anfordern noch das SQL als freier Text. Das OrgSort enum ist die Art Whitelist.
· BillingService
Anspruchsmodus durch einen gemeinsamen, deterministischen Lösungsmittel ableiten
TrialAdminService wählte sein Testabonnement mit findFirst() über eine ungeordnete Liste, so dass eine Org sowohl eine anhängige und eine aktive Studie halten könnte Bericht entweder. Das kommende Organisationsverzeichnis muss sortieren und filtern Dieser Zustand, und eine Abfrage kann keine nicht-deterministische Regel reproduzieren. Der Vorrang liegt jetzt in ************ Live-Tests, aktive Siege über anstehende Siege über abgelaufene, und der aktive Ablauf berichtet ist die neueste. status() behält seine genaue Antwortform. Erste Tests in diesem Repo (11).
· InitializerService
Backfill App Anspruchsreihen in den Plattformplan-Katalog
Anspruch löst sich nun auf einer getippten service_type Spalte, aber keine Katalogzeile trug eine, so jeder Plan, der noch beschlossen wurde, über den Ausfall-Open-Standard "alles eingeschlossen" zu haben. Dieses Saat der Matrix so kamo.entitlement.fail-open kann schließlich ohne Dark-Firing-Apps ausgeschaltet werden. - AppEntitlementCatalogMigration (@Order(51), nach PlatformOwnerPlanSeeder): idempotent Backfill. Erstellt eine 'Anwendung' Feature Kategorie mit einer BOOLEAN-Reihe pro Nicht-Kern-App gebunden an seinen ServiceType, re-bindet jede bereits bestehende Zeile, die den Code hat, aber keine serviceType und fügt die fehlenden Plan-zu-App-Reihen pro Tier ein. Einfügen-wenn-fehlen nur es löscht nie und überschreibt nie ein Operator ist ingeschlossen, so dass eine Ebene in der Einstellungen UI überlebt Neustarts. Auch die bestehende VIDEO_CONF / AI_ASSISTANT / HR_SYSTEM / ESIGNATURES / EMAIL_HOSTING Add-ons, die nichts zuließen. - KamoCRMPricingLoader: gleiche Matrix für einen frischen Cluster. Die App-Reihen sind im Inneren angefügt upsertFeatures anstatt in einem zweiten Durchgang geschrieben, weil upsertPlanFeatures löscht die Plan-Reihen vor dem Einfügen - ein zweiter Anruf würde still wischen die Marketing-Matrix. Hinweis: Dieser Loader ist deaktiviert (früh zurück, und sein DataLoader-Aufruf wird kommentiert), der warum die Migration oben der Produktionsweg ist.
· SecurityService
Gate Hypothek und persönliches Hypothek vertikale auf App-Anrecht
Ein MORTGAGE Markt erschien auf /commerce, wann immer POS eingeschaltet war, unabhängig von der MLOS App, und / Features/enable hatte überhaupt keine Abrechnungsprüfung - das Vorhängeschloss in den Einstellungen war Präsentation nur, so dass eine direkte POST eingeschaltet eine nicht berechtigte App. - FeatureController: 403 aktivieren, wenn der Plan nicht die App enthält; serialisieren Sie eine 'berechtigtes' Urteil über beide Funktionen[] und verfügbar[], so dass das UI-Vorhängeschloss und das 403 sind Errechnet durch den gleichen Dienst und kann nicht widersprechen. - CommerceMarketController: GET /allowed-Typen für den Markt-Typ-Picker (Modell allow-list mit Anspruch überzogen); die Marktliste fällt ohne berechtigte Vertikalen - versteckt, niemals archiviert, so dass die Wiederherstellung des Plans bringt den Markt zurück mit seinen intakten Daten. - ************ Ausfall-Zwischenschutz über jede /{marketId?/... Unterroute. AppAvailabilityInterceptor kann dies nicht ausdrücken. seine Präfixkarte ist ein Präfix für eins ServiceType und /Commerce-Märkte bedienen alle sieben Vertikalen unter POS. - POSController: Öffentliche Anrufer des Abo-Katalogs sehen keine Zeilen mehr, die an eine App gebunden sind die nicht erreicht hat COMPLETED, so dass die Verlagerung eines ServiceType zu COMPLETED ist, was veröffentlicht es zu die Marketing-Website. Interne Anrufer sehen immer noch alles, um es vorher zu bepreisen. - MortgageVerticalResolver: Bereitschaft gemessen POS nur, so ein Org, die nie gekauft MLOS noch lesen Sie als bereit; es berichtet jetzt MLOS in "vermisst" zu.
· kamo-internal
Umbenennen Sie LOS zu MLOS, fügen Personal Loan Origination System, Gate Commerce vertikalen
Apps Registerkarte zeigt jetzt 'Commerce: Hypothekendarlehen Origination System' (der Titel wird von der serviert backend enum, nicht der TS-Spiegel) und ein neues 'Commerce: Personal Loan Origination System' unter Nicht verfügbar. MORTGAGE und PERSONAL_LOANS Märkte sind auf ihre App gated. - AppType/ServiceType Spiegel: MLOS(14) + neu LOS(25); behebt auch die bereits bestehende Drift die Spiegel mit dem Java enum nicht einverstanden. - Organisation: istMlos hinzugefügt; isLos bedeutet jetzt persönliche Darlehen. isLos hatte null Verbraucher. - FeaturesManager: gating liest das vom Server gelieferte 'titled' Flag. Es wurde Client-Seite umgebaut von billingApi, dessen getCurrentAbonnement wirft und getAvailablePlans zurückkehrt [] (Vermächtnis stubs), so dass jede App still gelöst, um "unget" und kein Vorhängeschloss jemals gerendert. - Marktsammler: Sowohl die erstellen als auch die bearbeitenden Seiten hielten ihr eigenes Hardcoded COMMERCE_TYPES-Array; sie machen jetzt GET **************** so eine vertikale, die die Org nicht gekauft hat, ist nicht wählbar. Die Bearbeitungsseite hatte auch die Ein-MORTGAGE-per-org-Regel übersprungen. Es hält der aktuelle Typ des Marktes wählbar, so dass eine hindeutete Org noch öffnen und umbenennen kann. - Hypotheken-Einstellungen Oberflächen Tor auf isMlos statt isPos.
Euer Universum wartet.
Fügen Sie Produkte hinzu, wann immer Sie möchten – keine Migration, keine neuen Anmeldungen.
Für immer kostenlos – keine Kreditkarte erforderlich