Short term service feature.

[Mike-Heneghan]

Some users who add services to ALISS have given feedback that their services have predetermined end dates. This can be due to the availability of funding, staff or seasonal changes. For these users, they might find it challenging to go back and remove the service after it has been added.

Additionally, some services may come to an end but will start up again in the future and users don't want to have to delete and then later re-upload information regarding the service.

A potential solution to these related challenges could be to add a new column in the Service model which would store the end date. After this date, the services would be removed from the ElasticSearch index and would therefore not be searchable. Although preferably the data wouldn't be deleted.

If a user wants to reinstate or permanently add their service they could mark it as indefinite.

Need to consider how this can be implemented without adding unnecessary complexity.

Need to consider:

• In what form will the new data be stored.
• How will users change data.
• How will the system remove these services from search but preserve their data.
• How short term is a short term service and should this be enforced by ALISS?
• Will users have a tendency to reinstate but not update their service?

[Mike-Heneghan]

To implement one way could be:

• [x] Add a start date and end date to the Service model which would default to None and would be a DateTimeField.
• [x] Add a filter along the lines of filter_by_last_edited.
• [x] Apply the filter to the filter_queryset method of search.
• [x] Add new start date and end date fields to the Service form.
• [ ] Display results which have a start and end of None but make it clear if a service has not 'started' yet i.e. start date is in the future.

[Mike-Heneghan]

The initial plan was to not add the end date to the elastic search index although this complicated matters. The current methods of filtering and ordering could be impacted and it might be easier to remain consistent with the current approach.

[Mike-Heneghan]

After issues filtering with Elasticsearch instead added the exclusion as a filter of the Service objects in the search View.

[Mike-Heneghan]

• [x] Add start_date and end_date to the index.
• [x] Add a way to filter by field doesn't exist ES.
• [x] Add a way to have an or for end_date = None and end_date <= currentDate.
• [x] Test the filter.
• [x] Add the filter to the SearchView.
• [x] Update the interface of the datepicker to allow users to add Start and end dates.

[Mike-Heneghan]

An issue with standard form validation expecting the date to be inputted in American format i.e. month before day. Need to set the DateTime field input format to allow UK date format to be validated.

[Mike-Heneghan]

Fixed the saving and validation of dates.

Need to improve the form to hide the short term service content behind a question.

[Mike-Heneghan]

Adding a checkbox for short term service which then renders the inputs.

[Mike-Heneghan]

If a service has start date and end date of None.

• Submitting the from with the checkbox unchecked submits None for both fields.

Tooltip to explain feature.

When the checkbox is selected

• If the service has no associated start or end date it defaults to today's date.
• If the service has a date saved it is added to the pickadate input.

Form validation

• If there is a start and end date, the start must be at least 3 days beforwe the end.

Datepicker expans on click of input.

[Mike-Heneghan]

May need to split the start and end dates as is the start date is left blank it will default to the current date.

[Mike-Heneghan]

Added further test coverage to ensure the form can be submitted with a start and end date on creation and update of a service. Also tested that validation stops users from adding services with an end which is less than three days after the start date.

[Mike-Heneghan]

Still to complete:

• [ ] Add start_date and end_date information to services as they appear in results and on the detail page.
• [ ] Ensure it is clear for service editors that if the current date has passed a service's end_date it has expired and will not be shown to users.
• [ ] Abstract added JS and styling to the src/js/scripts and src/scss files respectively.
• [ ] Review the edge cases for the Service Availability section of the service create and update form i.e. if an end_date is supplied without a start_date when the form is subsequently submitted the blank start_date input field would default to the current date.
• [ ] Review the usability of the short term service section of service form including tooltip content.
• [ ] Consider potential filters for search results such as 'Only services which are available now' or 'Upcoming services' and whether they would be useful for users.
• [ ] Investigate impacts of short term services on content reporting i.e. generate_user_report.js and generate_location-report.js files to add short term service-based information reflecting the number of 'upcoming', 'active' and 'expired' services based on the start_date and end_date fields.
• [ ] When required ensure the elasticsearch index is updated to add start_date and end_date fields.