-
Notifications
You must be signed in to change notification settings - Fork 1
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
165 cold chain notification configuration should show the real sensors #169
165 cold chain notification configuration should show the real sensors #169
Conversation
Bundle size differenceComparing this PR to
|
Temperature Alerts will look something like this... | ||
----------------------- | ||
High temperature alert! | ||
pub struct ColdChainPlugin {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Making cold chain a plugin isn't really required for this PR, as it's currently using an SQL query in the frontend to retrieve data. I think it should somehow query the plugin instead, but leaving that for a separate PR & Issue.
Figured it doesn't hurt to keep this change in this PR.
const onSubmit = async () => { | ||
if (selectedIds.length === 0) { | ||
setErrorMessage(t('messages.nothing-selected')); | ||
// return; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what we want here. Should someone be able to select no sensors, I can see why it could be useful when your playing around, but also see the arguement for requiring one...
width: 150, | ||
sortable: true, | ||
accessor: ({ rowData }) => { | ||
return sensorDisplayName(rowData); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we render the store, location and sensor separately rather than display name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes I would say so...
onClose={onClose} | ||
setSelection={setSelection} | ||
/> | ||
<IconButton |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't love this edit button, but keen for ideas how we could do it better, perhaps some examples from another app?
"SELECT sn.id as id, s.name as store_name,coalesce(l.description, '') as location_name, sn.name as sensor_name FROM SENSOR sn JOIN store s ON sn.storeid = s.id LEFT JOIN location l on sn.locationid = l.id WHERE sn.is_active = true ORDER BY 2,3,4 LIMIT 1000"; | ||
const response = await sdk.getColdChainSensors({ | ||
sqlQuery: sensorQuery, | ||
params: '{}', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Figured if we stuck with this approach, we could pass parameters to say search if we end up with too many sensors in a big installation...
β¦onfiguration-should-show-the-real-locationsstores
Sorry I merged the windows service PR here, but shouldn't have. Please ignore commit 9d11fc3 |
β¦ould-show-the-real-locationsstores
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding, your query question. As it looks like it the backend is kept minimalistic and just provides the core functionality(?). I think then it makes sense to move the logic to the frontend (into frontend plugins I guess).
Do we need backend plugins at all? If you do, it would make more sense to provide the sensor list through the backend though(?) But what would be the generic interface to communicate between frontend and backend plugins? the frontend plugin sends a json blob to its backend plugin?
Or you make cold chain sensor a build in feature and provide proper graphql queries but as you said this would be extra work.
One thing I noticed: send_high_temperature_alert_telegram
could be moved into the test, right?
@@ -86,5 +86,6 @@ | |||
"helper-text.sql-query": "Your sql query can contain parameters, which are created using double curly braces within the query. For example: SELECT * FROM my_table WHERE id = {{param1}} AND name = {{param2}}", | |||
"label.test-sql-query": "Test SQL Query", | |||
"tooltip.manage-recipient-list": "Manage Recipient List", | |||
"message.no-parameters": "No parameters found" | |||
"message.no-parameters": "No parameters found", | |||
"message.no-sensors-selected": "No sensors selected" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: do you need a distinction between common.json
and system.json
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's pretty messy right now probably should create a coldchain one at least...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
frontend/packages/system/src/Notifications/api/hooks/useColdChainSensors.ts
Show resolved
Hide resolved
width: 150, | ||
sortable: true, | ||
accessor: ({ rowData }) => { | ||
return sensorDisplayName(rowData); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes I would say so...
frontend/packages/system/src/Notifications/Pages/ColdChain/CCNotificationEditForm.tsx
Outdated
Show resolved
Hide resolved
This changes quite a lot in the next PR. will leave that for review there... |
Yes, well we need them in that we want to support coldchain and scheduled reports and potentially other things in the future. Right now I'm just trying to implement them in their own crates until they are properly The JSON blob idea isn't crazy, hadn't thought of that. Something like I think I'll leave it for this PR though... |
Closes #165
π©π»βπ» What does this PR do?
π§ͺ How has/should this change been tested?
This needs an mSupply postgres (AKA Dashboard) database setup.
Ideally with coldchain sensors configured, although might be interesting to figure how/what we should display if there are no sensor...
π Any notes for the reviewer?
I'm not sure if the SQL Query in the front is a good, longer term plan.
I think the longer term plan (plugin queries perhaps?) should go in a seperate issue with design, and this might need to be merged for expediency, unless another quick to implement option is thought of.