Notify_credentials timing question

Development
1

notify_credentials has 2 ways of running.

  1. The manual, one-off method which uses --args_from_database to specify what should be sent.
  2. The automated method, which runs on a regular schedule, to catch anything which fell through the cracks.

The automated method does a certain amount of time/date math, which is, I assume, why it has some hardcoded logic; it’s not at all simple to have a cron-run management command running on a regular cadence that can do the same time logic.

        if options['auto']:
            options['end_date'] = datetime.now().replace(minute=0, second=0, microsecond=0)
            options['start_date'] = options['end_date'] - timedelta(hours=4)

However, it is not ideal that the actual time window of 4 hours is hardcoded directly into edx-platform.

I’d like to propose changing this in a way that’s not a breaking change:

  • create an overridable NOTIFY_CREDENTIALS_FREQUENCY that defaults to 1440 seconds (4 hours).
  • pulling that frequency into the quoted code

I propose doing it in seconds because that allows maximum flexibility.

Because this is not a breaking change it doesn’t really need review, but it’s a little weird that it was written this way in the first place, so I just wanted other people’s opinions, in case I am missing some subtlety.

If no one has any opinions I’m just going to make the change. :smiling_face:

1 Like
2

Just noting that you probably meant “… not a breaking change.”

3

:person_facepalming: thanks, fixed.

4

Change makes sense to me.

1 Like
5

This change makes sense to me to, but I feel we should get rid of this:

A model to store command line args that Jenkins can manage perfectly well. I suppose this was a workaround for when teams didn’t have an easy way to edit Jenkins jobs and one specific company :slight_smile: