Hi alper, thank you for the answer. There is a difference whether a service is down once every couple of years or once every couple of months. Anyway, I had forgotten about the local nuget cache. Of course we can use that as the source and push the packages to our Azure Artifacts feed. Thanks for the tip!
It turns out that abp has made custom nuget package source(some bicycle), which works like a xmas tree. Not a first time and not a last one when it's down, I assume. If you use a azure devops I would highly recommend to enable custom artifact feed. It has built-in capabilities to Azure devops and forward restores to it.
You cannot use custom feed for nuget packages in Azure Artifacts. That's why I suggested a method to enable package loading from the abp nuget server. If this was possible, we could download the packages and push them to Azure Artifacts feed (or where ever). Seems like MS is not going to implement the custom nuget feed capability any time soon.
This happens from time to time (too often I would say) and interferes with our deployments when it happens. This would mitigate the problem so we could cache the packages. https://support.abp.io/QA/Questions/5549/A-way-to-list-all-nuget-packages-from-Abp-nuget-server
Still not clear enough for me, sorry :) Can we "override the default UI to show the displayname instead of name" , without downloading and customising the source code.
Please clarify how. Do you mean adding the DisplayName as extra property? Will the display name already by visible in the UI or do we still need to create the custom page?
Ok, how about customizing the roles page so it would use the normalised name as localisation key. Then in that tenant, the role names could be visualised in a different language. Is this something we could easily do by just replacing the one page or do we need to pull the whole identity pro module to our sources?
Yes, we haven't customized the login page, so it is a weird situation. Anyway, closing the ticket since we got it working. Thank you
I got this fixed by installing the old Abp 5 version back, saving the EnableLocalLogin setting as true from the Account settings and re-installing the new version. I think that I was not able to refresh the cache after all. I guess the Abp 7 (or 6) version contained a bug fix that now the setting is correctly considered in the login page? However, I noticed that one of our tenants also had that setting as False, and their login page did not give that error. There might still be the same bug in the tenant side?
Yes, that seems to work. I got the impression that that was the fix for the hanging tests, but everything seems to work without it. Thank you for your help!
Ok, thanks. Do you have any suggestions on how to handle our current problem? We didn't have nested transactions problem before, but now we do. What caused the change? Why does the nested transactions problem occur during the tests? As far as I know, Abp unit of work system should be able to recognize if there is a transaction open already.