f1ee35b890
* added empty state text * update permission group in the dataset * Enhance dataset asset listing with organization-specific filtering - Updated the `list_assets` function to include organization ID filtering in dataset permissions queries. - Removed redundant organization ID filters from the dataset permissions queries to streamline the logic. - Ensured that only relevant dataset assets are returned based on the user's organization, improving data security and relevance. These changes enhance the API's ability to serve organization-specific data, aligning with recent improvements in dataset asset APIs. * containerized class should be white with no border at bottom * clear query when signing out * Use correct endpoint for dataset groups * yaml syntax highligting * create dataset endpoints * update disable logic for deploying a dataset * Refactor user routes to include new endpoint for retrieving user by ID - Removed the public modifier from `get_user` and `update_user` modules to encapsulate them within the module. - Added a new route to the user router for fetching a user by their ID, enhancing the API's functionality. - This change improves the user management capabilities by allowing retrieval of specific user details based on their unique identifier. * Add organizations module and integrate with user routes * remove unused imports and abstract variables * Refactor user update functionality to support role changes - Enhanced the `update_user` endpoint to accept and process user role updates alongside name changes. - Introduced a new `UserResponse` struct for improved response handling. - Updated the `update_user_handler` to handle changes in both user name and organization role, improving the flexibility of user management. - Adjusted response type to return no content upon successful updates, aligning with RESTful practices. These changes enhance the user management capabilities by allowing for more comprehensive updates to user information. * Update user route to use ID parameter for updates - Changed the user update route to require a user ID in the URL, enhancing RESTful practices. - Updated the `update_user` function to extract the user ID from the path, ensuring the correct user is updated based on the provided ID. These changes improve the clarity and functionality of the user update endpoint, aligning it with standard REST conventions. * simplify hooks imports * Remove unused component * restructure folders for layout * update imports for gloabl components * add additional routes * Implement user permission checks in dataset deployment and user update routes - Added permission validation to the `deploy_datasets` and `post_dataset` functions to ensure only users with workspace admin or data admin roles can execute these actions. - Enhanced error handling for permission checks, returning appropriate HTTP status codes and messages for insufficient permissions and internal errors. - Updated imports to include the new security checks module for consistency across routes. These changes improve security by enforcing role-based access control in critical dataset operations. * Refactor user update route to enhance RESTful practices - Updated the user update route to require a user ID in the URL, ensuring the correct user is updated based on the provided ID. - Improved clarity and functionality of the `update_user` function by extracting the user ID from the path. These changes align the user update endpoint with standard REST conventions, enhancing overall API usability. * Enhance dataset listing functionality with user organization roles - Refactored dataset listing logic to incorporate user organization roles, allowing for more granular access control based on user permissions. - Introduced new role checks for `WorkspaceAdmin`, `DataAdmin`, `Querier`, `RestrictedQuerier`, and `Viewer` to determine dataset visibility. - Updated database queries to fetch datasets based on user roles and organization associations, improving data retrieval efficiency. - Removed deprecated functions and streamlined the dataset fetching process, ensuring clarity and maintainability in the codebase. These changes improve the API's security and usability by enforcing role-based access control for dataset operations. * tweaked the post thread permissions handle. * permission_group string fix * remove package.json * fix: Add release please syntax handler and github action (#40) * fix(buster): Add release please syntax handler and github action * chore: add version tracking setup fix: update update nate rulez --------- Co-authored-by: dal <dallin@buster.so> |
||
|---|---|---|
| .. | ||
| migrations | ||
| python | ||
| src | ||
| supabase | ||
| Cargo.toml | ||
| Dockerfile | ||
| README.md | ||
| diesel.toml | ||
| makefile | ||
README.md
Buster Business Intelligence API
This API runs the Buster Business Intelligence service.
Get Started
- Load the .env file in the root of the project.
- In your terminal run
make dev. - Service is now available at http://localhost:3001
Repo Structure
All functional code is located in the src library. The main.rs file is the entry point for the application.
The repo is organized like so:
routes/contains the routes for the API. Each route is contained in its own file with a handler function.types/this contains general types that will be used across the app such as database types. If you would define a type multiple times, it shoudl go here. However if a type is constrained to a specific function, it should not go heremiddleware/this contains middleware for the app.utils/this contains clients and functions that would frequently be used across the app. If you would define a function multiple times, it should go here. However if a function is constrained to a specific route, it should not go heredatabase/this contains the database connection helpers, migrations, and database ORM system powered by Diesel.
routes/
The routes/ folder contains the routes for the API. The entrypoint to the routes is in the mod.rs file.
Routes are grouped into folders based on functionality. For example, a /users folder would contain all of my POST, GET, PUT, DELETE routes for the users resource.
Each route is defined in its own file with a handler function. This function receives user information through our middleware and uses types to define the input and output of each request.
Tests should be written directly in the route file and on the handler.
types/
The types/ folder contains general types that will be used across the app. If you would define a type multiple times, it should go here. However if a type is constrained to a specific route, it should not go here
Types should be grouped into folders based on the resource they are related to. For example, a /config folder would contain all of the types related to typed configurations throughout the app.
middleware/
The middleware/ folder contains middleware for the app. Middleware is a function that runs before the route handler. We don't use that much middleware so there are just two files in this folder.
utils/
This folder contains the clients/ folder and other groups of functions that would frequently be used across the app. If you would define a function multiple times, it should go here. However if a function is constrained to a specific route, it should not go here
The clients/ folder contains clients for the app. A client represents a functional service like OpenAI, Supabase, etc. These clients should always be defined as structs with methods implemented on them.
database/
This folder contains the database connection helpers, migrations, and database ORM system powered by Diesel.