atilioa / alertadotesouro Goto Github PK

ToastContext? Toast component?? What does this all mean?

It is non-working since #46.

I honestly don't know why the hell I did this but I think this was used as a workaround to create a new TreasuryBond if it has never been seen before, e.g.: if a new bond is created by the federal government and is now listed on the API response, it should be added to our SQL database. Could have been for any other reason though...
The current solution obviously has the problem of an extern agent being able to freely create TreasuryBond objects.

Users should be able to export all their data, to be received via e-mail. A .json file with everything (e-mail, notifications, notification preferences) serialized should suffice.
There should be a button under the /conta front-end route that starts the request for data export.
Loosely related to #36.

Currently, the URL for email confirmation returns a JSON with a success/failure message and some User data. This needs to have a front-end, i.e. redirect the user to a React page.
I'm not sure how feasible is redirect + toast message, but that would be preferred.

What is the difference between ResetUserPasswordService and UpdateUserService? Those files seems very much identical

This should provide nice feedback for users and also prevent spam from regular users. This is more relevant to buttons that do network-related actions (requests to the backend, etc; not essential for the logout button, for example)

Users should be able to reset their passwords whenever they wish by receiving an email.
The front-end also still has a blank /forgot route/page on the website.

Currently, the styling of components is highly redundant. This would be easily solved by moving a lot of definitions to the global style located at web/src/styles/global.ts.

To be honest, I think browser notifications are somewhat unreliable. Nevertheless, it would be cool to have this feature in our project, especially as it was a planned feature from the beginning.
I'll leave it as an extra. We can easily justify the removal of it from our scope at a later point. However, I don't believe it to be any hard to implement.

That's right. NO AUTOMATED TESTING IS ALLOWED IN THE VICINITY OF THIS REPOSITORY.

User creation might not be working properly, emailing can be reverted back to mailtrap. I bet notifications are borked too.

Currently, our navbar doesn't change, ever. Here are some things we can do to improve it:

1. "Conta" link should not appear when the user is not logged in;
2. "Logar" button should not appear when the user is logged in;
3. Underline the current page (when applicable);

Image showcasing of both of the last two requirements:

Existing endpoints lack documentation. Proper documentation should be included in the README, and if possible, TSDoc, to help with the development workflow.

Market status info can be retrieved from the API: ["response"]["TrsrBondMkt"] yields:

1. opngDtTm: opening datetime
2. clsgDtTm: closing datetime
3. qtnDtTm: ? (for the love of God stop aggressively abbreviating things!!). anyways, this should be of no use to us
4. sts: market status ("Aberto" or "Fechado")

We can format those as:
'Mercado aberto/Mercado fechado: [current time in HHhMM]'
'Horário de funcionamento: de HHhMM às HHhMM.'

Back when I draw this view, I was thinking about having the 'Atualizado às XX/XX/XXXX, XX:XX.' with a refresh button to its left, allowing the user to refresh the data without reloading the whole page. This might be a bit unnecessary since treasury bonds rates don't fluctuate too heavily within a day.
This simplified version cleans up some information and space, concentrating information tightly (without going overboard as well).

The cards are missing all of their functionality as well. This is where the users can subscribe to/create notifications.

Extra: The grey circled 'i' would flip the card and exhibit information about the bond, but that would be even harder. However, it is a reasonable solution since the text is rather long. I'm still not sure what to make of it. To start off, we might leave it as a simple tooltip text.

Extra: it would still be nice if the dashboard automatically updated the rates every 15 minutes. muh SPA

The project is set to use *mail as its email provider, but switching back to Mailtrap should be trivial.

Users should be able to edit their password, export their account data, log out and also delete their account at /conta.

Consider the following situation:

1. User creates an account
2. Server sends email promtping user to confirm email address
3. Email is sent to user, but is {not delivered, rejected, bounced, fell into a deletion rule, etc}

Then:

• User can't login because account is not confirmed
• User can't create a new account on the same email address

Could be any other code coverage solution, but I've used CodeCov and can recommend it.
Depends on #27. Both will probably be demanded by JP.

List all of the user notifications.
Make toggle buttons, editing and exclusion of notifications actually work.
Should be easier than #49.

we need some QA smh jp is asking for it

Since this web app heavily relies on creating an account to enable usage, it is reasonable to provide a Terms of Service and a Privacy Statement for all potential users to read.

Example:

Invalid e-mail should cause FiUser (now FiAtSign) icon to go red.

Steps to reproduce:

1. Load SignUp page (/registrar)
2. Place any character into any input field
3. Click submit button

Instead of only running backend in containers, a docker-compose should be more accessible and easier to the end-user, since they will need docker to run the backend anyway. That should even help when developing frontend.

What needs to be done in order to achieve it:

• Create a dockerfile that builds the project and then runs it.
• Create a docker-compose file that runs both the backend and then the frontend, all in the same network. In the future, the backend application can be in more than one network, to be in a separate network with only backend app and frontend.

With this, you should be able to run all applications (in the proper order) with docker-compose up, creating a docker container for each service instead of doing that with separate commands and the application in the shell session.