Hello.
I have a message reporting system. When a user writes and saves a message, the message is tied strictly to that user view their TenantID. All "related" (connected in some table) other Tenants can see this message. I think ABP automatically writes TenantId on Create, but I would like to know, which layer of the system does this responsibility technically lye in? Application or repository? Or even domain (constructor of the entity doesn't have session info though)
Next question is: We have an order system. This means there are 2 tenant ID's written on the order entity. This is fine. After an order is processed, a "shipment" is created by the person sending it. In this case, and for the sake of indexing, we have both tenant1 and 2 on the shipment (normalized, we could read this from the related order, but its slow so we have to denormalize). Where would the responsibility for this lie? Would this be a domain logic thing and so, the constructor for a shipment should take an Order?
Thanks
5 Answer(s)
-
0
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"?
-
0
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:
- 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.
- 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....
-
0
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.
-
0
Surely the user sessions must be kept somewhere serverside as well...
-
0
Hi,
I will try to answer your questions like this, but don't take them as final answers, because some of your questions are related to your domain and they have different answers :).
If you want multiple tenants to see a record, when you insert this record to creator tenant's database, then you can insert it to host database (You will need a seperate table if hostDb and tenantDbs are different). You can use domain events for this. <a class="postlink" href="http://www.aspnetboilerplate.com/Pages/Documents/EventBus-Domain-Events">http://www.aspnetboilerplate.com/Pages/ ... ain-Events</a> Whenever a message entity is created, updated or deleted you need yo sync the related record in hostDb. In this way, you can show this message to multiple tenants. (So, Don't use disable tenancy filter, because it does not work on DB per tenant architecture)
For your order question, I cannot say much but it seems definitely like a domain logic.
If your domain logic allows editing other factory users somehow, you can define permissions like you suggest.
