ABP Framework version: v5.1.0
UI type: Angular
DB provider: EF Core
Tiered (MVC) or Identity Server Separated (Angular): yes
According to this advice https://support.abp.io/QA/Questions/2284/Concurrency-handling-clarification-question , we now implemented updating concurrency stamp in every update method. However, we now have a problem that the "conflict" return value is not handled correctly in our Angular app. Backend returns 409 as expected. We get an exception page instead of an error dialog telling the user about the error like it was shown in the linked answer. I assumed that of course there is a default handling for conflict type return code, but couldn't find it from the angular source code.
Steps to reproduce the issue:" Add concurrency stamp update to an entities update method in application service, then update the entity concurrently from Angular UI
ABP Framework version: v5.1.1
UI type: Angular
DB provider: EF Core
Tiered (MVC) or Identity Server Separated (Angular): yes
Problem: After the update from 4.3.0, our Angular client is refreshing the token every second. I assume this is not normal. Can we adjust the refresh interval somehow or is there a bug somewhere?
Ok, thanks for your answer. I'm also interested in the longer version of the answer :) In what situations do you see it's ok not to use that method? Suite templates and at least earlier versions of easy CRM do not implement this. Is this a coming change to the templates?
Hello, I would very much like this clarified: https://docs.abp.io/en/abp/5.0/Concurrency-Check . Here it says that the concurrency stamp and check is managed by Abp: https://docs.abp.io/en/abp/latest/Entities#basicaggregateroot-class However, I now noticed that, at least in some Abp modules, the concurrency stamp is cycled via UI to update Dtos.
From this https://github.com/abpframework/abp/issues/3351 and from the docs I get the impression that the cycling is not needed but why is it implemented so at least in some modules here for example
My question is that should we always cycle the concurrency stamp through UI or in which cases we should do so.
I have no doupt that saving isn't a problem with this. To be clear, I haven't tried any solution yet, hence the "Design Question". However all the examples I have seen define the extraproperty name staticly and I'm trying to figure out if this king dynamic definition would work as well. If you have some sample code, I will gladly take a look at it :)
Hello, I think the JSON-field will suffice. But the problem isn't that can we map it to another table or not. The problem is that the meaning and value types change will change accross different tenants. For example: Tenant1 needs an additional property "SocialSecurityNumber" which is of type string but Tenant2 doen't care about that information. It needs an additional property "PersonLength" of type integer. We cannot know in advance what additional information each tenant needs, so the properties cannot be defined in advance like in the SetProperty-example. The JSON value would be created dynamically to the database by an external system (an integrator).
We have a situation where we should attatch some extra information to our entites. For example: EntityX has some properties and in addition Tenant1 needs to see extra property "Xyx" and it's value in UI. Tenant2 also needs extra property for EntityX but with different name "Abc" and possibly different value type. These extra properties cannot be determined at build time. At our old solution we just had extra columns for some database tables and meaning of the value was taken care of in customer guidance. I'm looking for more elegant solution than that and was wondering if the Extra Properties -model could provide the solution?
ABP Framework version: v4.4.3 Exception message and stack trace: No exceptions Steps to reproduce the issue: We have Project with Quartz for background workers and a project that contains Background jobs. The jobs are default Abp AsyncBackgroundJobs. With this configuration when ever I enqueue a background job to be excecuted, the excecution is done multiple times if background job excecution time exceeds the background job poll interval. If I unload the project that includes the AbpBackgroundWorkersQuartzModule, the background job is excecuted correctly (only once)
Hello, As it says here https://docs.abp.io/en/abp/latest/Background-Workers-Quartz default Abp background jobs are executed "on top of each other" if they are long running and the job polling interval is shorter. Same job is executed multiple times. This occurs only when Quartz is used with background workers. As the documentation suggests, I added AbpQuartzBackgroundJobs dependency to fix this, but this did not help. Is is so that I cannot use the default background job abstractions in this case and have to use only Quartz's abstractions all the way?
And we should always set the tenant Id as well?
