Hi all,
We have a Multi-Space enabled environment, we found that record of different space was referenced in an imported record, which was created via upload of Excel file through Import button in Table Block.
e.g.
Vendor Collection Fields:
- spaceName, vendorID (Auto increment), vendorCode, vendorName
Item Master Collection Fields:
- spaceName, itemID (Auto increment), itemCode, vendorID (belongs To Vendor Collection), itemName
Existing Vendor Data In System:
- spaceName=A, vendorID=1, vendorCode=V01, vendorName=Vendor 01.
- spaceName=B, vendorID=2, vendorCode=V01, vendorName=Vendor 01.
Import Excel Template Columns:
- Item Code, Vendor/Vendor Code, Item Name.
Excel File Content:
- Item Code=SKU01, Vendor/Vendor Code=V01, Item Name=Product 01.
Imported Data In Item Master Collection when performed the import at space A:
- spaceName=A, itemID=1, itemCode=SKU01, vendorID=2, itemName=Product 01.
When we traced the SQL statement, we found that the import function didn’t filter the record with spaceName, it only filtered the vendorCode, sort the records and returned the first matched record.
Wonder is this considered a bug in an Multi-Space enabled environment?
Or such design is fine in such environment?
Thanks.
Hello, this is how it’s designed: when importing related data, you need to use a unique value field with identifying capabilities.
Hi @hongboji ,
When using auto increment unique value field as the import field, and users accidentally entered the unique value which belongs to another space, import function didn’t reject it and import it successfully. Isn’t this breach the design of Multi-Space, the isolation of data in different spaces?
Import Excel Template Columns:
- Item Code, Vendor Id, Item Name.
Excel File Content:
- Item Code=SKU01, Vendor Id=2, Item Name=Product 01.
Imported Data In Item Master Collection when performed the import at space A:
- spaceName=A, itemID=1, itemCode=SKU01, vendorID=2, itemName=Product 01.
Hi @hongboji ,
When such data is created in the system successfully, the data of the linked record in another space might be retrieved. It does not seem to be correct design.
Multiple spatial data can be viewed simultaneously.
Hi @hongboji ,
How the current spotted outcome comply with the design principles mentioned in the shared page?
Hi @hongboji ,
We believe the spotted issue is a bug instead of a design of the import function under Multi-Space enabled environment, reason being that:
- The system does not ensure that the independent data of each business unit does not interfere with each other.
- For data tables with a space field, the system does not automatically enforce the created data automatically associated with the currently selected space, and return only records within the currently selected space when filtering the data.
Looking forward to your reply on this.
Thanks.
I understand your question. However, the multi-space feature does not provide complete tenant-level isolation across the entire system. It only provides on-demand isolation on individual collections. When data is created in a collection containing a space field, it is assigned to the current space by default. Multi-space supports querying multiple spaces when querying data; for complete application-level isolation, please use the multi-application feature instead.
For related data, During import, relationships are resolved based on the relevant collections. Therefore, we recommend using business fields that uniquely identify related records, rather than values that might repeat in different spaces.
Hi @hongboji ,
We understand and we can train users to use an unique identity field, e.g. ID field, to link the records under same space; but the current issue is the import function does not block the import but to create a new record referencing another space’s record when an ID of another space’s referenced record is specified. This has created a loophole in the function.
It does not function according to the following rule:
