Hello!
While investigating I’ve found that when copying attachment field, actually an integer is copied (I assume it’s an attacment id). So when Owner pastes this id into attachment field it gets converted into an actual attachment with that id. But when Editor does so — no conversion takes place, and an error is fired.
Another interesting aspect: when there is more than one attachment it the cell it would copy and paste successfully with Editor access.
Hi @genkush , this sounds very like this issue:
opened 10:01AM - 17 Apr 25 UTC
closed 08:15PM - 23 Apr 25 UTC
# Describe the current behavior
Here's a very _very_ specific bug that took us … almost a month to pin down properly. Will look into contributing an improvement although the conditions for this to happen are very involved.
On a big document with very complex Access Rules, some editors were complaining that they sometimes could not upload attachments if there already was an attachment uploaded by someone else in a cell. They were met with a very criptic error : `SQLITE_ERROR: malformed JSON`. Owners could make the upload, editors could upload their own attachments in new lines, but could not update an attachment cell.
After some digging, it appears that this was due to the function [_checkIncomingAttachmentChanges](https://github.com/gristlabs/grist-core/blob/881253352e81642a90c2499cd5c340cfc6945437/app/server/lib/GranularAccess.ts#L2384) calling [findAttachmentCellForUser](https://github.com/gristlabs/grist-core/blob/881253352e81642a90c2499cd5c340cfc6945437/app/server/lib/GranularAccess.ts#L562) which executes [findAttachmentReferences](https://github.com/gristlabs/grist-core/blob/881253352e81642a90c2499cd5c340cfc6945437/app/server/lib/DocStorage.ts#L1450) which itself executes some SQL code against the .grist sqlite db :
https://github.com/gristlabs/grist-core/blob/881253352e81642a90c2499cd5c340cfc6945437/app/server/lib/DocStorage.ts#L1450-L1469
This SQL query can fail if what's passed to `json_each(t.${quoteIdent(colId)})` is not valid JSON. **This can for example happen if the attachment column that's being checked is a function that sometimes raises an error (for example, a lookup function).**
## Quick fix
The easiest way to fix this issue is simply to make sure that the functions you write in your document don't raise errors (for example, you could use a simple try/except syntax) 🙃
# Steps to reproduce
Here's a basic .grist illustrating the behavior : https://docs.getgrist.com/hPVCwAMMWJhN/malformedJSON/p/1
To reproduce, you need to :
- upload an attachment as an owner of the document inside the "Depense" table
- add "editeur@random.net" as an editor on the document and **set some access rules for that user**
- use "View As" mode and switch to editeur@random.net
- observe that you cannot add a second attachment to the "BC" column of the "Depense" table
[Go back to being an owner, fix the BC formula column in the SF table so that there are no errors]
- use "View As" mode and switch to editeur@random.net
- everything works again :)
# Describe the expected behavior
I think the findAttachmentReferences function could be made to be more resilient in the case of an error.
At the very least, more explicit error logging would be useful : the current error message is quite cryptic
# Where have you encountered this bug?
- [x] On [docs.getgrist.com](https://docs.getgrist.com)
- [x] On a self-hosted instance
Is it possible you’re running an out of date version of Grist?
1 Like
It may be outdated but not that much. I think we last updated in may. But I’ll consider updating again
I can’t find that specific access type in access settings. Could you please specify where to search?