You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be useful for us to not have "never expire" as default selection for new pasts
Usecase:
I have deployed wastebin internally in a small company for people to share information among each other that does not fit inside a chat, or do not belong in a chat, where syntax need to be preserved, or in case one doesnt want to clutter documentation with raw text.
So i see people using it to:
share (semi)sensitive data that should expire within a day or week
share code snippets that also lose relevance very quickly
large raw log-files for troubleshooting that can contain also sensitive data sometimes and should expire until the troubleshooting is completed
store supporting data for documentation and reports probably need to remain available for 1 year and upwards
How do people use it:
paste information
press the go button
copy the link
call it a day
And thus you can see they forget to select an appropriate expiration resulting in:
server cluttering with data noone needs (creating digital-waste)
potential sensitive data being stored longer than needed (you know what endusers are like)
Potential solution 1:
allow the sysadmin to set which is the default pre-selected expiration
Con: this might lead to users pre-maturly losing their content
Pro: Previous con leads to user-education on how to correctly use the tool
Pro: this retains the quick flow of creating a paste, where the user can opt not to click on a expiration option
Potential solution 2:
not set a preselected expiration at all, and not accept sumbission of the paste until the use has done so
Con: this breaks the quick create workflow by introducing 1 additional click
Con: a bit of extra effort in coding the feature since the UX flow need to be changed including writing proper error messages
Pro: user-education without pissing users off for accidentally prematurly losing their content (potential solution 1), or pissing the sysadmins off by cluttering the system with items that exist longer then required.
Personally i like option 2 the most even if it's a bit more effort, however i cannot judge the usecases of other people.
The text was updated successfully, but these errors were encountered:
If WASTEBIN_MAX_PASTE_EXPIRATION is set, the default expiry will be 600 seconds, it is too short for most times, if not set, it will default to never, and it is unrealistic, maybe made a env that can change this default setting?
It would be useful for us to not have "never expire" as default selection for new pasts
Usecase:
I have deployed wastebin internally in a small company for people to share information among each other that does not fit inside a chat, or do not belong in a chat, where syntax need to be preserved, or in case one doesnt want to clutter documentation with raw text.
So i see people using it to:
How do people use it:
And thus you can see they forget to select an appropriate expiration resulting in:
Potential solution 1:
allow the sysadmin to set which is the default pre-selected expiration
Con: this might lead to users pre-maturly losing their content
Pro: Previous con leads to user-education on how to correctly use the tool
Pro: this retains the quick flow of creating a paste, where the user can opt not to click on a expiration option
Potential solution 2:
not set a preselected expiration at all, and not accept sumbission of the paste until the use has done so
Con: this breaks the quick create workflow by introducing 1 additional click
Con: a bit of extra effort in coding the feature since the UX flow need to be changed including writing proper error messages
Pro: user-education without pissing users off for accidentally prematurly losing their content (potential solution 1), or pissing the sysadmins off by cluttering the system with items that exist longer then required.
Personally i like option 2 the most even if it's a bit more effort, however i cannot judge the usecases of other people.
The text was updated successfully, but these errors were encountered: