This is an internal modification of how the application operates, as part of issues #6 and #14.
Currently, the list of services is stored as a single data block contain both (1) information about each organisation (i.e. name, address, phone number, etc) and (2) data concerning only the filtration of the list (i.e. location, legal issue, gender, etc). These two serve completely different purposes and as such must be isolated. The former is static information rendered in the final screen, whilst the latter concerns internal logic responsible for determining what is rendered in the final screen - i.e. the filtered list.
What did you expect to happen?
The filtered list should not store any information pertaining the organisation. Instead, org name should be used as a unique identifier inside the filtered list which is then used to fetch the required information from an Organisation List. In other words, it should function akin to a relational database. This separation of concerns, should enable us to pull a list of organisations from an Excel spreadsheet, hence simplifying the process of mutating existing services (i.e. adding, removing, or modifying).
The other concept that will be introduced is Filters - discussed separately in TBC
We need to implement the following:
Organisation List - containing: name, address, url, logo, phone number, and email (potentially pulled from a spreadsheet)
Original Service List - an array where each item is a dictionary consisting of org name and corresponding filters
Filtered Service List - a copy of the Original Service List, with items filtered out during the interview process.
Describe the issue
This is an internal modification of how the application operates, as part of issues #6 and #14.
Currently, the list of services is stored as a single data block contain both (1) information about each organisation (i.e. name, address, phone number, etc) and (2) data concerning only the filtration of the list (i.e. location, legal issue, gender, etc). These two serve completely different purposes and as such must be isolated. The former is static information rendered in the final screen, whilst the latter concerns internal logic responsible for determining what is rendered in the final screen - i.e. the filtered list.
What did you expect to happen?
The filtered list should not store any information pertaining the organisation. Instead, org name should be used as a unique identifier inside the filtered list which is then used to fetch the required information from an Organisation List. In other words, it should function akin to a relational database. This separation of concerns, should enable us to pull a list of organisations from an Excel spreadsheet, hence simplifying the process of mutating existing services (i.e. adding, removing, or modifying).
The other concept that will be introduced is Filters - discussed separately in TBC
We need to implement the following: