Activities of "maliming"

Hi,

The unique index doesn't protect global settings on SQL Server. EF Core adds a WHERE [ProviderName] IS NOT NULL AND [ProviderKey] IS NOT NULL filter to it, so rows with a NULL ProviderKey are never checked.

The filtered index you suggested works as a temporary fix. You can add it in your own DbContext:

1. Remove the existing duplicates first, otherwise the migration will fail. This lists them with their values:

SELECT s.Id, s.Name, s.ProviderName, s.Value
FROM AbpSettings s
WHERE s.ProviderKey IS NULL
  AND EXISTS (
      SELECT 1 FROM AbpSettings d
      WHERE d.ProviderKey IS NULL
        AND d.Name = s.Name
        AND d.ProviderName = s.ProviderName
        AND d.Id <> s.Id)
ORDER BY s.Name, s.ProviderName;

Keep one row for each setting (the one with the value you want) and delete the others by Id.

2. Add the index after builder.ConfigureSettingManagement():

using Volo.Abp.SettingManagement;

protected override void OnModelCreating(ModelBuilder builder)
{
    base.OnModelCreating(builder);

    builder.ConfigureSettingManagement();
    //...

    builder.Entity<Setting>(b =>
    {
        b.HasIndex(x => new { x.Name, x.ProviderName })
            .IsUnique()
            .HasFilter("[ProviderKey] IS NULL");
    });
}

3. Add a new migration and run the DbMigrator. The migration only creates IX_AbpSettings_Name_ProviderName, the existing index is not changed.

After this, a concurrent save of the same global setting fails with a duplicate key error instead of adding a second row.

We're looking into a proper fix in the framework and will update this ticket.

Thanks

Hi,

This is a bug in Suite. It adds some usings without checking if they are already there, and it doesn't remove or sort the usings after generating the code. Some .Extended.cs files also get the same usings again each time you regenerate an entity.

For now, you can clean up all files in one step. Add these lines to the .editorconfig file in your solution folder (create the file if you don't have one):

[*.cs]
dotnet_diagnostic.IDE0005.severity = warning
dotnet_sort_system_directives_first = true

Then run this command in the solution folder after each generation:

dotnet format style

It removes the duplicated and unused usings, and puts the System usings first and the others in alphabetical order. This clears the CS0105, SA1208 and SA1210 warnings. It also applies the other code style rules in your .editorconfig that are set to warning or error, if you have any.

We'll fix this in Suite in an upcoming version. Your ticket has been refunded.

Thanks

ok

Hi,

There's no setting for this yet. Theme Builder always writes to the root of the Angular workspace, and there's nothing in .abpsln or .abpmdl to change it.

We don't have plans to add this for now. The shared root src setup you're using is the way to go.

Thanks

Hi,

The Account Pro module has an Idle Session Timeout setting, and it works with Blazor Server.

You can find it in Administration > Settings > Account > Idle Session Timeout.

• It is disabled by default.
• After you enable it, the default timeout is 60 minutes. You can pick 1, 3, 6, 12 or 24 hours, or enter a custom value in minutes.
• When the timeout is reached, the user sees a warning modal. If there is no response in 60 seconds, the user is logged out.
• It doesn't apply to users who log in with Remember Me checked.

This setting was added in ABP 9.1.0. If your app is on an older version, you need to upgrade to see it.

https://abp.io/docs/latest/modules/account/idle-session-timeout

Thanks

Hi,

Theme Builder doesn't handle this multi-project Angular workspace layout directly. For now, keep the root-level src folder as the shared theme output and configure both applications to consume it.

In each application's build.options.assets, add:

{
  "glob": "**/*",
  "input": "src/assets",
  "output": "/assets/"
}

Also add src/styles.scss to each application's build.options.styles. Copy the generated src/assets/styles/... entries from the application updated by Theme Builder into the other application's styles array.

Both applications will then use the same generated theme files, so you won't need to move them after every Theme Builder change. If you add or remove a custom theme style, keep those generated style entries in both applications in sync.

You can share the trimmed angular.json if you want us to map these changes to your file.

Thanks

Hi,

1. License code after expiry The FAQ says the license is perpetual and that we can continue developing existing applications after it expires. Does our existing AbpLicenseCode continue to pass the license check indefinitely for version 10.6.1, both for the NuGet packages and for the modules built from downloaded source? Does this hold in development (debug) as well as in production, and on new developer machines and new servers?

Yes, it keeps passing after the license period ends, in Debug and in Release, on new machines and on new servers. Keep AbpLicenseCode in the configuration of every deployed application, otherwise the application stops with ABP-LIC-ERROR. A server needs nothing else. A developer machine needs abp login and access to abp.io, because Development mode and an attached debugger also do an online check, and that one passes after expiry as well.

2. Downloaded source after expiry May we keep using, modifying and maintaining the pro module source code we downloaded during the license period, inside our private repository, for this same application, after the license expires?

Yes, for this application. After the period ends abp get-source still works for the versions you have access to, as long as you pass --version and the commercial NuGet source is in your global NuGet.Config.

3. Upgrading the framework under our own maintained source The downloaded source references the package Volo.Abp.Commercial.Core and calls LicenseChecker.Check<TModule>() in each module class. If, after expiry, we upgrade the open-source ABP framework packages (for example to ABP 11 or a later .NET version) and maintain the pro module source ourselves: a) Is Volo.Abp.Commercial.Core 10.6.1 expected to keep working against newer Volo.Abp.Core versions, and will our license code still validate in that setup? b) If it does not, are we permitted to remove the LicenseChecker calls and the Volo.Abp.Commercial.Core reference from our own copy of the source? If this is not permitted, what is the supported path?

a) Yes for newer 10.x versions, and your license code is not affected by the framework version. ABP 11 is not released yet, so I can't answer for that one today.

b) You don't need to. The package you already have keeps working, so staying on it is the supported path.

4. Package feed and registry access after expiry Will our private NuGet feed (nuget.abp.io) and the commercial NPM registry keep serving the versions released during our license period (10.6.x, LeptonX 5.6.x)? Our CI restores packages on every build. Are we allowed to mirror those package versions to an internal, private feed (for example Azure Artifacts) used only by our own team and build servers?

Yes, 10.6.x and LeptonX 5.6.x keep being served and your CI keeps restoring. The limit after expiry is the last major.minor released before your license end date, so if 10.7.0 ships before that date you get 10.7.x as well. The Angular packages are on the public npm registry, so nothing changes for npm install. An internal feed that only your own team and build servers use is fine. Sharing the packages outside your organization or publishing them is not.

5. Remaining closed packages Is source code available for Volo.Abp.AspNetCore.Mvc.UI.Theme.Commercial and for Volo.Abp.Commercial.Core? If so, which CLI module or package name should we use?

No, there is no source code for those two packages. They stay as NuGet packages.

6. Developers After expiry, does the developer-seat limit still apply to who may work on the application and on the downloaded source?

Yes, the seat limit still applies, and it is the count that matters, not the specific people. You can move a seat to another person after expiry without any additional cost, and it stays 2 machines per developer.

7. Is there anything else that stops working at expiry that is not listed in the FAQ (for example ABP Studio, the CLI login, or "abp update" within 10.6.x)?

One thing the FAQ doesn't mention: after the period ends the CLI no longer gets your organization's NuGet API key and license code from abp.io. Both are already in your solution, the key in NuGet.Config and the code in your application configuration, so keep them safe. abp login keeps working. For a patch inside 10.6.x, set the versions in your csproj files instead of running abp update.

Thanks

Hi,

The wrapper LeptonX builds around a select.form-select isn't removed when Blazor removes the select. It stays on the page as a dead combobox, and the next render builds another one next to it.

Here's a workaround you can use for now. Add a file like wwwroot/lpx-select-cleanup.js to your Blazor host project:

(function () {
    var removeOrphanWrappers = function () {
        document.querySelectorAll('.custom-select-wrapper').forEach(function (wrapper) {
            if (!wrapper.querySelector(':scope > select')) {
                wrapper.remove();
            }
        });
    };

    new MutationObserver(function (records) {
        if (records.some(function (record) { return record.removedNodes.length > 0; })) {
            removeOrphanWrappers();
        }
    }).observe(document.body, { childList: true, subtree: true });
})();

Then add it to the Blazor script bundle in your ConfigureBundles method:

options.ScriptBundles.Configure(
    BlazorLeptonXThemeBundles.Scripts.Global,
    bundle =>
    {
        bundle.AddFiles("/lpx-select-cleanup.js");
    }
);

