Skip to content
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

Conversation

jmbrunskill
Copy link
Collaborator

@jmbrunskill jmbrunskill commented Oct 3, 2023

Closes #165

πŸ‘©πŸ»β€πŸ’» What does this PR do?

Kapture 2023-10-03 at 17 57 39

πŸ§ͺ 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.

@jmbrunskill jmbrunskill linked an issue Oct 3, 2023 that may be closed by this pull request
4 tasks
@github-actions
Copy link

github-actions bot commented Oct 3, 2023

Bundle size difference

Comparing this PR to main

Old size New size Diff
2.1 MB 2.1 MB 754 B (0.03%)

@jmbrunskill jmbrunskill changed the title 165 cold chain notification configuration should show the real locationsstores 165 cold chain notification configuration should show the real sensors Oct 3, 2023
Temperature Alerts will look something like this...
-----------------------
High temperature alert!
pub struct ColdChainPlugin {}
Copy link
Collaborator Author

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;
Copy link
Collaborator Author

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);
Copy link
Collaborator Author

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?

Copy link
Contributor

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
Copy link
Collaborator Author

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: '{}',
Copy link
Collaborator Author

@jmbrunskill jmbrunskill Oct 3, 2023

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...

@jmbrunskill jmbrunskill marked this pull request as ready for review October 3, 2023 05:11
…onfiguration-should-show-the-real-locationsstores
@jmbrunskill
Copy link
Collaborator Author

Sorry I merged the windows service PR here, but shouldn't have. Please ignore commit 9d11fc3

@clemens-msupply clemens-msupply self-requested a review October 10, 2023 21:24
Copy link
Contributor

@clemens-msupply clemens-msupply left a 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"
Copy link
Contributor

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?

Copy link
Collaborator Author

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...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

width: 150,
sortable: true,
accessor: ({ rowData }) => {
return sensorDisplayName(rowData);
Copy link
Contributor

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...

@jmbrunskill
Copy link
Collaborator Author

One thing I noticed: send_high_temperature_alert_telegram could be moved into the test, right?

This changes quite a lot in the next PR. will leave that for review there...

@jmbrunskill
Copy link
Collaborator Author

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?

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 plugins. Maybe it is ok how it is though?

The JSON blob idea isn't crazy, hadn't thought of that. Something like pluginDataRequest(plugin_name: String, requestBody: String)?

I think I'll leave it for this PR though...

@jmbrunskill jmbrunskill merged commit 60bdd14 into main Oct 11, 2023
@jmbrunskill jmbrunskill deleted the 165-cold-chain-notification-configuration-should-show-the-real-locationsstores branch October 11, 2023 03:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cold Chain Notification Configuration should show the 'real' locations/stores
2 participants