Closed eric-jahn closed 9 years ago
Moved in v0.0.10 with 5a893dc
I am not positive what data elements hasSeasonalSchedule refers to. But, I imagine it to be site opens on this day, closes on this day…if this is the case, I disagree with removing this from the site. Some locations are only open during a certain time period, while the program may still run at other locations.
my additional questions here. I have locations that are only open for a particular time as well as agencies only open during a particular season. SFSP sites: some locations are open June-Aug, some locations open only in Aug. Example of an agency only open during a particular season – Christmas Giving agency, doors and phones are only open from Thanksgiving through the day after Christmas. For these particular instances, maintaining sharing this type of data only at the SiteService level doesn’t give the proper picture. Or perhaps, I am misunderstanding this?
Does it make sense to have SeasonalSchedule at both the agency and the service site level? Operationally, the flag at the agency level would make the entire organizational record (agency, sites, services, service sites) unavailable for the date range where a flag at the service site level would only apply to that particular service at the site. I don't know how software systems are actually structured though, so this might not work...
It's at the SiteService level as of v0.0.11, but we could also have it at Site. I'm not sure how a building or a location alone can have a schedule. I guess it would mean that the doors are physically open? But without the context of a service being run at that site, it seems like meaningless information to me.
Remove hasSeasonalSchedule from site, but move to SiteService, since a schedule is for a service at a location, not for a site, which is just a place/location.