Make sure you use BlazorLeptonXThemeBundles.Scripts.Global. The global-scripts.js file that comes with the template is registered on the MVC bundle, so putting the script there does nothing in a Blazor Web App.

We'll fix this on the theme side in an upcoming release.

Thanks

Hi,

There's no supported way to run abp install-libs with Yarn Berry right now. It runs yarn --ignore-scripts in each project folder it finds, and Yarn 4 rejects the --ignore-scripts option.

You don't need it for the angular folder. There it only runs yarn install, which your script already does. You still need it for the HttpApi.Host project. It restores wwwroot/libs for the login pages, and that folder is excluded by the template's .gitignore.

You can pin the Yarn version per folder and remove the Corepack switching.

angular/package.json:

"packageManager": "yarn@4.12.0"

src/YourApp.HttpApi.Host/package.json:

"packageManager": "yarn@1.22.22"

Then run install-libs only for the backend folder (src is the folder with your .NET projects):

abp install-libs -wd src
cd angular
yarn install

The host always gets Yarn 1 and the Angular app gets Yarn 4, no matter which Yarn version is active globally. If someone runs abp install-libs from the root folder by mistake, the Angular step fails with an error instead of rewriting yarn.lock.

Thanks

Hi,

There are two problems here.

First, your AdministrationService turns off all three dynamic definition stores, and your IdentityService turns off the permission one. The microservice template turns them on. Your web app gets its permissions and features from the AdministrationService (/api/abp/application-configuration). With these stores off, it only sees its own definitions, so Account and Chat never show up, even when the tables have data. The IdentityService has the same problem when it grants permissions to the admin role.

Set them back to true in GreenWave365AdministrationServiceModule:

Configure<PermissionManagementOptions>(options =>
{
    options.IsDynamicPermissionStoreEnabled = true;
    options.SaveStaticPermissionsToDatabase = true;
});

Configure<FeatureManagementOptions>(options =>
{
    options.IsDynamicFeatureStoreEnabled = true;
    options.SaveStaticFeaturesToDatabase = true;
});

Configure<SettingManagementOptions>(options =>
{
    options.IsDynamicSettingStoreEnabled = true;
    options.SaveStaticSettingsToDatabase = true;
});

And in GreenWave365IdentityServiceModule:

Configure<PermissionManagementOptions>(options =>
{
    options.IsDynamicPermissionStoreEnabled = true;
    options.SaveStaticPermissionsToDatabase = true;
});

Second, the empty tables in staging. These definitions are not seeded by a migrator. Each service writes its own definitions to the Administration database when it starts, but it skips the write if the hash stored in Redis matches the current definitions. So if the Administration database was recreated, or staging shares the same Redis and key prefix with another environment, the tables stay empty and nothing is logged.

Find and delete these keys in the Redis that staging uses. GreenWave365: is the AbpDistributedCache:KeyPrefix in your appsettings, change it if staging uses another one. Add --tls or -n <db> if your staging Redis connection needs them:

redis-cli -h <host> -p <port> -a <password> --scan --pattern "GreenWave365:_*_AbpPermissionsHash"
redis-cli -h <host> -p <port> -a <password> --scan --pattern "GreenWave365:_*_AbpSettingsHash"
redis-cli -h <host> -p <port> -a <password> --scan --pattern "GreenWave365:_*_AbpFeaturesHash"

redis-cli -h <host> -p <port> -a <password> DEL <key1> <key2> ...

Then deploy the change and restart all services. IIS starts an app on the first request by default, so call each service once, for example its health check URL (/health-status by default). The definitions are saved in the background, so wait a minute and run your SQL queries again.

If the admin role still doesn't have the Account and Chat permissions after that, restart the IdentityService once more. It grants the permissions to the admin role when it starts.

To avoid this later, use a separate Redis for each environment, or set a different AbpDistributedCache:KeyPrefix for staging in all apps. If you recreate the Administration database and keep the same Redis, delete these keys again.

If the tables are still empty, check the AuthServer (Account) and ChatService (Chat) logs. Your HostOnlyConnectionStringResolver logs the server and database it resolves, so you can see which database they write to. You can also send the logs to liming.ma@volosoft.com.

Thanks