add an optional install-level limit for internal attachment storage #1729
Conversation
Add support for `GRIST_MAX_INTERNAL_ATTACHMENTS_BYTES` which, if set, will cause Grist to refuse to add new attachments if the current document is not set to use external attachments and the total attachment size would exceed this amount. Technically Grist docs can have attachments in several stores. This limit ignores that nuance.
| // If not using external attachments, apply installation limit on size. | ||
| // Technically the attachmentStoreId being set doesn't mean all attachments | ||
| // are actually stored externally, and a determined person could | ||
| // work around this limit at the API level. That's fine, their | ||
| // reward will be pain. |
There was a problem hiding this comment.
Agreed! I can imagine an in-UI workaround for this too (set to external, upload, transfer to internal).
I think either:
- This is completely fine, and pain shall become their companion
- We apply the limit during transfers too
I'll leave that up to you!
There was a problem hiding this comment.
I added a thing where if starting a transfer to internal, limits are checked. Since it is easy to imagine a doc with a lot of attachments stored externally, then user clicking to make internal to e.g. make the doc standalone. Let me know if it looks ok. Didn't get into nuance of trying to free up space if there are lingering attachments on the road to deletion. It is a little silly since all transfers will fail if total attachment size is greater than limit, and communication with user is poor about errors. But it could be easily improved if this is a corner users do in practice find themselves in.
Add support for
GRIST_MAX_INTERNAL_ATTACHMENTS_BYTESwhich, if set, will cause Grist to refuse to add new attachments if the the total attachment size would exceed this amount, and the current document is not set to use external attachments.Technically Grist docs can have attachments in several stores. This limit ignores that nuance.