Base solution for your next web application

Activities of "piapps"

Thanks for confirming!

Hi guys,

I have added an appsettings.Development.json file to my Web.Host project for use on my local machine which works fine.

However the EntityFrameworkCore project must not use the file because whenever I do Update-Database it fails (unable to find sql instance) unless I put the correct conn string back into appsettings.json.

How or where can I adjust the connection string resolver so that .Development will be respected by migrations?

Im using v6.8.0

Regards, Pete

Neither using set or $env = seemed to work, any other ideas?

Hi again,

Sorry I should have been clearer in my response yesterday.

I have tried both the following and they dont work

set ASPNETCORE_ENVIRONMENT=Development

and

$env:ASPNETCORE_ENVIRONMENT='Development'

That worked thanks, better yet after setting that change to the factory I have gone into properties of the EFCore project and set the environment variable in there so it remembers between Visual studio sessions (same as the host project)

Thanks again

I have been playing around with wanting to do this myself too and just havent had time. I dont believe there is anything done by the zero team yet.

My thoughts are 3 levels of permissions for an entity

  • Any/All
  • Owner/Admin
  • Member (or user connected to entity)

So in principle you would setup CRUD permissions per each of the above EntityName.Any.Create EntityName.Any.Edit EntityName.Any.Delete

EntityName.Own.Edit EntityName.Own.Delete

EntityName.Member.Edit EntityName.Member.Delete

Then inherit from RepoBase with something like EntityPermissionCheckedRepositoryBase and overload/overwrite the repo methods you want to confirm permissions on for example if we had a Customer entity that had users who could view it (but not all users) you might have something like this

public override IQueryable<Customer> GetAll() { var query = base.GetAll(); if (!_permissionChecker.IsGranted(AppPermissions.Pages_Customers_Any)) { //if they cant see all then they are limited to ones they are a member of query = (from c in query join cu in Context.CustomerUsers on c.Id equals cu.CustomerId where cu.UserId == Context.AbpSession.UserId select c); } return query; }

 So the above will get the normal query from standard repo base.
 If the user is not allowed to see all customers then it will add a where clause to the entity to join with a table
 that says who cant see what and select the customer entity at the finish. This will basically mean that
 anyone with the Any permission can see all, while those without can only see ones they are connected with.
 
 You could then potentially make this generic using interface types and you could even go as far as create a generic entity to replace CustomerUsers (store the entity type name and entity id) and it could map to any entity.
 
 For insert/update/delete type permissions you would need to inherit permission checker and expand it to
 pass in entity you are checking against then check like above and throw error or fail silently. You could also
 cache the check result to stop unnecessary round trips during those operations
    

Im not suggesting this is the right way to go and i certainly havent had time to flesh it out properly but its a way i was thinkgin about. You could use an entityframework filter too like they do with tenant id

Hi guys,

We have ASPNet Zero solution running in two Azure App Services spread over 2 geographic locations and it works well, however both instances are running the same background jobs im guessing because the job query transaction is not blocking reading of the same rows.

So my question is can I simply implement my own background job store to lock the reading of rows (in effect making it only one instance can read any single job at a time) and fix the issue. Or is it more systemic than that and I would need to adjust other layers of the background job code?

I do want the ability for multiple instances to process jobs just not the same jobs, our project will probably end up scaling up to 3-6 instances over the coming months with one of the purposes to utilise the job system accross all of them

Thanks in advance

I was going to check that out as well but still wondering if my solution above is viable?

I will have a look thanks

Thanks for the suggestion maliming i didnt realise that with zero hangfire is fully setup to go already i just had to toggle the variable in WebConsts and replace the service in Web Module and was up and running.

Works great, I turned the WebConsts flag into an app setting and added a setting for worker count because 20 was too CPU heavy per instance and it now works great.

Thanks for making it easy!

Showing 11 to 20 of 25 entries