In this release of the App, we have added a new welcome page and made all views work for each item type. In addition to the new additions, we have fixed a small bug and made several minor tweaks.
- We have updated the tables and filtering controls, they are now specific to the relevant item type.
- We have added a new welcome page which replaces the existing sign-in page. The welcome page provides an overview of our project.
- We have removed the `resource type` view for item types where it doesn’t make any sense.
- We have tweaked the design of the resource summary blocks.
- We have removed unnecessary menu items for `simple-expense` and `simple-item` item types.
- We have changed the resource summary blocks; we have customised them for each item type.
- We have updated our roadmap.
- Removed excess `p` tag on the dashboard.
For this point release, we spent some time fixing and tweaking issues related to adding new item types.
- We have renamed the existing Interfaces, more straightforward names.
- We have added additional Interfaces interfaces for the summary models.
- We have refactored several model classes to again, simplify the naming.
- We have corrected multiple summary config files, unnecessary structure.
- We have unified the parameters for related item methods.
In this release of the API, we have added general support for filtering; when we say filtering, we mean limiting the results by range. There are now four operations available to collections, pagination, ordering, filtering on a range and filtering on specific values.
We will add range filtering to the remaining non-item routes over time; currently, it would not be of any real value.
- We have added range filtering to the `items` collection; initially, we have added support for filtering for the `effective_date` of `allocated expense` items.
- We have added range filtering to the resource type `items` collection; as above, we have added `effective_date` filtering.
- We have added support for range filtering to the `items` and `resource type item` summary routes.
- We have added an X-Filter header to show the valid filters applied to a collection.
- We have added a link to Costs to Expect blog; the blog is a central repository for all product updates and somewhere to talk about our products.
- We have added a `FilterParameters` class to fetch any filter parameters from the URI and validate the format and values.
- We have refreshed the landing page, we have added updated text for each of the products within the service.
- We have tweaked the stying for the landing page.
- We have renamed the data methods in the `Option` subclasses, the conditional prefix is confusing.
- We have added an `interface` for the item model classes.
- We have added an `interface` for the resource type item model classes.
- We have updated the `Option/Get` class, the `sort`, `search` and `filter` parameters will only display if there are viable parameters.
- We have removed the layout file, not used as there is only one view file for the API.
We have fixed two small bugs on the Costs to Expect API.
- Select the correct year when validating the min and max year for year validation.
- The logo on the welcome page will redirect you to the API, not the app dashboard.
We have fixed two small bugs on the Costs to Expect Website.
- Search the name field rather than the description field.
- Selecting a subcategory will now jump you to the expenses table.
In the newest release of the Costs to Expect API, we add a new `item` type, “Simple items”. The intention is the new `item` type will be used to manage lists and collections.
We found the process of adding a new `type` to be more complicated than it should; we have refactored the item code to organise the different item classes more sensibly.
The full changelog is below:
- We have added a new item type, `simple item`. We intend that the ‘simple item’ type is useful for managing collections. The API will now allow you to list, add, edit and delete them.
- We have updated the summary routes to calculate the correct summaries for the `simple item` type.
- We have removed the effective date from simple expenses. Our intention is simple expenses are bucket based, not time-based.
- We have updated the copyright for the API.
- We have moved additional methods in the base `item` classes to reduce configuration code duplication.
- We have simplified the validation classes for `item` create and update requests.
- We have renamed some of the methods on the `item` class to make the intent of the method names more clear.
- We have renamed the item interface class.
- We have moved the `resource type item` classes; they are below the`item` class; there is no need for them to be so low in the structure.
- We have moved the factory class for `resource type` items.
- We have moved the validation classes.
- We have moved the `item` model classes; we have grouped all classes of the same type.
We have released a minor update to the Costs to Expect App. We are adding new `item types` to the Costs to Expect API and needed to push out a small release to ensure the App correctly handles data it doesn’t understand.
The full changelog is below:
- We have added a helper method to the `Request\Response\Result` class, `hasResponse()`.
- We have updated the `Request\Api` class to ensure a response exists before attempting to cache the result or results from multiple requests.
- We have made some minor tweaks so that the app doesn’t error when an unknown item type gets added to the Costs to Expect API.
We have released a new version of the Costs to Expect Website.
The Website was far too needy and we needed to tweak the cache settings, we are closer to a sensible cache setup and will work to improve it in the future.
The full changelog is below:
- We have added caching for the requests not covered in the v1.11.0 update.
- We have updated the back-end dependencies.
- We have updated the front-end dependencies and switch to using the slim and minified versions.
- We have refactored the ‘Request/Api’ class to remove code duplication.
- We have increased the cache lifetime to four hours.
- We have fixed a typo in the ‘Request/Api’ class.