Feat:Added field to show automatic scheduling status

[gpuligundla]

Rationale

Fix #816

Changes

• Added enabled field to schedulelight schema & retrieved its value from Postgres.
• Added a pause icon to show it in the front end.

Screenshot:

[benoit74]

@gpuligundla do you confirm this is ready for review?

[benoit74]

NOTA: I updated your first comment to use the "Fix #xxx" syntax, so that the issue will automatically be closed when the PR is merged

[gpuligundla]

@gpuligundla do you confirm this is ready for review?

yes

[benoit74]

LGTM, but please do not merge main into your branch to retrieve changes, instead rebase your branch on top of latest main changes (typically with git rebase main when on your branch). This is a highly debatable choice of course, but it is our convention ^^

Thank you for this very good first PR anyway.

[gpuligundla]

LGTM, but please do not merge main into your branch to retrieve changes, instead rebase your branch on top of latest main changes (typically with git rebase main when on your branch). This is a highly debatable choice of course, but it is our convention ^^

Thank you for this very good first PR anyway.

Done

[benoit74]

Thank you! I'm just asking @rgaudin for a final pass since he has more expertise than me on this kind of UI stuff and previous discussions that occurred on the Zimfarm.

[benoit74]

Just to clarify a bit the PR workflow (detailed in https://github.com/openzim/overview/wiki/openZIM-workflow), especially regarding changes on main branch while you are developing for all openzim/kiwix/offspot repos:

• do not forgot to ask for a review once your PR is ready (otherwise it is difficult for us to know if it is really ready or still a WIP); you might add us as reviewers directly (for zimfarm, either rgaudin or myself is OK) or simply add a comment asking for help (when working on other repos where
• once the PR has been submitted a first time to review, do not mind any changes that will happen on main branch anymore (they will be rare anyway) ; in general, do not rebase or merge, since it will make the review work much more tedious ; before submitting your first review you might do the rebase (especially if it took you weeks to finalize the PR)
• fix all requested changes on your branch as-is (based on a potential old commit of main branch) ; ask again for review once fixes have been done or answers provided (not all our comments require a change, sometimes we might be wrong as well ^^)
• once PR is ready, the reviewer (usually, especially when this is obvious and also because he usually has more knowledge of what happened on main) or the author (sometimes, when lots of conflict have to be dealt with) will take care of rebasing the PR branch on latest commit of main branch

But again, don't be afraid of all this, this is just small conventions to facilitate everyone asynchronous work, avoid misunderstandings and your help is still valuable and welcomed!

[rgaudin]

LGTM ; thank you for this great first contribution 👍

[gpuligundla]

Just to clarify a bit the PR workflow (detailed in https://github.com/openzim/overview/wiki/openZIM-workflow), especially regarding changes on main branch while you are developing for all openzim/kiwix/offspot repos:

• do not forgot to ask for a review once your PR is ready (otherwise it is difficult for us to know if it is really ready or still a WIP); you might add us as reviewers directly (for zimfarm, either rgaudin or myself is OK) or simply add a comment asking for help (when working on other repos where
• once the PR has been submitted a first time to review, do not mind any changes that will happen on main branch anymore (they will be rare anyway) ; in general, do not rebase or merge, since it will make the review work much more tedious ; before submitting your first review you might do the rebase (especially if it took you weeks to finalize the PR)
• fix all requested changes on your branch as-is (based on a potential old commit of main branch) ; ask again for review once fixes have been done or answers provided (not all our comments require a change, sometimes we might be wrong as well ^^)
• once PR is ready, the reviewer (usually, especially when this is obvious and also because he usually has more knowledge of what happened on main) or the author (sometimes, when lots of conflict have to be dealt with) will take care of rebasing the PR branch on latest commit of main branch

But again, don't be afraid of all this, this is just small conventions to facilitate everyone asynchronous work, avoid misunderstandings and your help is still valuable and welcomed!

sure, I'll follow it from next time. Thanks <3