Long UserID

[Diego Zuniga]

We currently have a user with a very long User ID, which is causing an issue when uploading files through the Attachment widget in Catalog Items.

The user's User ID is:

name1name2.lastname1lastname2@email.com

Due to its length, the system does not allow attachments to be added.

However, I cannot modify the User ID because doing so would impact the user's access to the environment and could also affect SSO authentication.

What options do I have to resolve this issue without changing the User ID?

[Tanushree Maiti]

Hi @Diego Zuniga ,

For one of our clients, we faced the same issue because the domain name was long. As a result, when the user ID was also long, it got truncated.

To address this, we increased the user ID field length from 40 to 80 characters (if I recall correctly). In our case, this change did not affect SSO.

You may want to test this in your sandbox once to confirm it works as expected.

[radha050903]

Hello @Diego Zuniga ,

Yes, this can happen because (sys_user.user_name) is a String field with a fixed maximum length. If the user's email ID exceeds that limit, which cause issues.

You can increase the Maximum Length of the user_name field by navigating to System Definition → Dictionary (sys_dictionary), searching for the user_name field on the sys_user table, updating the Maximum Length (for example, from 40 to 80), and then testing the attachment upload.

I strongly recommend validating this change . 

[yashkamde]

Hello @Diego Zuniga ,

Lokk for the property name : glide.attachment.max_filename_length

If it doesn't exist, I would suggest create it manually:

• Name: glide.attachment.max_filename_length
• Type: integer
• Value: e.g 1024

Also you can look for file_name gets built in the Attachment widget and shorten that concatenation.

If my response helped mark as helpful and accept the solution.

[DavidW447091066]

I wouldn’t change the User ID if it could affect SSO or access. Check with support whether this is a known Attachment widget limitation or if there’s a patch/workaround. Another option is to use an alternative attachment method until the issue is fixed.