Activities of "maliming"

Hi,

No change on that front yet — AI Management is still host-level by design in the current release. Workspaces and their data sources, MCP servers and indexed documents aren't tenant-scoped entities, so they stay shared across tenants.

Making it tenant-scoped is on our roadmap, but it isn't tied to a specific release yet, so we can't give you a target version or date at this point. We'll keep tracking this on our side and share an update once there's a committed plan.

The blob-path issue you linked was a separate bug and it already shipped in a patch release, so that one is covered.

Thanks

Hi,

Glad it's sorted, and thanks for flagging it. We've fixed the update so it won't write those Unknown versions again — it'll be in the next release.

Thanks

Hi,

On a normal Bearer/OpenIddict API host (your setup), the HTTP status alone isn't enough, and an authorization/permission failure doesn't carry an ABP error body at all — so there's no error.code to match on for that case. Here's what actually comes back:

• Missing permission (authenticated): 403 with an empty body — no ABP payload, no error.code, no _AbpErrorFormat response header.
• Not authenticated (missing/expired token): 401 with an empty body (WWW-Authenticate: Bearer).
• A BusinessException (and validation, not-found, etc.): comes back with the ABP error body — an error.error object (a message, usually a code) plus the _AbpErrorFormat: true header. A BusinessException also uses 403, which is exactly why the status alone can't separate it from a permission failure.

The reason for the difference: ABP handles AbpAuthorizationException differently from other exceptions. Instead of serializing a JSON error body, it hands off to the authentication scheme's Forbid/Challenge (403 when authenticated, 401 when not). So the Volo.Authorization:... codes you may have seen only show up in the server log, not in the response the client gets.

So the reliable signal on the client is "is there an ABP error body?", not the status code or a specific error code:

• 401 → not authenticated → send the user to login.
• 403 without an ABP error body → permission/authorization denied → show your "You don't have permission" message.
• Any status with an ABP error body (error.error present) → business/validation/other error → show error.error.message.

For Angular, the built-in extension point is a custom error handler (CUSTOM_ERROR_HANDLERS), which runs before the default handling based on priority:

import { Injectable } from '@angular/core';
import { HttpErrorResponse } from '@angular/common/http';
import {
  CUSTOM_ERROR_HANDLERS,
  CustomHttpErrorHandlerService,
  CUSTOM_HTTP_ERROR_HANDLER_PRIORITY,
} from '@abp/ng.theme.shared';

@Injectable({ providedIn: 'root' })
export class PermissionErrorHandlerService implements CustomHttpErrorHandlerService {
  // Higher than the built-in handlers so it wins for the bare 403 case.
  readonly priority = CUSTOM_HTTP_ERROR_HANDLER_PRIORITY.veryHigh;

  canHandle(error: unknown): boolean {
    // 403 with no ABP error body => authorization/permission denied.
    return error instanceof HttpErrorResponse && error.status === 403 && !error.error?.error;
  }

  execute(): void {
    // show your "You don't have permission" message here
  }
}

Register it as a multi-provider:

{ provide: CUSTOM_ERROR_HANDLERS, useExisting: PermissionErrorHandlerService, multi: true }

For the calls where you pass skipHandleError: true and handle the error yourself, use the same check (this assumes the default JSON response — for a text/blob responseType the ABP envelope isn't parsed, so you'd parse it first):

if (err.status === 401) {
  // not authenticated -> login
} else if (err.status === 403 && !err.error?.error) {
  // no permission
} else {
  // business/other error -> err.error?.error?.message
}

A few notes for your topology:

• Host API vs module APIs behave identically — same ABP exception pipeline on both.
• This holds for an API host whose forbid/challenge scheme is Bearer/JWT. If a host is set up with a cookie scheme instead, an authorization failure redirects to the login/access-denied page rather than returning 401/403, and custom JwtBearerEvents (or a custom IAbpAuthorizationExceptionHandler) can change the shape too.
• Through the gateway it's the same as long as the gateway just forwards the response. Note the gateway/proxy can also produce its own 401/403 that isn't from an ABP permission check — those land in the "403 without ABP body" bucket as well, so treat that bucket as "not authorized" generically rather than "definitely a missing permission".
• Since your Angular app is on a different origin, reading the _AbpErrorFormat header directly needs it exposed via CORS (the ABP template already does this). You don't need the header though — checking whether error.error exists is enough.

Thanks

: )

Hi,

We've confirmed it and will fix it soon. https://abp.io/support/questions/10778/Unable-to-Download-LeptonX-Theme-Pro-Source-Code-from-ABP-Studio

We've refunded your ticket.

Thanks

Hi,

This isn't an entitlement issue with your account - the source package for that LeptonX theme version wasn't published on our side, which is why Studio shows that message. We've confirmed it and will fix it soon.

We've refunded your ticket.

Thanks

Hi,

You're right, this is on our side - the source package for that LeptonX theme version wasn't published, so the versioned download fails. We've confirmed it and will fix it soon.

We've refunded your ticket.

Thanks

hi

Can you share the start and end dates of your license? When did you activate the Blazorise license?

Thanks.

Hi,

Thanks for the files — your version setup is fine. Your Directory.Packages.props already has all the ABP packages at 10.5.0 (LeptonX at 5.5.0), so your solution is on 10.5; nothing is wrong with the actual package versions.

So the only thing left to fix is the Unknown values that ended up in the .abpmdl and .abpsln. The cleanest way is to restore both files from source control (their state before the update). If you'd rather edit them by hand, replace every Unknown with the matching version from your Directory.Packages.props — that's 10.5.0 for the ABP packages and 5.5.0 for LeptonX. Make sure you fix both files, including the AbpFramework / AbpCommercial / AbpStudio / LeptonX entries in the .abpsln, since those feed later Studio operations.

You don't need to re-run the update for this — your packages are already on 10.5. Please avoid running abp update again on this version, as the same follow-up step can write Unknown a second time. We're fixing that step so it can never write an unresolved version into the .abpmdl/.abpsln, and it'll be in the next release.

Thanks

Hi,

You're right, this is a bug on our side. The size class lands on the hidden native <select>, so it never reaches the visible element LeptonX renders.

You can use this CSS for now (covers both Small and Large):

.custom-select-wrapper:has(> select.form-select-sm) > .custom-select-display {
    font-size: .765625rem;
    padding: .375rem 1.125rem .375rem .75rem;
    border-radius: var(--bs-border-radius-sm);
    min-height: 0;
}

.custom-select-wrapper:has(> select.form-select-lg) > .custom-select-display {
    font-size: .984375rem;
    padding: .825rem 1.125rem .825rem 1.5rem;
    border-radius: var(--bs-border-radius-lg);
    min-height: 0;
}

We'll fix this in the theme in the next LeptonX release so Size works out of the box again and you can drop the CSS above.

Thanks