Activities of "worthyvii"

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>

Hello, this is more of a design question than specific to ABP, but there are some smart people here so I wanted to hear your answers.

A user may be able to edit a Tenants details. So we need a "Edit Tenant" page. If a user can edit their own tenant, and other tenants (they are a kind of Admin), then they can use the same "Edit Tenant" page for all cases. When the user clicks save, I only need to check that they have the "Edit All Tenants" permission.

Some users, can only Edit their own Tenant. These users can still use the normal "Edit Tenant" page, however, this means that when the user tries to save, I need to check that the user has the "Edit Own Tenant" permission. But this requires creating a whole separate flow for the case where a user is editing their own Tenant. Which means at least putting an "if tenantId is session.tenantId" into the service methods. This feels wrong.

So my question comes down to, shouldn't it be some kind of CanUserEditTenant(input.TenantId) ?

This would require a lot of work under permissions, but would mean that all views, controller actions and service methods could be clean from any authorization work, and duplicate code. It would mean that all editing of a tenant would be one view, one controller action and one service method. The service method would call this function to check the permission.

Am I on the right track? If so, where should these "permission checking" functions be written? They will end up being quite elaborate.

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:

1. The absolute simplest way, is to use a UpdateFactoryUserInput, and allow it to have a TenantId field, even though the field will not be input by the user. Then I just overwrite whatever is on this field when it comes to my AppService.
2. Find the actual user from the UpdateFactoryUserInput.Id, in the database, get it's tenantID, and compare that with the sessionUsers TenantId. But isn't this some kind of permission check in that case? So should I be doing this elsewhere? If I do it here what error do I throw?

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"?