We have published a few new features for the Budget App which are now available – check it out or continue reading to see what we’ve changed.
We use Budget ourselves and our mantra is that if it isn’t suitable for our needs, then it isn’t likely to be suitable for anyone else. We received feedback concerning the limit and got close to hitting it ourselves. We don’t want to think about reaching the limit again so we’ve increased the limit to one hundred budget items.
If you track multiple accounts, there is an important piece of information missing from the Budget overview – the account an expense relates to. Space is at a premium on the Budget Overview; we can’t add the name of the account in addition to everything else as it will end up looking too busy. To solve this, we now allow you to set a colour for each account. Each expense will now include a small icon in the relevant colour so you can identity the account related to the expense.
We have made a couple of minor changes to the design of the projection sections – primarily for mobile users. This area of the Budget overview is very much work in progress and we are figuring out to use the extra space for tablet and desktop users.
We have tweaked the expense bars to show a larger differentiation for smaller value expenses. Under £5 will now display differently to under £25.
We have made a couple of minor content changes and update the included
env.example file for any developers who may want to host their own version of Budget.
On the way
We have several features in the works, feedback has been incredible and by using it ourselves, we are able to see where the usability falls down.
- We are going to add a search to the Budget overview
- We are going to add a “transfer” option – more on this soon.
- We are going to add the ability to act on multiple budget items at once. Again, more on this soon.
We have published a couple of fixes for the Budget beta both of which relate to editing an expense.
Account / Target account
When you edit an expense, the “account” and “target account” fields will now be set to the correct value. Previously, the first value was always selected.
Editing a one-off expense and changing the “due date” could cause the expense to disappear. The expense still existed; it just wouldn’t be shown because of a data issue relating to its end date. We have corrected all one-off expenses and they will display again.
We have a couple of fixes on the way:
- We are going to make the app easier to use for people who have multiple projection accounts.
- We are going to increase the limit for expense items. A freelance user informed us that they need to use one-off expenses and the limit of 35 isn’t friendly for that type of usage so we are going to set the limit to one hundred.
We have released an update to Budget which includes the first batch of changes raised by our beta users.
Please review the below and let us know if there is anything we have missed. Our goal is to make Budget as easy to use as possible and all the lessons we learn with Budget will make Budget Pro better.
Locked in the demo
Users who opted to load the demo felt locked in once the demo had loaded; there was no obvious way to return to the beginning and create your own Budget. Our thought process was based around the user “adopting” the demo and using it as the starting point for their own Budget. We have added a button which always shows next to “Adopt” which takes the user to the reset page so they can reset their App and start afresh.
We had added four more currencies to the App – Candian, Australian and New Zealand Dollar and the India Rupee. We will add additional currencies upon request – just let us know if there are currencies you’d like included.
Hello fellow developers!
The Budget App is open source. We reviewed the README and have updated the installation instructions to ease setup and we have added some helpful values into the .env.example file.
You can set up your own instance of Budget or even submit suggestions via GitHub. All contributions welcome and very much appreciated.
With the impending releases we are making the API more testable and improving the first-install process.
- We have started transferring our Postman response tests to local feature tests.
- We have added tests for the
- We have started writing tests for the
- We have updated
/auth/register, both now support a
send GET parameter, if defined, no email will be issued.
- We are tweaking the first install; we have squashed all the migrations and tweaked the Docker setup. We have added an
initial-install.sql file, this includes the required data for the API.
- We have made minor changes to how we return validation errors; we were calling
exit and stalling our tests.
- We have updated the responses for
/auth/register; responses include the required follow-on URIs and parameters.
- We have updated the README, we have added a
Tests section and updated the setup steps.
We are working towards releasing the beta for the Costs to Expect App and releasing other apps; we have therefore opened up the registration on the API.
- We have opened up registration on the API; you can register, login, and use all the expected authentication features.
- We have added notification emails for registration and forgot password requests.
- We have switched to Laravel Sanctum and removed all references to Laravel Passport, Sanctum makes more sense for our API.
- We have updated to Laravel version 8.
- We have tweaked our Docker setup and removed composer and phpunit.
- Content updates
We had to tweak our sign-in after a change to the Costs to Expect API, the API switched to Sanctum from Passport.
- Switch to Sanctum on the Costs to Expect API, minor changes required.
- We have updated our cache invalidation; we will not clear as many cache entries on resource creation.
We have switched to using queues to clear cache.
- We have added migrations for the job and failed jobs table; we are switching to queues.
- We have switched to queues for cache clearing. Approximately 50% of our clear cache requests will be delayed and processed later; the rest of the clears are synchronous; it depends on where we are sending the user next.
- We have altered the TTL for API responses; the TTL is defined based on the age of the data in the API response, we use the X-Last-Updated header.
- Switching to named routes, work in process.
- Minor tweak to the meta viewport tag.
- We have reviewed the App and removed a couple of single instance classes and found better homes for some others.