This repository was archived by the owner on Aug 29, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on Aug 29, 2025. It is now read-only.
How should scheduled queries not created by the current user be handled? #501
Description
Currently, if a scheduled query was created by a different user than the one currently logged in, it is read only.
Is this correct behavior? If Falcon is running on a shared server, are there cases where multiple users should have permission to edit/delete a single scheduled query?
Activity
nicolaskruchten commentedon Jul 25, 2018
Interesting question. @BRONSOLO @tarzzz can you help answer it?
@briandennis when you say "it is read-only" what does that look like in the UI?
This makes me think: should we have a legit "edit" button in the scheduled tab to make it extra-clear that that's how you edit stuff? And then the edit button could be greyed out with a tooltip if read-only?
nicolaskruchten commentedon Jul 25, 2018
I think I would be comfortable with allowing users to edit each others' queries IF the edits aren't saved unless the first save succeeds. Presumably if user X is trying to edit user Y's query targeting a fid belonging to Y, and X does not have write access to that fid, then her first update will fail with an informative error message and everyone is happy.
briandennis commentedon Jul 25, 2018
@nicolaskruchten in the UI that means they'll still see the query in the list and can still view it's details. But the edit/delete buttons are hidden (equivalent to not being logged in).
briandennis commentedon Jul 25, 2018
re allowing users to edit each others' queries:
Maybe @n-riesco can shed some light here as I don't completely understand the logic, but this description of behavior makes me nervous about that solution. If user X not having permission leads to user Y's query getting removed that seems problematic. At the same time though, the query won't be able to run anyway if user X's access token replaces user Y's, right?
nicolaskruchten commentedon Jul 25, 2018
OK. I'm fine with the current read-only behaviour unless @n-riesco thinks it's a problem, and so long as we haven't changed the behaviour of Falcon wrt to the old UI.
n-riesco commentedon Jul 25, 2018
@briandennis @nicolaskruchten I don't have the whole picture, because I'm not very familiar with Plotly's API. But this is how it goes in Falcon:
whenever a user goes through the oauth2 procedure successfully, the access token is stored in
~/.plotly/connector/settings.yaml(see https://github.com/plotly/falcon-sql-client/blob/dd7ec836b0dde2d12ebc38f1d4101743d5ce3aad/backend/routes.js#L340 )whenever a scheduled query is run, the access token corresponding to the requestor is retrieved from
~/.plotly/connector/settings.yaml(see https://github.com/plotly/falcon-sql-client/blob/dd7ec836b0dde2d12ebc38f1d4101743d5ce3aad/backend/persistent/QueryScheduler.js#L227 ). I.e. Falcon's backend uses the credentials associated associated to the requestor (note that the requestor is stored in the queryObject)my reading of https://github.com/plotly/falcon-sql-client/blob/dd7ec836b0dde2d12ebc38f1d4101743d5ce3aad/backend/persistent/QueryScheduler.js#L308-L338 is that the query is deleted from
~/.plotly/connector/settings.yamlif the user deletes the grid associated with the scheduled query (or if the user stops having the necessary permissions to update the grid).briandennis commentedon Jul 25, 2018
Thanks for the info @n-riesco, really informative!
As per discussion, we're going to leave the current read-only behavior in place for now. Note #500 adds a message to inform the user why the query is read-only.
Closing this for now, let's reopen down the road if we want to update this behavior.