Description

After updating some field, an update should be made to the DB backend.

TODO

• Trigger an update after field change

Depends

List of issues in which this feature depends (may be empty):

• #3
• #5

Description

The final user of the app should be allowed to do the following actions once they log inside the app.

TODO

• Add new customer
• Add new pet
• Add new stay
• Remove existing customer (without deleting their registry)
• Remove existing pet (without deleting their registry)

Depends

List of issues in which this feature depends (may be empty):
As the app development evolves, some issues will be linked to this one.

• ...

Description

Description

Users may want to add their own avatar to their profile.

TODO

• Implement image serialization

Depends

List of issues in which this feature depends (may be empty):

• ...

Description

App should know how it must be initialized (which logo it will be using, specific text and translations...)

TODO

• Reference every variable from a JSON file
• Unspecified variables should be grabbed from a hardcoded JSON

Depends

List of issues in which this feature depends (may be empty):

• ...

Description

App content should be translatable to other languages. We should find a way to implement it via standardized translation files, such as CSV files.

TODO

• Search info, and update this issue.

Depends

List of issues in which this feature depends (may be empty):

• ...

Description

Users may want to completely prune the DB. DB should be removed, and SQL init scripts will be re-executed.

TODO

• Remove DB from the filesystem
• Trigger signal to re-execute every init script of the system

Depends

List of issues in which this feature depends (may be empty):

• ...

Description

As the application is intended to be used as a platform, we shouldn't name it as a specific type of data management app, but more like a generic data management platform. Suggested names are:

• DataFlow: It's easy to remember and pronounce, and suggests an efficient and fluid flow of data.

• BizData: It's short, easy to remember and pronounce, and suggests a business application for data management.

• DataWorks: It's easy to remember and pronounce, and suggests an application that helps make data "work" effectively.

• InfoPro: It's short, easy to remember and pronounce, and suggests a professional application for information management.

• WorkFlowPro: It's easy to remember and pronounce, and suggests an application that helps improve efficiency in business workflows.

Currently, and as a placeholder, I'll use DataWorks, but feel free to suggest new ones.

TODO

• Select a marketable name for the app

Testing deploy with Kasm

Kasm Workspace. Kasm Workspace is a cloud-based application and desktop virtualization solution.

Kasm

Description

The app shouldn't allow users to do anything until a DB initialization script has been placed. Also, users should be able to watch when somethings has been completed (tables created, fields text variable adapted...) via progress bar, so they can interactively follow the instructions given by the application.

Thanks to the dynamic nature of web technologies, this shouldn't be a very difficult task.

TODO

• Listen to changes in users FS for executing newly created scripts (should prompt before starting the actual execution)
• Notify user when anything has been completed

Depends

List of issues in which this feature depends (may be empty):

• ...

Description

We should define the app DB structure before starting any of the actual app end work. As stated in the official wiki, we should define one focused in the management of a pet hotel.

The ones that have been clarified are the following:

Customer:

• Name: String
• Surname: String
• Address: String
• Bank data (may be expanded into more fields)
• Active: Bool (represents if the customer has not been deleted, useful when customers want to shut down their accounts while keeping their history on the system)

Pet:

• Name: String
• Race: String (picklist?)
• Additional treatments: String

Customer-Pet:

Customers may have one to N pets
1-n

Pet should be saved in the customer table`

Stay:

• CustomerID (PK)
• PetID (PK)
• Enter date: Date
• Exit date: Date

TODO

• Discuss the DB structure.
• Prepare data insertion script.

Depends

List of issues in which this feature depends (may be empty):

• ...

Description

Users should be able to check whether the key they're referencing in the insertion dialog is the actual foreign registry they want to link to.

TODO

• Query the foreign key table to display a data visualization
• (?) Hide unnecessary columns

Depends

List of issues in which this feature depends (may be empty):

• ...

Description

Data updating is still not implemented. This should be top priority before the project deadline.

TODO

• Implement data updates

Depends

List of issues in which this feature depends (may be empty):

• ...

Description

Register creation dialog fields should be adapted to reflect the data type inside the DB. There are multiple ways to implement this. As its hasn't been decided yet, this case implementation is considered open for discussion.

What's currently defined is the way fields will be interpreted by the app renderer:

• We will receive all the fields of the object, and their type (password: password field, email: text field, age range: drop-down list...).
• For each field, create a new element with the appropriate id, hint, type... inside the dialog.

TODO

• Define the implementation.
• (?) Header JSON holding each data structure and its expected
• (?) Header inside the DB holding each data structure fields
• Implement it!

Depends

List of issues in which this feature depends (may be empty):

• #5

Description

The app should have a base logo.

TODO

• System icon
• Greeter icon

Depends

List of issues in which this feature depends (may be empty):

• ...

Description

We can try adding dark mode to our UI, we still have to redesign the app.

• https://mui.com/material-ui/customization/dark-mode/

Description

We need to include the repository where I am currently working on the Website

TODO

• Add a submodule to this repository

Description

At least, backend code should be documented so we can easily expand upon what's already built without having too much trouble. For example, the DB API should make use of this.

Finally, we should be able to auto generate doxygen docs, and merge it with the presentation docs.

TODO

• Document backend source code
• Document frontend source code

Depends

List of issues in which this feature depends (may be empty):

• ...

Description

Users should be able to access an overview where DB contents should be displayed. They may create, remove or modify registers.

Ideally, this should be tailored to each client requirements, but a basic table view should be enough as a placeholder.

TODO

• Register creation modal
• Register deletion button (each register should have their own)
• Register modify button (each register should have their own)
• Overview
• (?) Some way to instruct the app how data should be displayed (extension scripts?)

Depends

List of issues in which this feature depends (may be empty):

• #3 (Full functionality integration)

Description

Users must be able to validate themselves against the local DB before committing any changes or querying any data.

TODO

• Create a DB table for storing user data.
• Bind the query from main process onto the Login action button.
• First run on the app should display a user creation dialog.

Depends

List of issues in which this feature depends (may be empty):

• ...

Description

The application should greet users with a welcome screen. Users may select a login option, which will prompt a dialog for authenticating against the SQLite DB.

TODO

• Install SQLite in the project using npm package manager
• Read the docs

Depends

List of issues in which this feature depends (may be empty):

None

Description

We want to implement a webpage to show documentation and download the application