Repeating schedules

Hi,
A simple version of this could be done in scheduler, but whether it gets added depends on how well it fits with the rest of the scheduler code and whether we view it as an essential part of scheduling or just another 'great to have' option (there are lots of them already :-)

I could visualise how it could be done using a simple repeating pattern eg set the usual 'publish on' date & time and specify a number of hours or days for the repeated publication. You would likewise set an 'unpublish on' date & time but the same 'repeat duration' would be used. The repeat value could be added into the scheduler table as a simple number. Then during the cron run which does the publication, if a repeating value was given then a new row would be inserted into the scheduler table (or the existsing row could be updated) calculating the new date from the date just used. Likewise on unpublication. The difficulty would be in allowing things like 'every 1st of the month' because this requires more information to be stored in the scheduler table to allow the next publishing date to be calculated.

An alternative would be to allow multiple rows in the scheduler table, which would be inserted at the node editting time as is done currently. This has the benefit that the 'until' date could be specified and then all the events would be added to the table at one time. There would probably have to be a few tweaks to the logic in the cron function but that should not be too difficult.

So it comes down to whether other users, and more specifically the maintainer Eric, think that this is a useful addition to scheduler. This functionality is common in other calenders and mail programs, so it may well be good to include it.

Jonathan

I could also use this. For example publishing specific nodes only on certain dates (Xmas, New Year, Valentine's day etc.).

The Date Repeat API also has a calculation function that will parse the RRULE and return an array of dates that match those rules.

If this feature request is accepted & finally implemented in this specific way, there should also be a way to allow users to set a start date and an end date (so that the array isn't endless).

...btw, feature requests go against the latest dev of the most recent branch.

I'd love this functionality, it's exactly what I'm looking for as I'd like to add an ubercart product to my drupal site that is only on sale at certain times of the day during the working week. Is it likely that this could happen?

I just realised that this is for Drupal 7... I use Drupal 6, not 7, but don't want to flood your issues table by making a new request for Drupal 6.

Hey Mark, don't be frustrated. New features are almost always filed against the latest branch (currently 7.x), but provided that a project's 6.x branch is still maintained these features have a chance of being back ported. If I were you though, I'd be looking to upgrade to D7 anyways ;)

That's good to know thanks :)

Hello Fellow Drupal Folks,

Please update me as to the 6.x and 7.x progress of this 'repeating event' feature of Scheduler.

I can imagine a database column defined as an enum with varied date spans,

repeat ENUM('none', 'daily', 'weekly', 'monthly', 'quarterly', 'yearly'),

Where would this appear in the scheduler php code and where would the ui element code lie?

I would be willing to help. Thank you.

Great feature request, keep me up to date :)

This is a very important feature to be added. I'll be tuned too!

i feel like this could probably be done cleverly with rules scheduler, but doing it in a general way with the repeat api would make more sense....

Any plans to add this feature ?

Hi,
I created a recurrence system based on the days of the week.
Basically, if recurrence is enabled (check box just at the bottom of schedule screenshot1.png), I display the days of the week (screenshot2.png).
Then cron will test between the date of publication and unpublishment, and verify if one is in a day checked.

NB: I had to remove the date of publication from NULL after it is exceeded, in this system we keep the dates of publication and unpublishment in all cases. Then in the cron I include in the entityquery the status (example if I want to publish, I only retrieve nodes with status TRUE etc ..)

Salla

Just a little regards into this patch :

1. +++ b/scheduler.module
   @@ -201,6 +204,40 @@ function scheduler_entity_base_field_info(EntityTypeInterface $entity_type) {
   +      ->setLabel(t('Recurrence'))
   

   You should user $this->t() instead t() usages. @see StringTranslationTrait if you haven't $this->t() already here.

2. +++ b/src/Plugin/Field/FieldWidget/SelectWithCheckboxesWidget.php
   @@ -0,0 +1,77 @@
   +
   

   Unused white break.

3. +++ b/src/Plugin/Field/FieldWidget/SelectWithCheckboxesWidget.php
   @@ -0,0 +1,77 @@
   +    if ($form_state->getValue('recurrence')['value'] == TRUE) {
   +      foreach ($form_state->getValue('days') as $day) {
   +        if ($day != FALSE) {
   +          $error = FALSE;
   +        }
   +      }
   +      if ($error == TRUE) {
   +        $form_state->setError($element, t('No day checked, or uncheck recurrence'));
   +      }
   +    }
   +    if (is_array($element['#value'])) {
   +      $values = array_values($element['#value']);
   +    }
   +    else {
   +      $values = [$element['#value']];
   +    }
   

   You can simply a lot the complexity of that.

4. +++ b/src/SchedulerManager.php
   @@ -76,131 +76,149 @@ class SchedulerManager {
        $dispatcher = \Drupal::service('event_dispatcher');
   +    $lock = \Drupal::lock();
   

   You shouldn't use that directly for better mockability you need to use injected services instead of \Drupal::

5. +++ b/src/SchedulerManager.php
   @@ -76,131 +76,149 @@ class SchedulerManager {
   +        $query = \Drupal::entityQuery('node')
   

   Similar problem use injection.

6. +++ b/src/SchedulerManager.php
   @@ -216,131 +234,156 @@ class SchedulerManager {
   +    $lock = \Drupal::lock();
   

   Injection.

7. +++ b/src/SchedulerManager.php
   @@ -216,131 +234,156 @@ class SchedulerManager {
   +        $query = \Drupal::entityQuery('node')
   

   Injection.

That would be better if we can purpose a Tests too. With lot changes we need to bu sure all is ok.

@sallakane you do switch issue to need review to play tests of module with your patch.

Hi @woprrr, thank you for your review.
I'm looking at this, and I'm trying to fix it all.

Thx.

Hi sallakane and woprrr,

Thanks for your input on this. The patch is big, 829 lines, so you definitely need to run our automated tests. When you upload a patch and set the issue status to 'needs review' the tests will be run automatically.

If we were to add the repeating functionality, however, I think it would need to be generic (see the discussion in #2, #3 and #10 above). Your work only covers days of the week and involves a lot of hard-coding. I don't think this is the direction we would go for Scheduler - we want be able to re-use a generic date-repeat rule somehow, rather than cater for each type of repeat via new long-hand code.

I don't want to put you off doing this coding work and having fun with enhancements for Scheduler, but I do want to warn you that with your current design it is unlikely to make it through and be committed. :-)

Jonathan

I agree with #19. What kind of approach you would be willing to accept?

I'm working on #1 comment's first suggestion.

• Recurring options will be extendable by plugins
• Will include basic options like "hourly", "daily", "weekly", "mohtly", "yearly", etc.
• Recurrance is applied on scheduler unpublish
• Will include some tests

Following a discussion on Slack, iMiksu is going to work on this as a sub-module of Scheduler, using plugins for the various types of repeat. It will be triggered on unpublishing, and the new publish and unpublish dates derived and set. We will start with a few simple repeating periods, but when proven new plugins could be added to do more complicated rules.

Thank you iMiksu, this sounds very promising.

Big thanks to @iMiksu for the work done so far. We now have an operational version of the new scheduler_repeat submodule in this GitHub branch https://github.com/jonathan1055/scheduler/tree/1345666-repeat and the pull request is https://github.com/jonathan1055/scheduler/pull/8

Here is a patch generated from the PR to see how it runs on drupal.org. Note that this patch is a consolidated one from all the commits, created using scheduler/pull/8.diff with the .diff extension on the PR url. This is because some of the new files are renamed during the commit history, so the full set of individual commits in a patch generated using scheduler/pull/8.patch cannot be applied.

I have added functional tests to check the creation anf editing of nodes with repeating schedules and processing via cron. There is still some work to do, and I will be listing the known remaining tasks soon, but if anyone would like to test this you can use the above GitHub branch or the attached patch. There are still many coding standards messages to fix, but the two new functional tests should run OK.

Ignore the Issue Fork I created for this issue - the work will continue on the GitHub branch with regular posting of patches back to this issue.

Here is an updated patch with 3 more commits from 9 November, to fix all the coding standards.

Lots of good work was done on this, and we could still add it as a Scheduler sub-module. New features will now go into the 2.x branch