Month: March 2020

In this release, we update the management of `simple-item` items. You can add items directly from the data table as well as adjust the quantity.

Added

• We have added an inline form to the `simple-item` data table; this allows quick addition of items.
• We have added increment and decrement buttons to the `simple-item` data table; these enable the quantity to be adjusted swiftly.

Changed

• We have renamed the $allow_edit variable; based on our permission system, $write_access is a more suitable name.
• We have slightly reduced the cache lifetime; the App cache is a short-term solution until we add caching to the Costs to Expect API.
• We have tweaked the `simple-item` data table; we hide the “Created” column at mobile screen sizes.
• We have tweaked the API requests data table; we hide the “Response” and “Method” columns at mobile screen sizes. 

In this release, we have added editing. You may be wondering why it took so long, well, we wanted to get the base of the App just right before we started to increase functionality. 

Added

• We have added the ability to edit `allocated-expenses`, `simple-expenses` and `simple-items`.
• We have added edit icons to the resource data tables.

Changed

• We have added the missing metadata necessary for share cards.

Fixed

• We have updated the layout file for our error pages, the inline styling; Our Content Security Policy was not keen on the inline styles.

For this release, we make a couple more changes, changes that do not only exist to help the App. If you review the API response for an `item` with the relevant include parameters set, it makes sense to include the `uri` field.

Changed 

• When a response includes additional data via the include parameters, we include the URI fragment for that data.

This release is a small point release to “assist” with development of the edit functionality within the App. 

The new parameters exist for the collection; in adding them for an ‘item’, we are not bending the API to the will of the App. The scare quotes are present because we would prefer not to add support to an ‘item’; however, the performance gain is substantial.

Changed

• We have updated the `resource-types/[id]/resources/[id]/items/[id]` GET endpoint; the `include-categories` and `include-subcategories` can be included in the request for ‘allocated-expense’ and ‘simple-expense’ type items.

In this release, we become a better internet citizen, make managing assigned filters easier, tweak our styling and fix some bugs.

Added

• We have added the expected security headers to be a better web citizen.
• We have added an assigned filters section above data tables; it is simpler to remove a set filter.

Changed

• We have switched to a new font; the font is more legible at small screen sizes, and, it looks cool.
• We have updated our front-end dependencies.
• We have updated our back-end dependencies.
• We have tweaked the styling of the “Start tracking” section.

Fixed

• We have tweaked the styling of the “API requests” table for mobile screen sizes.
• We have updated our Uri/Parameters class; it casts parameter values to the expected type to allow more strict checking later in the flow.
• We have removed an infinite redirect; Mrs Costs to Expect wasn’t happy that she couldn’t log in.

We have pushed out a point release of the API, lots of small tweaks.

Changed

• We have switched to a new font; the font is more legible at small screen sizes, and, it looks cool.
• We have reviewed our HTTP headers; Content-Language missing along with other expected headers.
• We log the id of the user that added a user to the ‘permitted_user’ table; this is to help later with permitted user management.
• We have updated the API to the most recent version of Laravel 6.

Fixed

• The `description` field for the `simple-item` type should be nullable.

In this release, we have added the ability to create `simple-expense` and `simple-item` items; the functionality of the App just increased, Mrs Costs to Expect can now log “bucket” expenses as well as manage lists.

Added

• We have added the ability to create `simple-expenses` and `simple-items`.
• We have updated the resource summaries; they are now specific to each item type.
• We have added a visual guide to highlight active filters on data tables.

Changed

• We have trimmed down the menu options dependant on the item type selected for a resource type. For example, the resource type view is unnecessary for `simple-expense` and `simple-item` item types.
• We have updated the labelling on the create forms; the labelling is less generic.
• We have tweaked the styling for the pagination controls and information section; they look less like actionable controls

Fixed

• The `description` and `publish after` fields were not getting sent to the API for a create allocated expense request.
• The selected `year` and `month` values were not “sticky” in the filtering options.
• The pagination controls will no longer expose any internal request parameters; the `include-categories` and `include-subcategories` parameters should not be controllable by the user. 

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.

Added

• 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.

Changed

• 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.

Fixed

• 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.

Changed

• 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.

Added

• 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.

Changed

• 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.

Fixed

• We have updated the `Option/Get` class, the `sort`, `search` and `filter` parameters will only display if there are viable parameters.

Removed

• We have removed the layout file, not used as there is only one view file for the API.