Sorry I didn't explain the issue very well. I've managed to figure out what was happening. Basicially we had two separate databases Shout (top layer) and Survey (module). Sqlite was destroying /overwriting the module later in this use case.
Can you please confirm that this is the correct way to resolve the issue? If it is then it should probably be documented in your Integration Test setup section.
#ShoutEntityFrameworkCoreTestModule.cs
namespace Shout.EntityFrameworkCore;
[DependsOn(
typeof(ShoutEntityFrameworkCoreDbMigrationsModule),
typeof(ShoutTestBaseModule),
typeof(AbpEntityFrameworkCoreSqliteModule)
)]
public class ShoutEntityFrameworkCoreTestModule : AbpModule
{
private SqliteConnection _sqliteConnection;
public override void ConfigureServices(ServiceConfigurationContext context)
{
context.Services.AddAlwaysDisableUnitOfWorkTransaction();
ConfigureInMemorySqlite(context.Services);
}
private void ConfigureInMemorySqlite(IServiceCollection services)
{
_sqliteConnection = CreateDatabaseAndGetConnection();
services.Configure<AbpDbContextOptions>(options =>
{
options.Configure(context =>
{
context.DbContextOptions.UseSqlite(_sqliteConnection);
});
});
}
public override void OnApplicationShutdown(ApplicationShutdownContext context)
{
_sqliteConnection.Dispose();
}
private static SqliteConnection CreateDatabaseAndGetConnection()
{
var connection = new SqliteConnection("Data Source=:memory:");
connection.Open();
// Configure logging for SurveyDbContext
var surveyDbOptions = new DbContextOptionsBuilder<SurveyDbContext>()
.UseSqlite(connection)
.EnableSensitiveDataLogging() // Include parameter values in logs
.LogTo(Console.WriteLine, LogLevel.Information) // Log SQL queries to console
.Options;
// Configure logging for ShoutMigrationsDbContext
var shoutMigrationsDbOptions = new DbContextOptionsBuilder<ShoutMigrationsDbContext>()
.UseSqlite(connection)
.EnableSensitiveDataLogging()
.LogTo(Console.WriteLine, LogLevel.Information)
.Options;
// Create tables with logging enabled
new SurveyDbContext(surveyDbOptions).GetService<IRelationalDatabaseCreator>().CreateTables();
new ShoutMigrationsDbContext(shoutMigrationsDbOptions).GetService<IRelationalDatabaseCreator>().CreateTables();
return connection;
}
}
How about integrating an adapter for integration services like Zappier, automate, pabbly connect?
Your feature request thread was auto closed btw.
We love the framework but support and bug reporting is not handled well. My developer has mostly given up reporting issues as he says it's not worth it as responses tend to be one line, minimum effort answers. Complex issues often just get auto-closed without resolution.
I don't mind the one line answers but they should not be considered a paid response to an issue when we only get to report 15 a year. Basic forum responses should not be included in any limit.
I would suggest you take a look at how service stack (https://forums.servicestack.net/) handle this for a fraction of the price. With a unlimited support forum for paid users with a smaller number of private escalated incidents.
There is very little in the commercial package we use as we have our own UI framework, we're basically just paying for the support forum.
The point is that this is the wrong way around, and I'm guessing by mistake, not by design.
Specific items would always override group permissions. To use a file system as an example, a file permission would override the inherited folder permission. With ABP you have it the other way around which has no use case that I can see.
It should be:
Tenant default permissions are inherited from Edition, but permissions set on the tenant are not overwritten by Edition.
Example. If a feature is causing an issue for a specific customer, we would disable it on their tenant, not the entire edition.
I've been in contact with the author of Rebus and they've confirmed to me that the behaviour is intended.
Connection errors bubble up to the calling app (in this case ABP) and any retry logic needs to be handled there.
https://github.com/rebus-org/Rebus.RabbitMq/issues/98#
If you follow your own link then you will see that the issue was moved to the following issue and then marked as Completed
https://github.com/rebus-org/Rebus.RabbitMq/issues/3
Currently our application fails every time the server is rebooted and there doesn't appear to be any obvious way to correct this from our side.
Is there no way to put a short say 5 second delay and retry loop into the rebus setup code?
Seems to be working. Can the Google sign on URL be obtained in anyway so that we can pass it to our front end (static cdn deployed) via an api call? It would be nice to have the button on the homepage.
We could do some hacky iframe thing but I thought there might be a better way.
Thanks I'll taker another look, it may be that we have made a mistake with the merging of the IDS MVC pages as we have several overrides setup and may be using some outdates files.
Regarding the flow, I took another bash at designing something that matches how ABP handles tenants.
For standard logins logins I've moved password to a later page once the tenant is identified, either by the custom tenant handler or by the tenant selection page.
Are there any plans to implement a tenant selector page like this? This seems like too much custom code to safely add to our project without causing a security issues if we ever failed to merge changes correctly. If not, any idea how best to approach this?
