Auto-close scheduling by # of days instead of # of hours

(Dave McClure) #1

When auto-closing topics, I almost always want to set it for some number of days… We’ve adopted the practice established here on meta where bug topics are auto-closed 1-3 days after they are fixed (I usually leave a few more days for the weekend if its toward the end of the week).

However, I often find myself forgetting to multiply by 24.

Leaving it in hours is more flexible, but is it that useful? Anyone else here using auto-close to close topics in < 24 hours?

I’d like to see an integer treated as a number of days… folks with specific timing needs can still enter a full timestamp.

Another enhancement might be to have the number default to the last number used.

This is just a niggle, not a burning issue in the race to v1…

(lid) #2

If it is a UX question.

Then the answer will be add a time selection widget, I am not sure who in is right mind know what is the current timestamp( if we are talking epoch)

If you still prefer just to input using a keyboard then a format of sort can be introduced.
#1d = 24 hr
#1d6h = 30hr
#5h = 5hr

a simple parser.

(Dave McClure) #3

Sure… I think a number of the admin facing features get a little less love because there are that many fewer users that will deal with them.

I don’t have any objections to making this fancier, but I also wouldn’t mind a quick and dirty fix if others who user this feature simply agree that closing by days is a much more frequent use case than closing by hours.

Not sure whether there’s unanimity there or not without throwing this out there though…

(Mittineague) #4

I can think of where I would want to autoclose a new topic in a matter of minutes, and close topics after a long period of inactivity.

Perhaps it’s too late for me, but I think I understand it. The way I see it this setting is tied in with cron-like processes though I don’t how often any might be happening.

Taking minutes as the finest point, this allows real possibilities.
Using hours, not so much, but still 24 per day.

But I guess most people don’t think of many days in terms of minutes or even hours.
So if it is used where a day here or there isn’t important I think it would make a better UI experience for many.

(Manthan Mallikarjun) #5

@Lid shows a good point.

It should be something like 1d3h4m.

(cpradio) #6

I also like @Lid’s approach and to ensure it doesn’t break existing, if there isn’t any time indicator (d/h/m) then it should assume it is hours (so it keeps the existing functionality).

(Sam Saffron) #7

I would be happy with a PR that adds support for d and h postfixes. ‘m’ is tricky cause it can be confused with minutes.

(lid) #8

This is what moment.js uses

I have created a small parser for this format, it uses moment.js which is already used on discourse(no new dependency)
and the parser will support any of the format that moment.js support as shown above.

you can easily decide on the output unit using moment.js

(Sam Saffron) #9

For now I am happy with a PR that add “w”, “d” and “h” suffix support, it must also update the help text. not that comfortable adding anything more complex than that for now.

(lid) #10

If anybody wants to play with this experiment:
what time units allowed is configurable in the javascript end, and it is very flexible as to the input

(Stefan Brand) #11

Is there anything new on this? I think it would suffice, if the input field would only be able to do multiplications:

(Mittineague) #12

You’re not getting the datepicker?

(Stefan Brand) #13

No, no datepicker here… :confused:

(Joshua Rosenfeld) #14

Hmm, what version of Discourse are you running?

(Stefan Brand) #15

v1.7.0.beta7 +5 (20 chars)

(Joshua Rosenfeld) #16

Well, I just tried it over at Stonehearth (1.8.0.beta1) and also am not seeing the date picker. I wonder if there’s been a regression…

(Régis Hanol) #17

I don’t remember there ever was a date picker for the auto-close time.

(Stefan Brand) #18

There is one for the “pin topic”-dialogue. Can the same datepicker be implemented for the auto-close-dialogue?

(Jeff Atwood) #19

No because the input accepts many forms of data not just dates.

(Stefan Brand) #20

Ok, what about multiplication of the number of hours then?