af7e969af8
* fix permission check on post_dataset rest * refactor: enhance dataset overview access lineage and permission checks - Updated the `get_dataset_overview` function to conditionally add default access lineage based on user roles and existing access paths. - Simplified the logic for adding user roles to the lineage, ensuring clarity and maintainability. - Improved handling for the `RestrictedQuerier` role to include checks for existing access before adding default lineage, enhancing permission accuracy. - Streamlined code by removing redundant checks and consolidating role handling, optimizing overall readability. * feat: Enhance permission group handling and data retrieval - Introduced a new `PermissionGroupInfo` struct to encapsulate detailed information about permission groups, including user and dataset counts. - Updated the `get_permission_group` and `list_permission_groups` functions to improve data retrieval and error handling. - Refactored SQL queries in `list_permission_groups` to include additional joins for counting users and datasets associated with permission groups, enhancing the overall functionality and clarity of the API. - Streamlined code for better readability and maintainability, ensuring consistent handling of user and permission group data. * refactor: Improve dataset access handling and permission checks - Enhanced the `get_restricted_user_datasets` and `get_restricted_user_datasets_with_metadata` functions to include additional permission checks for dataset groups and permission groups. - Consolidated SQL queries to ensure proper filtering of deleted records and improved clarity in dataset retrieval logic. - Introduced new joins and filters to handle dataset group permissions, ensuring accurate access control for users. - Streamlined code for better readability and maintainability, enhancing overall functionality in dataset access management. * fix: Update SQL migration and seed data for user attributes - Modified the SQL migration to specify the schema for the `users` table, ensuring clarity in the update statement. - Adjusted the seed data for `users_to_organizations` to change the `organization_id` from 'public' to 'none', reflecting a more accurate state for user roles and organization associations. - Ensured consistency in the formatting of SQL insert statements for better readability. * fix: Prevent users from updating their own profiles - Added a check in the `update_user_handler` to prevent users from updating their own information, returning an error if they attempt to do so. - This change enhances security by ensuring that users cannot modify their own records, which could lead to unauthorized changes. * refactor: Simplify dashboard permission queries by removing team-based joins - Removed left joins with `teams_to_users` table in dashboard permission queries - Simplified permission checks to only filter by direct user ID - Updated queries in `get_user_dashboard_permission`, `get_bulk_user_dashboard_permission`, and `list_dashboards_handler` - Streamlined SQL query logic for more direct and efficient permission checks |
||
|---|---|---|
| .. | ||
| migrations | ||
| python | ||
| src | ||
| supabase | ||
| .cursorrules | ||
| .gitignore | ||
| 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.