You must log in or register to comment.
I have scheduled posts for lemmy in the past using lemmy-schedule, so I won’t say no to this feature, but I don’t think it needs to be a high priority. It is most useful for community moderators that do things like schedule weekly posts (what I have used it for) or create threads for specific events (sporting event, community movie night, etc.). This is something that wouldn’t be too hard to live as a third-party tool interacting via an api (if a piefed api exists…I haven’t checked).
I’m considering starting to work on this. But I need some advice: Where do I put the task to periodically ckeck the database and send out the posts? Do I introduce yet another cronjob? Or lump everything together with the maintenance task, make it run every 5minutes and add some logic to skip maintenance unless once at 2am? Is there another clever way to trigger a periodic task?
That’s great :)
The daily maintenance task takes a long time to run, too long to run often.
Also that function is already doing too many things - we’ll need a new function in cli.py with a new cron job.
The DB model is worth getting right because the ramifications will be everywhere.
My first thought is to add a ‘status’ field (bool) onto the Post model and set that when moving a post from draft to published. That way we won’t have two models to keep in sync (“Post” and “ScheduledPost”) and no extra dependent models/tables (Poll, post_tag equivalents for scheduled posts). But then every time we run a query on Posts we’d need to filter out the unpublished posts. We already do this to filter out deleted posts which leads me to:
Another possibility would be to use the value of ‘status’ (int, not bool) to represent scheduled, published and deleted states. This would mean we don’t have an extra filter in play to hide deleted posts - 99% of the time we’ll only want published Posts.
How’s that sound?
Thanks. I’ll just make it a separate cronjob, then.
I was hoping the object-relational mapper can do some magic for us. Like make ScheduledPost inherit from the class Post and just add a timestamp. But I haven’t looked at that yet. Your other two ideas sound fine as well. I guess I’ll just start, and decide once I’m buried in the code. That way I’ll see which one feels clean to type out… In case of doubt you can intervene, I guess this will be a small part of the changes anyway. I also have to come up with some UI etc.
I am unsure if
flask db migrateis smart enough to generate tables from inherited models but it’ll be interesting to find out.
