starred/wastebin-matze

Fork 0

mirror of https://github.com/matze/wastebin.git synced 2026-04-25 16:45:59 +03:00

[GH-ISSUE #54] Feature Request [Force Expiration] #42

New issue

Closed

opened 2026-02-27 10:15:26 +03:00 by kerem · 7 comments

kerem commented

2026-02-27 10:15:26 +03:00

Owner

Originally created by @jk-nia on GitHub (May 31, 2024).
Original GitHub issue: https://github.com/matze/wastebin/issues/54

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

Originally created by @jk-nia on GitHub (May 31, 2024). Original GitHub issue: https://github.com/matze/wastebin/issues/54 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

kerem closed this issue

2026-02-27 10:15:26 +03:00

kerem commented

2026-02-27 10:15:27 +03:00

Author

Owner

@denissteinhorst commented on GitHub (May 31, 2024):

+1 on that one!

@denissteinhorst commented on GitHub (May 31, 2024): +1 on that one!

kerem commented

2026-02-27 10:15:27 +03:00

Author

Owner

@matze commented on GitHub (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.

@matze commented on GitHub (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.

kerem commented

2026-02-27 10:15:27 +03:00

Author

Owner

@denissteinhorst commented on GitHub (Jun 3, 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.

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! 🥇

@denissteinhorst commented on GitHub (Jun 3, 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. 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: ```rust 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! 🥇

kerem commented

2026-02-27 10:15:27 +03:00

Author

Owner

@HeapUnderfl0w commented on GitHub (Jul 6, 2024):

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")

@HeapUnderfl0w commented on GitHub (Jul 6, 2024): > 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"`)

kerem commented

2026-02-27 10:15:27 +03:00

Author

Owner

@kamaradski commented on GitHub (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.

@kamaradski commented on GitHub (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.

kerem commented

2026-02-27 10:15:27 +03:00

Author

Owner

@cgzones commented on GitHub (Sep 22, 2024):

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

@cgzones commented on GitHub (Sep 22, 2024): When setting the environment variable `WASTEBIN_MAX_PASTE_EXPIRATION` to a limited value the `never expires` option is not available.

kerem commented

2026-02-27 10:15:27 +03:00

Author

Owner

@matze commented on GitHub (Feb 25, 2025):

Okay guys, despite what was written here and in #65, I drafted something a bit more radical in this wip branch because I'm breaking a few things already, so why not here as well, right? Essentially, this replaces the current WASTEBIN_MAX_PASTE_EXPIRATION by a fully customizable list of expiration values. My only concern is that anything longer than a week will be rendered imprecisely (i.e. how many seconds are in a month and year …).

@matze commented on GitHub (Feb 25, 2025): Okay guys, despite what was written here and in #65, I drafted something a bit more radical in [this wip branch](https://github.com/matze/wastebin/compare/master...wip) because I'm breaking a few things already, so why not here as well, right? Essentially, this replaces the current `WASTEBIN_MAX_PASTE_EXPIRATION` by a fully customizable list of expiration values. My only concern is that anything longer than a week will be rendered imprecisely (i.e. how many seconds are in a month and year …).

kerem referenced this issue

2026-02-27 10:15:52 +03:00

[PR #42] [MERGED] Autofocus on main input elements #128