Open voipmeister opened 2 months ago
@voipmeister This is actually already implemented, sorta. Just not exposed via oputil
... yet.
You can currently set any of/combination of the following in your area's config:
maxMessages
maxAgeDays
Setting e.g. maxAgeDays
to 0 disables any max.
The system will keep the areas up to date with these params.
I will keep this ticket open for oputil mb purge [--max-age-days, --max-messages]
to run with current config "now", or override with the params. Does that work for you?
EDIT: We also need some documentation updates on these fields in the message area docs, would love a PR :D
I will keep this ticket open for oputil mb purge [--max-age-days, --max-messages] to run with current config "now", or override with the params. Does that work for you?
Yes, that would work 👍
EDIT: We also need some documentation updates on these fields in the message area docs, would love a PR :D
Let me see what I can do about that 🙂
PR https://github.com/NuSkooler/enigma-bbs/issues/552 created :)
Is your feature request related to a problem? Please describe. Currently, we need to manipulate the message base using
sqlite3
.Describe the solution you'd like It would be great if the
./oputil.js mb
command could be used to do the following:The first two options could be achieved by adding parameters in the area properties in the
config.hjson
file:In this example,
max_age: 365
would cause messages older than 365 days in the areatqw_afs
to be purged. Question is, would the date of import be considered or the send date of the message? (haven't looked in the database yet, I'd vote for the latter if it would be a choice).The parameter
max_count: 2000
would obviously cause a purge of messages older than the last 2000 messages. Again, not sure about which date to consider.A separate
reset
option would be useful to reset (empty) an area if so desired. Maybe a wildcard could be implemented, although that might be a risky option. Likewise, maybe a reset-conference option could be implemented, not sure how often you'd use that though.The first two would be very nice to have IMHO, because we could have a maintenance
oputil
job run every day/week to maintain the message base.Describe alternatives you've considered Hacking away with
sqlite3
, which is kinda... error prone? ;)Additional context Nothing further, I think :)