While testing I found some bad scenarios related to attachments on system records:
Test case with a System record, in my tests I used AD_SysConfig_ID=200234 (UPLOAD_TEMP_FILENAME_PREFIX).
Marked in red what I consider errors
Test Case 1 - attachment on Garden for a System record :
Login as GardenAdmin and upload an attachment on GardenWorld into the Record on System -> the record is created with ad_client_id=11
Login as System:
System user can see the attachment and/or delete it
System user can upload new attachments, this doesn't change the ad_client_id or create a new attachment (it could not create a new one because table+record is a unique key)
notice that here the System user doesn't have any clue that the attachment being uploaded is visible in GardenWorld tenant
Login as GardenWorld
it can also see the attachment created by System user
it can also delete the attachment file uploaded by System user
Login to a SecondTenant
the attachment button is presented as pressed indicating there is an attachment
the user cannot see attachment because of error "Cross tenant PO reading request detected"
Test Case 2 - attachment on System for a System record:
Login as System and upload an attachment on System into the Record on System (the record must not have previous attachments) -> the record is created with ad_client_id=0
Login to GardenWorld or a SecondTenant
the attachment button is presented as pressed indicating there is an attachment
the user can see the System attachment
the user can delete a file in System attachment, but it cannot save the AD_Attachment record
with DB storage provider the user cannot save it and everything is OK
with FileSystem storage provider (or others external like S3) the file is deleted from the storage provider, creating an orphan attachment
the user can upload a new file but it cannot save it
Reopening this issue - the validation on MAttachment.isReadOnly is stopping the orphan records to be deleted, for example with the process “Clean Orphan Cascade Records”
The thing is that the PO.is_new was broken for UUID key tables when loaded programmatically - it was working from the UI, but not loading the PO from java code.
Heng Sin Low November 28, 2024 at 1:45 PM
hi , the error of AD_OrgInfo is cause by the setKeyInfo() change. I’m not sure what’s the intention of the change but it is breaking table that don’t have _ID primary key and uses parent key.
Heng Sin Low November 28, 2024 at 12:48 PM
For ad_message_trl, you can’t make any update since m_IDs[0] (which is AD_Message_TRL_UU) is null and is_new() will always return true.
Heng Sin Low November 28, 2024 at 12:45 PM
I think it make saving of AD_OrgInfo fail as well.
While testing I found some bad scenarios related to attachments on system records:
Test case with a System record, in my tests I used AD_SysConfig_ID=200234 (UPLOAD_TEMP_FILENAME_PREFIX).
Marked in red what I consider errors
Test Case 1 - attachment on Garden for a System record :
Login as GardenAdmin and upload an attachment on GardenWorld into the Record on System -> the record is created with ad_client_id=11
Login as System:
System user can see the attachment and/or delete it
System user can upload new attachments, this doesn't change the ad_client_id or create a new attachment (it could not create a new one because table+record is a unique key)
notice that here the System user doesn't have any clue that the attachment being uploaded is visible in GardenWorld tenant
Login as GardenWorld
it can also see the attachment created by System user
it can also delete the attachment file uploaded by System user
Login to a SecondTenant
the attachment button is presented as pressed indicating there is an attachment
the user cannot see attachment because of error "Cross tenant PO reading request detected"
Test Case 2 - attachment on System for a System record:
Login as System and upload an attachment on System into the Record on System (the record must not have previous attachments) -> the record is created with ad_client_id=0
Login to GardenWorld or a SecondTenant
the attachment button is presented as pressed indicating there is an attachment
the user can see the System attachment
the user can delete a file in System attachment, but it cannot save the AD_Attachment record
with DB storage provider the user cannot save it and everything is OK
with FileSystem storage provider (or others external like S3) the file is deleted from the storage provider, creating an orphan attachment
the user can upload a new file but it cannot save it