Fix #399 Make max attachments configurable
Default value is 16 attachments (4 rows of 4 thumbnails) to bump it up from the previous hard coded 9. There's no absolute max for the user configured max amount.
Merge request reports
Activity
186 187 }, 187 188 useContainFit (value) { 188 189 this.$store.dispatch('setOption', { name: 'useContainFit', value }) 190 }, 191 maxThumbnails (value) { 192 if (value < 0) { 193 value = 0 194 this.maxThumbnails = 0 
I was able to input negative values without it
edit: or if you meant the this.maxThumbnails yeah that I should remove
Edited by Shpuld Shpludsonchanged this line in version 2 of the diff
-
Looks ok. Two suggestions:
- Make it instance-configurable
- people will be less angry for developer-imposed limitations, so that smug for example can bump it to 32 or infinity (see pt.2) or something
- would be easier for admins to tweak value if someone starts bombing helltachments-filled posts
- Currently only removing limit would be setting it to something ridiculous like 99999, which seems a bit like bad UX, so I'd add a separate option to enable/disable limit. For example
Limit displayed attachment previews [x](default true)amount: [ 12](suboption)
either way it could be made into separate issues/mrs. Feel free to merge it in as is.
- Make it instance-configurable
Maybe an MRF Policy so incoming posts can be limited, while on local maxThumbnails is set to whatever.
This can be user configured, so the server/BE pipes the images raw into the client maxThumbnails at a time, on scroll or load more button.
Defaults whatever, don't care, let the admin set their default, users navigator.storage.persist() whatever they want.
E.g. smug 90+ image post incomes to kawen set to 4, BE has entire copy, but kawen loads 4 images at a time of the post as it scrolls or clicks load more, while smug just loads the 90+ and let's the client deal with the load.
Edited by NotZemichimentioned in commit 058238c3