I am using a filter to apply object level permissions to a collection. Resources in a second collection have a many-to-many relationship with the first. On the browsable API, when creating resources in the second collection, the user is presented with a list of resources from the first to link it to. However, this list is not filtered, so the user can see values that they should not be able to see.
I've poked around the documentation and source a bit and I cannot see a way to add filtering to the queryset that generates the choices without overloading or modifying a bunch of code to pass the request data down (probably removing some of the collection specific data on the way) and then apply the filters.
Is there a better way to achieve this?
Currently there's nothing to support this out of the box. Pull requests are always welcome. If it's something you want to work on you may want to either open a ticket on GitHub or hit up the mailing list to discuss it first.
Related
lets imagine that we have 2 independent data collections:
menu (contains labels + links [])
posts (contains text [])
By default Strapi gives me 2 endpoints, one for menu and another for posts. That's fine, but how I can combine this two (or even 10+ small data collections) in one Strapi REST API response?
I'm new to Strapi so need most simple and effective solution. I know that possible to make a custom endpoint but in this case I should manually add/remove any collections inside Strapi config - think its not a true way.
Thank you for your time!
You can also create another collection e.g. agg_collection that has relations to both collections so you can retrieve them by calling api/agg_collection?populate=....
Writing a custom endpoint is the preferred solution I suppose, but the question is; do you really need to have it in a single request?
We are running DRF in combination with django filter to narrow down list view results.
As filters and filter options are increasing, we would like the frontend to display only the available (the select-able) filter choices.
Simple example: There are a lot of products but none is green. The frontend should be able to disable/hide the checkbox for green by asking the DRF
More complex example: There are a lot of products and all of the red ones are small. If the user selected the red filter (e.g. frontend calls /products/?color=red) there is no need to bother the user with filters for medium and large.
Currently, we are about to create a custom implementation based on DRF's options method: That is manually checking for available filter choices depending on the current query set and returning this info as the "actions":{ "GET": {...}} dict using e.g. custom metadata.
We could also augment the GET response similar to the pagination API which already adds count, next and previous to the answer.
However, this seems to be a rather common use case (e.g. in online shops) and thus I was wondering if there is a django-filter/DRF-onic way (a best practice) or even a library for that.
I'm using Google Data Studio to visualize results from various queries (from different tables within the same BigQuery-database).
For this reason, I created and use multiple data-sources-connectors. Each one of them has a SQL query included and makes use of an defined input parameter (which can be changed by report editors) - called "userid". It is the same id for all queries and resulting charts.
However, when I click "Manage URL parameters", I'm not allowed to use the same URL parameter for more than one data source (instead they are called ds0, ds1, ds2 etc - although they all end up being used as "userid").
If I add a data source under File - Report Settings, a new field "userid" appears, which I can alter - this will update ALL charts in the report with the very same userid (as expected). This works, but I do want to make use of an url which delivers an report with all updated queries depending on ONE userid.
Therefore, I guess I'm overseeing something - it should be possible to just use one query parameter to update the same "userid" for all queries in all data connectors? Or have I overlooked the possibility to fire multiple queries within one data source connector? Or is it expected to create a looong url full of redundant query parameters in this case?
I'm curious for your input!
Best regards :)
There does not seem to be any good solution for this.
For now the best workaround seems to be to just repeat the parameter multiple times -- it's ugly but it works. For example, use the URL parameter mapping screen to call the parameter u1, u2, etc., and then just pass all of them:
?params={"u1":"foo","u2":"foo"}
(URL encoded of course)
The ugliness is mostly for us developers: it violates our sense of DRY and clean code, and makes the URL much longer than it needs to be. However, most people don't care or know about the URL parameters so its irrelevant to them.
The bigger downside is that when the URL is distributed to clients (bookmarks, mobile apps), every time new data sources are added that require the same URL parameters, a new URL has to be distributed to clients for no good reason. A workaround for this is to build the URL dynamically via a simple redirector function.
This issue https://issuetracker.google.com/issues/180705297 is a feature request to implement this capability.
If you group the elements that you want to control with the same parameter (select and then shift G) then it will give you options to select the data source and the params box to apply to the group.
I store specific custom field for each transaction. I'd like to conduct a search by this field. I wouldn't like to retrieve too many transactions (can filter by payment method id, but still) and iterate through them on application side. So, I read a documentation, didn't find an ability to search by custom field (only by predefined). I didn't try it out, but probably it's possibly to do so by following the same pattern like
var stream = gateway.transaction.search(function (search) {
search.myCustomField().is("custom_field_value");
// or search.customFields.myCustomField().is("custom_field_value");
});
Thanks in advance
I work as a developer for Braintree. Searching on custom fields is not supported at this time. You can see all of the searchable transaction attributes listed here.
If you would like to discuss alternatives, I recommend emailing our support team at support#braintreepayments.com to see if there is another method to achieve what you are trying to do.
I've been having a look at several MVC frameworks (like rails, merb, cakephp, codeignitier, and similars...)
All the samples I've seen are basically plain and simple CRUD pages, carrying all the infr needed in the querystring and the posted field values.
I've got a couple of apps made with some sort of framework built with classic asp.
This framework handles some CRUD stuff a little more complex than the examples I found.
Something like master-detail, filtering by example, paging, sorting and similars.
I have a controller class that it's just a finite state machine, that goes thru diferent states (like new, browse, filter, show, etc.), then performs the appropiate action depending on the event raised and finally retrieves the neede info to the calling page.
To achieve this I have several hidden inputs to keep the state of the web page (like current id, filter criterias, order criterias, previous state, previous event, well, you get the idea)
What do you think would be the finnest approach to achieve this kind of funcionality?
hidden inputs built in the view and used from the controller??? (I guess that would be the equivalent of what I'm doing right now in classi asp)
--
(added in response to tvanfosson)
basically, my question refers to the third category, the context-dependent setting (in respect to the other two categories I agree with you) the info I was storing in hidden fields to store them on the querystring, I guess that when you click on the "next page" you include everything you need to save in the querystring, right? so that piece of query string gets appended in each and every link that performns some kind of action...
I'm not sure, what are the advantages and disadvantages of using the querystring instead of hidden inputs???
I use different strategies depending on the character of the actual data. Things that are preferences, like default page size, I keep in a Preferences object (table) that is associated with the current logged in user and retrieve from there when needed.
Persistent settings associated with the current logon, like filter settings for a page, are stored in the user's session. Generally these are things that if a user sets them in the current session they should remain sticky. I think filter settings and visibility are like this. If I filter a list, navigate away from it to drill down into a particular item, then come back to the list, I want my filter settings to be reapplied -- so I make it part of the session.
Context-dependent settings -- like the current sort column or page number, are controlled using query parameters. Paging and sort controls (links) are built with the appropriate query parameters to "do the right thing" when clicked and pass any necessary query parameters to maintain or update the current context of the control. Using the query parameters allows you to use an HTTP GET, which is bookmarkable, rather than a POST. Using hidden form parameters makes it much harder for the user to save or enter a URL that takes them directly where they want to go. This is probably more useful for sorting than it is for paging, but the principle applies equally.