[#442] setting a Service Provider to not work at certain day

Migrated from Redmine #442 | Author: Arian Hojat
Status: New | Priority: Low, I can wait | Created: 2019-11-12


Just curious , i noticed if i don’t set a workday hours for a new Service Provider, it inherits from the company hours.
For example if i set Monday/Tues/Wednesday/Thursday with data like so:

$workday_data = array(
  'start_time'=> $value['start'], //dynamic value from Excel file
  'end_time'=>   $value['end'],   //dynamic value from Excel file
  'is_day_off'=> 0,
  'index'=> $day_index_to_use, //index is 1-7 for Monday - Sunday (check to see if this is dynamic depending on the our set 'startday of the week' and adjust accordingly
  'name'=> ucfirst($day), //"Monday", "Tuesday", etc, not sure why this is needed if index above controls this. Maybe for explicitness?
  'unit_group_id'=> $sb_provider_id, //dynamic value from just inserting the Service Provider above this code
  'event_id'=> 1, //this is the service id
);
$output = $client->setWorkDayInfo($workday_data);

then Friday will still have the company hours inherited for this Service Provider… What do I need to do to clear out Friday for this 1 Service Provider?
This is my guess, if you can confirm, is to remove the start/end hours and just have is_day_off set to 1:

$workday_data = array(
  'is_day_off'=> 1, //maybe set to 1 to say this Service Provider doesn't work on this day at all
  'index'=> $day_index_to_use, //index is 1-7 for Monday - Sunday (check to see if this is dynamic depending on the our set 'startday of the week' and adjust accordingly
  'name'=> ucfirst($day), //"Monday", "Tuesday", etc, not sure why this is needed if index above controls this. Maybe for explicitness?
  'unit_group_id'=> $sb_provider_id, //dynamic value from just inserting the Service Provider above this code
  'event_id'=> 1, //this is the service id
);
$output = $client->setWorkDayInfo($workday_data);

Side question#2:
if you supply the ‘index’ (where 1=Monday, 2=Tuesday, etc), why do you also need to supply the ‘name’ like ‘Monday’? It seems like the former or the latter won’t be used by you guys (as they can be conflicting data)?

Thanks,
Arian

Redmine Admin wrote:

Hi,

This method should override Friday and any other company week day setting. Please check the following :

  1. company or provider does not have schedule settings for some date which is Friday
  2. provider cannot have working period longer than company working period for this weekday. (It is still possible to make special schedule for some date which is longer than company week day schedule)

Is day off = 1 will close weekday/date for bookings

#2 was needed to support legacy API code. It is of course not needed and will be fixed. Please provide day name for now.

Arian Hojat wrote:

Redmine Admin wrote:

Hi,

This method should override Friday and any other company week day setting. Please check the following :

  1. company or provider does not have schedule settings for some date which is Friday
  2. provider cannot have working period longer than company working period for this weekday. (It is still possible to make special schedule for some date which is longer than company week day schedule)

Is day off = 1 will close weekday/date for bookings

#2 was needed to support legacy API code. It is of course not needed and will be fixed. Please provide day name for now.

K great, i’ll try that.
For the other question I had about the ‘index’/‘name’:
“Side question#2:
if you supply the ‘index’ (where 1=Monday, 2=Tuesday, etc), why do you also need to supply the ‘name’ like ‘Monday’? It seems like the former or the latter won’t be used by you guys (as they can be conflicting data)?”

Redmine Admin wrote:

hi,

Side question#2: you are right about this :slight_smile:

Arian Hojat wrote:

Redmine Admin wrote:

hi,

Side question#2: you are right about this :slight_smile:

hehe, so what happens? Can i just use one vs the other? or have to supply both and both have to be correct or who knows what will happen? The API doc for setWorkDayInfo doesn’t really say.