Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Issues with attachment on System records

Description

While testing https://idempiere.atlassian.net/browse/IDEMPIERE-6266 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

Environment

None

discovered while testing

Activity

Show:

Carlos Ruiz January 6, 2025 at 12:04 PM

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”

Carlos Ruiz November 28, 2024 at 9:10 PM

Thanks

I reverted the PO change with https://github.com/idempiere/idempiere/commit/ecd2d8855db231bda8b2d93154c134b7477ebd8b
and added the line 1961 which was the correct fix.

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.

Fixed

Details

Assignee

Reporter

Fix versions

Priority

Created November 24, 2024 at 1:00 PM
Updated March 1, 2025 at 9:49 AM
Resolved January 8, 2025 at 10:39 AM