How should scheduled queries not created by the current user be handled?

[briandennis]

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?

[nicolaskruchten]

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]

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]

@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]

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]

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]

@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.yaml if the user deletes the grid associated with the scheduled query (or if the user stops having the necessary permissions to update the grid).

[briandennis]

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.