Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request [Force Expiration] #54

Open
jk-nia opened this issue May 31, 2024 · 6 comments
Open

Feature Request [Force Expiration] #54

jk-nia opened this issue May 31, 2024 · 6 comments

Comments

@jk-nia
Copy link

jk-nia commented May 31, 2024

Hey folks,

Is it possible to add a flag that removes the never expires option so one either has to pick an expiration time (maybe max also controllable) or burn after read?

Many thanks in advance

@denissteinhorst
Copy link

+1 on that one!

@matze
Copy link
Owner

matze commented Jun 2, 2024

Sounds reasonable, will definitely look into that ASAP. Question is if that should be yet another environment variable or if I should bite into the sour apple and allow configuration via a file.

@denissteinhorst
Copy link

Sounds reasonable, will definitely look into that ASAP. Question is if that should be yet another environment variable or if I should bite into the sour apple and allow configuration via a file.

Well I mean, having the freedom to completely decide what expiration-options one would like to have, would indeed be a beautiful addition. If you take the Challenge, I imagine to see the various options like:

enum ExpirationValue {
    Bool(bool),
    Int(u32),
}

struct ExpirationConfig {
    after_read: bool,
    never: bool,
    minutes: ExpirationValue,
    days: ExpirationValue,
    weeks: ExpirationValue,
    years: ExpirationValue,
}

If ExpirationValue is set to false; the Option is just "not present" in the UI. If set to an integer it's "that value".
maybe you could even expose those config somewhere so one could change em on the fly?

aaanyway: What ever path you might choose, thanks for your quick reply on that topic mate! 🥇

@HeapUnderfl0w
Copy link
Contributor

Question is if that should be yet another environment variable or if I should bite into the sour apple and allow configuration via a file.

To bikeshed a tiny bit here: i usually am fine with just having stuff like this as an environment, as most service managers (systemd, docker, etc) allow loading .env files.

On the other hand a core issue is that env vars do not lend themselves well to multiple values and some custom format has to be invented and documented (even if its just "valA,valB")

@kamaradski
Copy link

kamaradski commented Jul 26, 2024

Before i open a new feature request for something that actually lured me here, i like to confirm the scope of the work done on this feature request as we might overlap.

I was looking for a way to a) freely config the expiration for each individual item, like @denissteinhorst mentioned above, or b) a way to statically configure the expirations a bit more to my liking (example: add 1 month, and maybe 2 weeks).

in case something like this is already part of the works related to this request, i can spare the extra feature request, otherwise i would be happy to open a new one specifically for this topic.

On topic and for what it's worth:
I do not have a usecase to disable the "never expire" option, but i do like the idea of being able to do so. Even more useful for me would be to NOT have "never expire" as default option. People tend to not change it and clutter the server with useless pastes.

@cgzones
Copy link
Contributor

cgzones commented Sep 22, 2024

When setting the environment variable WASTEBIN_MAX_PASTE_EXPIRATION to a limited value the never expires option is not available.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants