-
Notifications
You must be signed in to change notification settings - Fork 552
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for bulk creating beds inside a location #10585
Comments
i would like to work on this. |
issues will be assigned once the solution to solve this is approved; do share your thoughts on how to solve this. |
Hmm, as much as I understood, we can have the prefix name from user and also starting and ending numbering label for example A1 to A10. And prefix 'Bed' and push the array from Bed A1 to Bed A10 |
Approach
|
Approach for Dynamic Bed Naming & Optimized API Request1. User Input Fields in Location Form
2. Real-Time Bed Name Preview
3. Optimized API Request Structure
{
"location_id": "12345",
"bed_type": "ICU",
"count": 3
} 4. Backend Processing & Database Update
5. Validation Rules
|
@rithviknishad is the backend open for contributions now |
@rithviknishad we can ask the user to add multiple beds once the user selects location form as bed. We can create a separate model for Bed in the backend with fields bed_type, number_of_units, location referencing to existing facilityLocation model or we can also create a JSON field of beds in FacilityLocation Model anything can be preferred. And it will be better to create a separate model for Bed Types also which would allow admin to add default bed types. In frontend we can show a select field with all those bed types as choices. |
Is your feature request related to a problem? Please describe.
When setting up locations of a facility, there'd be multiple beds inside a location. To ease data entry effort, we should be able to bulk create beds (eg. Bed 1, Bed 2, Bed 3, etc...).
Describe the solution you'd like
We could either ask the prefix name from the user and call the API.
Describe alternatives you've considered
We def. can/should explore more better ways to approach this
The text was updated successfully, but these errors were encountered: