API returns error when Note lacks attachment #4482

New issue

Open

opened 2026-02-20 16:18:07 -05:00 by deekerman · 0 comments

deekerman commented

2026-02-20 16:18:07 -05:00

Owner

Originally created by @tsummerer on GitHub (Feb 3, 2021).

API returns error when Note lacks attachment

Issue

When doing a Patch of a Note record - if your client has the filename attribute present, then the application assumes that you're trying to upload a file. It assumes this even if the filename is empty. An empty attribute causes the endpoint to throw an exception and return an error to the client.

When you GET a Note bean, it returns the filename attribute as an empty string (if there is no file). It is not uncommon for a client to return that same object for a PATCH - so the application should not fail if this attribute is blank.

This is not a special field type - it should probably not be the trigger to initiate an upload and it certainly should accept blank values.

Error introduced by #8408

Expected Behavior

If you PATCH a Note with a blank filename, the request should not fail.

Actual Behavior

If you PATCH a Note with a blank filename, the application tries to do a file upload and fails when it cannot interpret the filename.

Examples:
GET a Note:

GET : {{INSTANCEURL}}/Api/V8/module/Notes/2aed145d-8ff9-b4ea-e8c0-5fc93a0a08fc
{
    "data": {
        "type": "Note",
        "id": "2aed145d-8ff9-b4ea-e8c0-5fc93a0a08fc",
        "attributes": {
            "assigned_user_id": "1",
            "date_entered": "2020-12-03T19:20:00+00:00",
            "date_modified": "2021-02-03T23:13:00+00:00",
            "name": "Mobile Note",
            "file_mime_type": "",
            "file_url": "",
            "filename": "",
            "description": "A test note",
            ...
        },
        "relationships": {
            ...
        }
    }
}

If your client edits the description and tries to pass the object back to the API, it will fail

PATCH {{INSTANCEURL}}/Api/V8/module
{
  "data": {
    "type": "Notes",
    "id": "2aed145d-8ff9-b4ea-e8c0-5fc93a0a08fc",
    "attributes": {
	  "description" : "A new description",
          "filename": ""
          ...
    }
  }
}

Response:

{
    "errors": {
        "status": 400,
        "title": null,
        "detail": "File upload failed: File extension is not included or is not valid."
    }
}

Possible Fix

At a minimum, line 378 in ModuleService.php should have a !empty() condition added

} elseif ($property === 'filename' && !empty($value)) { 
    $createFile = true;
    continue;
}

Steps to Reproduce

Create a Note that does not have an attachment
Attempt to edit this note via the API, pass filename as a blank string

Context

Our mobile app builds objects based on vardefs. It uses these objects when communicating with the API. It's unable to edit Notes that do not have attachments because Suite won't accept a blank filename

Your Environment

SuiteCRM Version used: 7.11.18
Browser name and version (e.g. Chrome Version 51.0.2704.63 (64-bit)): n/a
Environment name and version (e.g. MySQL, PHP 7): LAMP
Operating System and version (e.g Ubuntu 16.04): Ubuntu 16.04

Originally created by @tsummerer on GitHub (Feb 3, 2021).    API returns error when Note lacks attachment #### Issue   When doing a Patch of a Note record - if your client has the `filename` attribute present, then the application assumes that you're trying to upload a file. It assumes this even if the `filename` is empty. An empty attribute causes the endpoint to throw an exception and return an error to the client. When you `GET` a Note bean, it returns the `filename` attribute as an empty string (if there is no file). It is not uncommon for a client to return that same object for a `PATCH` - so the application should not fail if this attribute is blank. This is not a special field type - it should probably not be the trigger to initiate an upload and it certainly should accept blank values. Error introduced by #8408 #### Expected Behavior  If you `PATCH` a Note with a blank `filename`, the request should not fail. #### Actual Behavior   If you `PATCH` a Note with a blank `filename`, the application tries to do a file upload and fails when it cannot interpret the filename. Examples: GET a Note: ``` GET : {{INSTANCEURL}}/Api/V8/module/Notes/2aed145d-8ff9-b4ea-e8c0-5fc93a0a08fc { "data": { "type": "Note", "id": "2aed145d-8ff9-b4ea-e8c0-5fc93a0a08fc", "attributes": { "assigned_user_id": "1", "date_entered": "2020-12-03T19:20:00+00:00", "date_modified": "2021-02-03T23:13:00+00:00", "name": "Mobile Note", "file_mime_type": "", "file_url": "", "filename": "", "description": "A test note", ... }, "relationships": { ... } } } ``` If your client edits the description and tries to pass the object back to the API, it will fail ``` PATCH {{INSTANCEURL}}/Api/V8/module { "data": { "type": "Notes", "id": "2aed145d-8ff9-b4ea-e8c0-5fc93a0a08fc", "attributes": { "description" : "A new description", "filename": "" ... } } } ``` Response: ``` { "errors": { "status": 400, "title": null, "detail": "File upload failed: File extension is not included or is not valid." } } ``` #### Possible Fix  At a minimum, line `378` in [ModuleService.php](https://github.com/salesagility/SuiteCRM/blame/v7.11.18/Api/V8/Service/ModuleService.php#L378) should have a `!empty()` condition added ``` } elseif ($property === 'filename' && !empty($value)) { $createFile = true; continue; } ``` #### Steps to Reproduce   1. Create a Note that does not have an attachment 2. Attempt to edit this note via the API, pass `filename` as a blank string #### Context   Our mobile app builds objects based on vardefs. It uses these objects when communicating with the API. It's unable to edit Notes that do not have attachments because Suite won't accept a blank `filename` #### Your Environment  * SuiteCRM Version used: 7.11.18 * Browser name and version (e.g. Chrome Version 51.0.2704.63 (64-bit)): n/a * Environment name and version (e.g. MySQL, PHP 7): LAMP * Operating System and version (e.g Ubuntu 16.04): Ubuntu 16.04