Mabadiliko
Nini kipya.
Kila kuboresha jukwaa, kama ni meli.
· SecurityService
Add theme provisioning — NATS publisher, provision-theme endpoint, logo upload
· ConversionService
Add image resize and favicon generation endpoints
· InitializerService
Add migration runner for logo_full_ext column on orgs
· kamo-shared-library
Add logoFullExt field to Organization entity; add listObjects to MinIOStorageService
· kamo-internal
Replace emoji icons with solid SVG icons on create wizard stepper
· kamo-shared-library
Add findByBranchTypeID derived query to OrganizationRepository
Supports the new /branch-types/{id}/usages endpoint in SecurityService for checking whether a branch type has active child orgs before deletion.
· SecurityService
Add GET /branch-types/creatable and /{id}/usages endpoints
/creatable returns branch types filtered by the caller's creator-type (OWNERS/TEAM_MEMBERS/MEMBERS) via AppliedModelEnforcementService. /{id}/usages returns the count and summary of orgs created under a given branch type, used by the frontend to block hard deletion.
· kamo-internal
Guard branch type deletion against active org usages
Before removing a branch type chip, the frontend now calls **************** If any orgs exist it shows an informational dialog listing them and instructs the admin to disable the type instead of deleting it.
· kamo-internal
Live support ticket badge on NavTop — SupportCountContext subscribes to NATS via STOMP, badge shows pending count
· MediaService
Live pending support ticket count via NATS — notify org owner on new tickets, add pending-count REST endpoint
· kamo-shared-library
Add pending count field to SupportAgentNotificationDTO and count query to SupportTicketRepository
· kamo-internal
Add domain name field to org creation wizard
Adds a required domain field to the Basics step with automatic www. stripping. Validated, included in API payload, and shown in the review step.
· kamo-marketing
Add API modification callout to kamo-api-reference page
Shown only on /kamo-api-reference, prompts users to submit API change requests via /requests or reach out via /contact.
· SecurityService
Add GET /branch-types/creatable endpoint with creator-type filtering
Returns only the branch types the calling member is permitted to create a child org under, based on their OWNERS/TEAM_MEMBERS/MEMBERS classification against the current org's applied security models. Mirrors the exact same getBranchTypesCreatableBy enforcement the POST /org endpoint applies at submission time, so the frontend can pre-filter the pick list and avoid showing options that would produce a 403. Response includes allowedMemberAgeRanges and allowedTeamMemberAgeRanges from each branch type's security model so the UI can gate AgeReqType options in the same request, without a second round-trip.
· kamo-internal
Replace OrganizationType wizard step with branchType/SecurityModel selection
- Replace OrgTypeStep (OrganizationType + Configuration dropdowns) with BranchTypeStep that fetches **************** — the new endpoint returns only branch types the caller is permitted to create a child org under, filtered by their OWNERS/TEAM_MEMBERS/MEMBERS classification against the org's applied security models - Remove OrganizationType from the payload entirely; configType is now auto-derived from the security model's allowedMemberAgeRanges (KIDS_ONLY → KIDS_CLUB, teen-range → CLUB, else ENTERPRISE) - AgeRestrictionsStep now filters available AgeReqType options to those permitted by the selected security model, with a banner when gating is active; null age (Not specified) remains a safe no-op per backend - After successful creation redirect to /setup/dns?orgId=&orgName= of the CURRENT org (not the new child org) — DNS must be configured before the new org is accessible - Add **************** Next.js proxy route - ReviewStep shows branch type name + allowed age scope instead of old org type / config type badges
· kamo-internal
/network create affordance is gated by member-type + right
- BranchSetupManager: new "Who Can Create Child Orgs Under This Model" card with three toggles (Members / Team Members / Owners). Values round-trip through mapBackendModel and both save flows (child model + master model). Empty state defaults all three to false — a model doesn't offer creation to anyone until the admin opts them in. - /network page: fetches **************** on mount and hides every "Create New Organization" affordance (header button, empty-state button, bottom card) unless the server definitively returns canCreateChildOrg=true. While the check is in flight (null) the affordance stays hidden so we never flash it to a member who shouldn't see it. - New **************** proxy route forwards through to SecurityService's new endpoint.
· SecurityService
Gate /network child-org creation by right + member-type applicability
Wires the applied-security-model child-org creation gate end-to-end: - SecurityModelController + MasterModelController round-trip the three new apply-to flags (appliesToMembers / appliesToTeamMembers / appliesToOwners) through create and update payloads. - New GET **************** resolves — for the caller's session — the creator-type bucket they fall into, whether their role carries CREATE_CHILD_ORG, the list of branch types available to them, and a combined canCreateChildOrg boolean the /network page uses to hide the create affordance when false. - **************** now rejects with 403 when the caller lacks CREATE_CHILD_ORG or picks a branch type that isn't among those their creator-type is offered — defense in depth against a client that bypasses the UI gate.
· kamo-shared-library
Member-type gate + CREATE_CHILD_ORG right for child-org creation
Adds the data layer for gating /network child-org creation by member type: - New CREATE_CHILD_ORG right on RoleRightType (id 131). - Three new boolean columns on ChildOrgSecurityModel: appliesToMembers / appliesToTeamMembers / appliesToOwners When true, the model's branch types are offered to that member-type bucket on /network. A model with all three false is never surfaced as a creation option to anyone — it only governs existing orgs. - ChildOrgSecurityModelService gains 13-arg create/update overloads that accept the new flags; the legacy 10-arg signatures delegate through. - ChildOrgSecurityModelDTO round-trips the three flags. - AppliedModelEnforcementService exposes the gate logic that every caller shares: enum ChildOrgCreatorType { MEMBERS, TEAM_MEMBERS, OWNERS } getBranchTypesCreatableBy(org, creatorType) → the list of branch types that belong to models which apply to that creator type and have at least one branch type. **************** creatorType) → boolean predicate. Creator-type classification: OWNERS = team-members with isOrganizationOwner=true, TEAM_MEMBERS = other team-members, MEMBERS = everyone else. Right-check (CREATE_CHILD_ORG) is intentionally NOT baked into these helpers — callers combine both checks so the helper can also back read-only queries.
· InitializerService
Master model applies to all three member types on init
provisionMaxedOutMasterModel now sets appliesToMembers, appliesToTeamMembers, and appliesToOwners all true so every member type sees the master model's branch types as creation options on /network. The Administrator template continues to GRANT every RoleRightType including the new CREATE_CHILD_ORG right (id 131) by virtue of iterating RoleRightType.values().
· kamo-marketing
Add milliseconds to launch countdown, tick every 50ms
· kamo-marketing
Replace static launch date with live countdown to 2PM PST Apr 20 2026
Ticks every second showing Xd XXh XXm XXs; falls back to static date until client hydrates, shows "Now" when target is reached.
· InitializerService
Administrator default role template starts with all rights GRANTED
provisionMaxedOutMasterModel now populates the Administrator template with every RoleRightType set to GRANTED. The other three templates (Team Member, Member, DEFAULT) still materialize with zero rights (NOT_SPECIFIED for everything), matching the intended blank baseline for non-admin roles. Why GRANTED (not FORCE_GRANTED): at child-org creation time ChildOrgTemplateSeedingService copies non-force template values into the new org's OrgRoleRight rows, so a GRANTED admin template gives every new child org a ready-to-use admin role with full permissions that the owner can still edit. FORCE_GRANTED would lock rights at runtime and hide them from the security-roles editor, which we don't want for the admin template baseline.
· InitializerService
Provision a maxed-out master security model for KamoCRM on init
DataLoader now creates and assigns a master ChildOrgSecurityModel to KamoCRM immediately after the org is created, with every setting maxed out to the most permissive / force-enabled value: - allowOwnersViewOtherOrgs / allowOwnersPrivateOrgs / allowSubChildOrgs = true - identityProviderSetting = ENABLED - teamMemberPayFeesSetting = FORCE_ENABLE - allowedMemberAgeRanges / allowedTeamMemberAgeRanges = every AgeReqType - appConfigs = every non-deprecated ServiceType at FORCE_ENABLED, with CRM's allowedCommerceTypes containing every CommerceType - Organization.masterModelID set to the new model The four default role templates (Administrator / Team Member / Member / DEFAULT) are materialized with zero rights so the UI renders tabs for each — every right stays NOT_SPECIFIED at runtime, the intended blank baseline. Admins can edit specific force rules later via the branch-types tab. Also bumps kamo-shared-library to 1.5.0 so the new ChildOrgSecurityModelService / AppConfigService / DefaultRoleService and related types resolve at compile time.
· kamo-internal
FeaturesManager honors applied-model force-enabled state
Accepts the new modelAvailability + locked fields from FeatureController and surfaces them in the UI: - Features whose modelAvailability is FORCE_ENABLED render the toggle in the on state, disabled, with an explanatory tooltip — admins can see they're on but can't flip them off. - Toggling a modelForced feature short-circuits with a clear toast rather than a generic error from the backend's 403. - NOT_AVAILABLE features never reach the client (filtered server-side) so the UI list is already the gated view.
· SecurityService
Applied-model is the read-time source of truth for feature availability
Closes the "stale DB leaks a disabled feature" gap by gating every surface that touches OrgFeature / ServiceType through the applied security model. - **************** (the primary feeder of the frontend OrgContext): replaces the raw features serialization with **************** org.getFeatures()). The auto- provisioning loop now also skips apps the model marks NOT_AVAILABLE so we never create DB rows for blocked apps. - FeatureController.list: returns each feature with modelAvailability + locked metadata. NOT_AVAILABLE rows are filtered out, FORCE_ENABLED rows are reported as enabled=true + locked=true regardless of their DB state. The available list is also filtered down to apps the model permits. - New AppAvailabilityInterceptor + WebMvcConfig: installs a HandlerInterceptor on every service-scoped URL prefix (/api/security/pos, /api/security/commerce-markets, /api/security/leads*, /api/security/lead- imports, /api/security/lead-markets, /api/security/lead-vendors, **************** **************** **************** Each request is matched to a ServiceType, resolved against the caller's applied model, and rejected with HTTP 403 if the app is effectively off. This is the final line of defense: even with stale client state, a forgotten controller guard, or a direct API call, a blocked app returns 403. Net effect: the applied security model now wins at read time everywhere the org's features or apps are exposed — navigation, home page, settings slide-out, FeaturesManager, per-service endpoints. When the admin flips CRM to NOT_AVAILABLE on the model, the CRM UI disappears from the frontend and CRM endpoints start 403'ing — regardless of whether the DB still has OrgFeature.isActive=true for CRM.
· kamo-shared-library
Effective-feature resolver for applied-model read-time gating
Adds the read-time gate that makes the applied security model the final source of truth for feature availability, so stale DB state can't leak a disabled feature through and a force-enabled feature is always visible even when the DB hasn't caught up. New methods on AppliedModelEnforcementService: - computeAvailabilitiesMap(org) — one-pass resolution of every ServiceType's availability for an org in a single lookup. Serves as the batch primitive the other new methods build on. - isAppEffectivelyEnabled(org, serviceType, features) — the canonical "is this app on" check. Core services always on, deprecated always off, FORCE_ENABLED always on, NOT_AVAILABLE always off; OPTIONAL_* defers to the OrgFeature row's isActive state. - **************** features) — the Set<ServiceType> companion for callers that need "all effectively-on apps" as a set. - computeEffectiveFeatures(org, features) — returns a fresh ArrayList of OrgFeature rows projected through the gate: NOT_AVAILABLE dropped, FORCE_ENABLED forced to active (even on disabled DB rows), and FORCE_ENABLED apps with no DB row yet represented by transient rows (organization-scoped, never persisted). Callers serializing an org's features to clients now route through computeEffectiveFeatures rather than reading the raw collection, so the frontend sees the applied-model-gated view by default.
· kamo-internal
Add per-assocType docs settings tabs with doc types, stacking orders, and config panels
Replaces ComingSoonTab on /settings/features/docs with a full settings interface: - General overview tab + one tab per ImageAssocType (Account, Service Application, Service Order, Call Recording, My Docs, Meet Recording, System-Wide) - Each assocType tab has 3 sub-tabs: Configuration (folder/docType feature toggles), Doc Types (full CRUD), Stacking Orders (CRUD with visual pipeline drawer) - Next.js API proxy routes for all imaging settings endpoints - AssocConfigPanel, DocTypesManager, StackingOrdersManager, StackingOrderDrawer, AssocTypeSettings components
· DocsService
Add ImagingSettingsController with doc type, stacking order, and assoc config CRUD
· kamo-shared-library
Add ImgAssocConfig entity, repository, and sortOrder to ImgStackingOrderDt
· InitializerService
Add FEATURE_REQUESTS to Support category and all plan-feature mappings
Free: Community vote, Starter: Vote & request, Business: Priority requests, Enterprise: Custom dev included
Ulimwengu wako unasubiri.
Kuanza bure katika dakika. Ongeza bidhaa wakati wowote wewe ni tayari - hakuna uhamiaji, hakuna logins mpya.
Bure milele - hakuna kadi ya mkopo inahitajika