-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Cannot Add Query-based Dropdown Parameter to a Saved Query #3711
Comments
rauchy
pushed a commit
that referenced
this issue
Apr 17, 2019
… might still not be associated with the parent. see #3711
1 task
rauchy
pushed a commit
that referenced
this issue
May 12, 2019
* propagate `isDirty` down to `QueryBasedParameterInput` * go to /api/:id/dropdown while editing a query, since dropdown queries might still not be associated with the parent. see #3711 * show helpful error message if dropdown values cannot be fetched * use backticks instead of line concatenation * remove requirement to have direct access to dropdown query in order validate it. parent query association checks are sufficient * remove isDirty-based implementation and allow dropdown queries through nested ACL even if they aren't associated yet (given that the user has _direct_ access to the dropdown query) * fix tests to cover all cases for /api/queries/:id/dropdowns/:id * fix indentation * require access to the query, not the data source * use require_access instead of has_access
rauchy
pushed a commit
that referenced
this issue
Jul 15, 2019
* change has_access and require_access signatures to work with the objects that require access, instead of their groups * use the textless endpoint (/api/queries/:id/results) for pristine queriest * Revert "use the textless endpoint (/api/queries/:id/results) for pristine" This reverts commit cd2cee7. * go to textless /api/queries/:id/results by default * change `run_query`'s signature to accept a ParameterizedQuery instead of constructing it inside * raise HTTP 400 when receiving invalid parameter values. Fixes #3394 * enqueue jobs for ApiUsers * rename `id` to `user_id` * support executing queries using Query api_keys by instantiating an ApiUser that would be able to execute the specific query * show deprecation messages for ALLOW_PARAMETERS_IN_EMBEDS. Also, move other message (email not verified) to use the same mechanism * add link to forum message regarding embed deprecation * change API to /api/queries/:id/dropdowns/:dropdown_id * split to 2 different dropdown endpoints and implement the second * add test cases for /api/queries/:id/dropdowns/:id * use new /dropdowns endpoint in frontend * first e2e test for sharing embeds * Pleasing the CodeClimate overlords * All glory to CodeClimate * remove residues from bad rebase * add query id and data source id to serialized public dashboards * add global parameters directive to public dashboards page * allow access to a query by the api_key of the dashboard which includes it * rename `object` to `obj` * simplify permission tests once `has_access` accepts groups * support global parameters for public dashboards * change has_access and require_access signatures to work with the objects that require access, instead of their groups * rename `object` to `obj` * simplify permission tests once `has_access` accepts groups * no need to log `is_api_key` * send parameters to public dashboard page * allow access to a query by the api_key of the dashboard which includes it * disable sharing if dashboard is associated with unsafe queries * remove cypress test added in the wrong place due to a faulty rebase * add support for clicking buttons in cy.clickThrough * Cypress test which verifies that dashboards with safe queries can be shared * Cypress test which verifies that dashboards with unsafe queries can't be shared * remove duplicate tests * use this.enabled and negate when needed * remove stale comment * add another Cypress test to verify that unauthenticated users have access to public dashboards with parameters * obviously, I commit 'only' the first time I use it * search for query access by query id and not api_key * no need to fetch latest query data as it is loaded by frontend from the textless endpoint * test that queries associated with dashboards are accessible when supplying the dashboard api_key * propagate `isDirty` down to `QueryBasedParameterInput` * go to /api/:id/dropdown while editing a query, since dropdown queries might still not be associated with the parent. see #3711 * show helpful error message if dropdown values cannot be fetched * use backticks instead of line concatenation * remove requirement to have direct access to dropdown query in order validate it. parent query association checks are sufficient * remove isDirty-based implementation and allow dropdown queries through nested ACL even if they aren't associated yet (given that the user has _direct_ access to the dropdown query) * fix tests to cover all cases for /api/queries/:id/dropdowns/:id * fix indentation * require access to the query, not the data source * resolve dashboard user by query id * apply new copy to Cypress tests * if only something would have prevented me from commiting an 'only' call 🤔 * very important handling of whitespace * respond to parameter's Apply button * text widgets are safe for sharing * remove redundant event * add a safety check that object has dashboard_api_keys before calling it * supply a parameter value for text parameters to have it show up * add parameter values for date and datetime * use the current year and month to avoid pagination * use Cypress.moment() instead of preinstalled moment() * explicitly create parameters * refresh query data if a querystring parameter is provided * avoid sending a data_source_id - it's only relevant to unsaved queries, since a saved query's data_source is available in the backend * remove empty query text workaround * provide default value to parameter * add a few more dashboard sharing specs * lint * wait for DynamicTable to appear to reveal that actual results are displaying * override error message for unsafely shared widgets
harveyrendell
pushed a commit
to pushpay/redash
that referenced
this issue
Nov 14, 2019
…ash#3716) * propagate `isDirty` down to `QueryBasedParameterInput` * go to /api/:id/dropdown while editing a query, since dropdown queries might still not be associated with the parent. see getredash#3711 * show helpful error message if dropdown values cannot be fetched * use backticks instead of line concatenation * remove requirement to have direct access to dropdown query in order validate it. parent query association checks are sufficient * remove isDirty-based implementation and allow dropdown queries through nested ACL even if they aren't associated yet (given that the user has _direct_ access to the dropdown query) * fix tests to cover all cases for /api/queries/:id/dropdowns/:id * fix indentation * require access to the query, not the data source * use require_access instead of has_access
harveyrendell
pushed a commit
to pushpay/redash
that referenced
this issue
Nov 14, 2019
* change has_access and require_access signatures to work with the objects that require access, instead of their groups * use the textless endpoint (/api/queries/:id/results) for pristine queriest * Revert "use the textless endpoint (/api/queries/:id/results) for pristine" This reverts commit cd2cee7. * go to textless /api/queries/:id/results by default * change `run_query`'s signature to accept a ParameterizedQuery instead of constructing it inside * raise HTTP 400 when receiving invalid parameter values. Fixes getredash#3394 * enqueue jobs for ApiUsers * rename `id` to `user_id` * support executing queries using Query api_keys by instantiating an ApiUser that would be able to execute the specific query * show deprecation messages for ALLOW_PARAMETERS_IN_EMBEDS. Also, move other message (email not verified) to use the same mechanism * add link to forum message regarding embed deprecation * change API to /api/queries/:id/dropdowns/:dropdown_id * split to 2 different dropdown endpoints and implement the second * add test cases for /api/queries/:id/dropdowns/:id * use new /dropdowns endpoint in frontend * first e2e test for sharing embeds * Pleasing the CodeClimate overlords * All glory to CodeClimate * remove residues from bad rebase * add query id and data source id to serialized public dashboards * add global parameters directive to public dashboards page * allow access to a query by the api_key of the dashboard which includes it * rename `object` to `obj` * simplify permission tests once `has_access` accepts groups * support global parameters for public dashboards * change has_access and require_access signatures to work with the objects that require access, instead of their groups * rename `object` to `obj` * simplify permission tests once `has_access` accepts groups * no need to log `is_api_key` * send parameters to public dashboard page * allow access to a query by the api_key of the dashboard which includes it * disable sharing if dashboard is associated with unsafe queries * remove cypress test added in the wrong place due to a faulty rebase * add support for clicking buttons in cy.clickThrough * Cypress test which verifies that dashboards with safe queries can be shared * Cypress test which verifies that dashboards with unsafe queries can't be shared * remove duplicate tests * use this.enabled and negate when needed * remove stale comment * add another Cypress test to verify that unauthenticated users have access to public dashboards with parameters * obviously, I commit 'only' the first time I use it * search for query access by query id and not api_key * no need to fetch latest query data as it is loaded by frontend from the textless endpoint * test that queries associated with dashboards are accessible when supplying the dashboard api_key * propagate `isDirty` down to `QueryBasedParameterInput` * go to /api/:id/dropdown while editing a query, since dropdown queries might still not be associated with the parent. see getredash#3711 * show helpful error message if dropdown values cannot be fetched * use backticks instead of line concatenation * remove requirement to have direct access to dropdown query in order validate it. parent query association checks are sufficient * remove isDirty-based implementation and allow dropdown queries through nested ACL even if they aren't associated yet (given that the user has _direct_ access to the dropdown query) * fix tests to cover all cases for /api/queries/:id/dropdowns/:id * fix indentation * require access to the query, not the data source * resolve dashboard user by query id * apply new copy to Cypress tests * if only something would have prevented me from commiting an 'only' call 🤔 * very important handling of whitespace * respond to parameter's Apply button * text widgets are safe for sharing * remove redundant event * add a safety check that object has dashboard_api_keys before calling it * supply a parameter value for text parameters to have it show up * add parameter values for date and datetime * use the current year and month to avoid pagination * use Cypress.moment() instead of preinstalled moment() * explicitly create parameters * refresh query data if a querystring parameter is provided * avoid sending a data_source_id - it's only relevant to unsaved queries, since a saved query's data_source is available in the backend * remove empty query text workaround * provide default value to parameter * add a few more dashboard sharing specs * lint * wait for DynamicTable to appear to reveal that actual results are displaying * override error message for unsafely shared widgets
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue Summary
On a new query, query-based dropdown parameters get their values from
/api/queries/:id/dropdown
and on saved queries they get them by association from their parent query id (/api/queries/:parent_id/dropdowns/:id
).When adding a query-based dropdown parameter to a saved query, the association is not yet created which results in a 403.
Steps to Reproduce
The text was updated successfully, but these errors were encountered: