Hi, I'm also having trouble using EF.Extended because we are in a transaction scope aready
<cite>ismcagdas: </cite> Hi,
I think it is better to make this control in your AppService method before the edit operation. Don't put methods like CanEditProduct, CanDeleteProduct or CanEditAnyProductsFromTenant because they are entity specific. If you follow this approach, you will have so many methods in the PermissionManager.
Instead of doing this, you can define permissions like CanEditProduct, CanDeleteProduct and use them attributes on your application service method.
You can check CanEditAnyProductsFromTenant in the application service method's beginning.
I understand, and this is actually the approach I have ended up taking.
This is actually what I was doing before I learned about Abp, but I started to think it was the wrong way since I learned about permission based stuff and whatnot. Now it turns out it was more complex than that and my initial solution was a good one.
Thanks
Ok, It is not ACL, but UAC (User Access Control) I am looking for: <a class="postlink" href="http://stackoverflow.com/a/1342406/1079267">http://stackoverflow.com/a/1342406/1079267</a>
So, it is suggested that this is implemented in the repositories. I can see two ways of doing this.
1) Create different repositories for different groups of a single entity. OurProductsRepository, LocalSuppliersProductsRepository
2) Inside the repository create permission functions which take the user and the Id of the Entity and compare them using MAD LOGIC to decide if they can or cannot edit them. This would require adding an Edit property to the Entity (which isn't stored in the database).
Any suggestions about how else to implement this in such a way, using ABP?
How about, functions in the PermissionManager:
CanEditProduct(int Id) CanDeleteProduct(int Id) CanEditAnyProductsFromTenant(int Id)
?
So far, I can understand that we need to be able to call a function on an Entity to be able to determine if this is doable: Product.CanEdit
This makes sense, but where exactly would be the best place to implement this? It feels like it would be easier to place it into the creation of Product.Dto, so that all other subDtos can also use it.
Any ideas?
It seems what I am actually leaning towards is ACL (Access Control Lists), I have no experience with this stuff, but I would like to know where/how this would be easily implemented with ABP.
This post: <a class="postlink" href="http://stackoverflow.com/questions/1335315/access-control-in-asp-net-mvc-depending-on-input-parameters-service-layer/1336404#1336404">http://stackoverflow.com/questions/1335 ... 04#1336404</a>
Wait seriously how DO we stop a user from updating any user just by fiddling with the ID on the clientside? A permission is kind of "tablewide" So allowing UpdateUsersPermissions is too broad. Halp.
OK NEXT QUESTION!
We have factories. Factories have Users, and one User is an Admin user. The Admin user can also see the users of other factories. But they can only edit users of their own factory.
Create is fine, because we can modify the actual entitiy by settings its TenantID before it is saved. Update though... the CrudAppService doesn't take the original entity for Updates, so how am I supposed to inject the TenantId to ensure it overwrites any tenantID they send?
OPTIONS:
Is there supposed to be some kind of generic "compare to self" functionality which compares the "distance" of an Entity in relation to the current user. So for example. Me -> me = 0 EditSelfPermission Me->FactoryUser = 1 EditOwnFactoryUserPermission Me->OtherFactoryUser = 2 EditAllFactoryUsersPermission
??? Seems elaborate but....
Hello, I've realized that actually I cannot put a Tenant ID on my Messages class, because that means nobody would be able to read it except the person who created it.
So how is this kind of logic supposed to be implemented? Do I "Disable Tenancy Filter" when I try to "GetAll" in my "MessageAppService"?
Perfect thank you. I totally saw this before and completely forgot about it.