I currently have a workshop module that allows users to view a set of objects and then filter them according to a filter widget.
I would like my users to be able to set which filters are applied via URL such that they can quickly apply their default filters.
How can I achieve this?
Create a variable for each filter you would like the user to be able to apply via URL.
Promote the variable so that it can be update via the URL.
Update the filter output to use the variables you created above.
In addition to using the promoted variables described in the answer above, specifically for the case of saving and re-using Filter state, you can enable the State Saving feature for users of your app, which allows them to snapshot and save specific application state as a separate Foundry resource. You can then share the link or bookmark or re-open from a folder without worrying about the "wiring" of variables and URL parameters.
Related
I know how to use input widget in Slate but I have a use case where I need to create several inputs from an array. Maybe one, maybe more, let's say around 10 or 15. Is that possible to create a input and to catch the user entry just by using an HTML widget.
One other way to say shoud be: I would like to have a table of 1 to 15 rows with one column dedicated to an input area. Number of row depend of the source data, so I want that the input is created dynamically. Is it possible in foundry-slate ?
Best regards
You can't do this in a plain HTML widget - the dependency graph can't read state from arbitrary HTML input elements.
There are a couple other options here; the one that most directly works they way you would like it to in your question, would be to use the Code Sandbox widget, which effectively let's you build your own widget and wire it up to the Slate dependency graph for interaction with the rest of the app. You can use a 3rd-party library, assuming you have the license, to do something more advanced (you can search your Foundry instance for some examples in the Slate Reference Examples) or simply use HTML and Javascript to build the widget as you would in normal web development as you have access to the DOM and JQuery when working in the Sandbox.
Slightly more in-line with how Slate might expect you to build this functionality, you can use a single input widget, but toggle what you do with the associated input based on other state, for example what row the user has selected. This, in combination with a button that stores the input into a Variable with a click event, can be used to let users build up a "bag" of edits, that you can then apply with Actions (or you can apply them immediately - all depends on the workflow). You'll find some examples of that pattern in the "Events" folder in the Slate Reference Examples.
Thinking a bit more expansively, if you model your data in the ontology, you can set up an editable table pattern in Workshop and have a quite straightforward experience once you have the right Action and Object Type configuration. You'll find the documentation on this on your Foundry instance at https://www.palantir.com/docs/foundry/workshop/widgets-object-table/#inline-edits-or-cell-level-writeback and an example in the Flight Alert Inbox example application.
I've created a scenario in Foundry Workshop, and would like to set it up so that it resets whenever a user changes their active Workshop tab. Is it possible to accomplish this within scenario variables?
If the scenario array variable is produced from a scenario object set, then changing the object set should reset it. See the relevant documentation for this at https://www.palantir.com/docs/foundry/workshop/scenarios-save/ .
If you have a single dynamic scenario that you'd like to reset, then you can use the "Reset variable" event to reset it to its default value.
We are currently using a generic report which will be used differently by multiple usergroups. We have made this possible by creating linked reports with different settings of hidden parameters (such as 'show column x', 'enable feature y').
These settings (parameters) are needed on other reports as well, so we pass them along using the Go to ... Action.
To create the look and feel we are after, we are passing some additional parameters as well, HTML Viewer commands and Report Server commands such as &rc:Parameters=False (reference).
Unfortunately, this leaves us with only the option Go to URL, since Microsoft hasn't implemented these commands for Go to Report. This means we have to pass our settings (the hidden parameters) along in the URL. This results in a security issue, example given: &PARAMETER_ENABLE_FEATURE_Y=False.
The user might notice this parameter in the URL and is so given the possibility to enable this function by editing the URL to &PARAMETER_ENABLE_FEATURE_Y=True.
So my question is: how to use an Action in Reporting Services while preventing users from editing our sensitive parameters and while being able to use HTML Viewer commands and Report Server commands?
You will never get complete security in this sense if you absolutely have to use URL based parameters.
When navigating via the URL, the only way you can hide parameter values without hard coding them is to make them data driven. In your scenario however this will not be 100% secure as you will still need to pass the value that populates your data driven parameters.
This level of obfuscation is probably enough and can be achieved by collating a list of either every parameter combination or just the ones your need and assigning it an ID that you can call in a dataset. This can obviously still be changed by your users should they get curious and can be a faff to maintain.
I would say your only other option is to hide the URL bar completely by providing a 'landing page' for your reporting and displaying everything in an iframe. This frame can be targeted with a javascript link in your Go To URL:
="javascript:void(window.open('URL to open','iFrame Name'))"
If you are able to though, I would advise you group your users into Active Directory security groups and then maintain a collection of permissions and customisations per group. You can then check which groups a user is a part of using custom code similar to the answers here and return the required parameter values accordingly.
Doing things this way will also enable you to maintain which groups can see what from a central location, assuming you have rolled out the same parameter structure across all reports.
I have successfully added a data set for the CKAN site. It enables to preview the data set as well.
Below is the URL for the data set
testckan.com:5000/dataset/my-data1/resource/4c2647ca-a4ab-4d20-8119-5c3da9d4ae14
By adding api/rest/ to the URL as below enables to expose data sets as a JSON service.
testckan.com:5000/api/rest/dataset/my-data1/resource/4c2647ca-a4ab-4d20-8119-5c3da9d4ae14
All I want to do is add an button so that user can view the data set as a JSON rather than typing it in the URL which is not user friendly.
I have seen similar button in the
http://data.gov.uk/dataset/bona-vacantia-estates-advertisements
under API & APPS. Please see the image below.
How to enable API button for CKAN data set like above?
You will have to modify the front-end templating for the package (aka dataset) view. You can either add this change to your own copy of CKAN source code, or like Hendrik mentioned and data.gov.uk people have done, create a CKAN extension to modify the templates.
Your example of the feature is implemented for the data.gov.uk site which is open source and available in GitHub. The specific part is in the read_common.html:
<b>API: </b><a href="${h.url_for(controller='api', register='package', action='show', id=c.pkg.name, ver='2')}">
${h.url_for(controller='api', register='package', action='show', id=c.pkg.name, ver='2')}
</a>
The url_for function is from the ckan.lib.helpers module which "is available for templates as 'h'" according to the CKAN docs, so you should be able to use it directly in the template as in the code above.
AFAIK that's no feature of CKAN itself, thus it can not be enabled. You can, however, easily add it yourself in an extension.
I want to display the full username in my SSRS report. I used =User!UserID which gives domain\login.
Can I get the full name of the user like Tom,Cruise, instead of abc\tcruise.
The global variable you mentioned (User!UserID) is the only relevant built in variable, if you look at the built-in globals on MSDN, so I think you may have already answered your own question.
Some alternatives from the top of my head:
If you're running the report in your own app using the ReportViewer, you could use a hidden parameter and have the app pass the full user name.
A more heavy weight alternative you could try is using custom (embedded) code or assembly references, that may give you access to this info (not 100% sure though).