I need to get only those SmartCollections that are imitating some kind of category of products e.g. Pants, Shirts, Shoes. But there is also collections like "All Products" or "Available on local store". What I need to get via API are only those spesific categories and nothing else.
So is there any way to set some kind of metafield or alternative to SmartCollections so I could filter via API only collections I need?
Of course one(and really bad) way to do this is to hard code list of not wanted collections, but this solution isn't very dynamic :/
I am using this package froatsnook:shopify from atmospherejs.com.
Here is Shopify's API documentation about SmartCollections: SmartCollection
Okay, I managed to do this eventhough API disagrees with me. With this Chrome extension you can use metafields also with SmartCollections: http://shopifyfd.com/
And then you just have to create new function for this new endpoint via build in functionality provided by froatsnook:shopify like this:
Shopify.API.define({
"name": "getSmartCollectionMetafieldsById",
"method": "GET",
"path": "/admin/smart_collections/#{collection_id}/metafields.json",
"returns": "metafields",
"description": "Get a single smart_collection metafields by its ID"
});
And voilá! Now you can include/exclude SmartCollections via API by using metafields!
Related
In azure when adding a user, group, or service principle to a role you can search by name and email address in the same search (screenshot below). When I look at the MS Graph APIs there are separate APIs for users, groups, and service principles (MS Graph API documentation links below). And it looks like the search options cannot be mixed (just display name or just email).
Does anyone know how to achieve a search like this using an Azure REST API. I'm curious if anyone knows what calls Azure is actually doing and if they are part of the published rest API? Or if one search is combining like multiple API calls which would be confusing since are paginated that would be hard to figure out what to display from which....
I'm building an app to add permissions and I'm trying to recreate a feature like this search.
Only way I can think of to achieve this now would be to select an option to search for either 'groups', 'users', or 'service principles'. Then another options to select search by 'email' or search by 'displayName' (but not both as the same search). This seems more clunky but technically ok.... but I'd rather do it like the azure screenshot below.
https://learn.microsoft.com/en-us/graph/api/user-list?view=graph-rest-1.0&tabs=http
https://learn.microsoft.com/en-us/graph/api/group-list?view=graph-rest-1.0&tabs=http
https://learn.microsoft.com/en-us/graph/api/serviceprincipal-list?view=graph-rest-1.0&tabs=http
Microsoft Graph API provides batching functionality where you can batch multiple requests together and send them as a single request for processing. In your case, on the server-side (Graph API side) three requests will be processed but from your application you will be sending a single request and get a single response.
Your request would be something like:
{
"requests": [
{
"id": "1",
"method": "GET",
"url": "/users?$filter=<your-filter-criteria>"
},
{
"id": "2",
"method": "GET",
"url": "/groups?$filter=<your-filter-criteria>"
},
{
"id": "3",
"method": "GET",
"url": "/servicePrincipals?$filter=<your-filter-criteria>"
}
]
}
You can learn more about the batching capability in Microsoft Graph API here: https://learn.microsoft.com/en-us/graph/json-batching.
So the batching answer was not exactly what I wanted but something really cool that I'll likely end up using in the future!
Since batching could get ugly with the paging results since say I want 30 total results (so i set paging to 10,10,10) then if one gives 10 and has nextlink and the next gives 0 and the last give 5. I now have 15 results to display but paging with the other and the sorting of results after the next could throw results earlier. It might just be weird and I don't have time to think it through.
I just ended up doing a drop down for users, groups, and service principals. And you have to search separate. Not as cool as how MS does it internally but its consistent, predictable, and works.
I have a chrome extension where the user can make purchases using Chrome webstore.
Numerous Google pages refer to https://developer.chrome.com/webstore/check_for_payment.html . Which is dead and nowhere to be found. Great!
I am trying to find out how to get a list of all purchases of all users from the webstore, preferably using PHP or even by pure REST by using Postman or similar?
Any help appreciated!!
Here is the link learn more about the Payments:List
Lists the in-app products that the user has purchased.
If successful, the structure of the response body will be:
[
{
"kind": "chromewebstore#payment",
"itemId": string,
"sku": string,
"createdTime": long,
"state": string
}
]
Parameters are also supplied in the documentation.
The state will identify if the payment is ACTIVE, PAYMENT_DECLINED, EXPIRED, CANCELLED, REJECTED, PENDING, CANCELLED_BY_DEVELOPER, DISABLED.
From there, you will now be able to filter out what data you needed.
Hope this helps.
I'm trying to figure out how to get the route for an HTTP triggered Azure Function within an ARM template.
Thanks to a blog post I managed to find out the listsecret command, but when trying to execute this action via powershell, the output doesn't give me the trigger_url I was expecting. The URL does not comply with the configured route of the function, and shows the default trigger if no route would have been configured.
Any way I can get a hold of the configured route instead since I can't seem to use the trigger_url.
My configured route has got parameters in the path as well, e.g.:
{
"name": "req",
"type": "httpTrigger",
"direction": "in",
"authLevel": "function",
"methods": [
"POST"
],
"route": "method/{userId}/{deviceId}"
}
The output of listsecrets is:
trigger_url: https://functionapp.azurewebsites.net/api/method?code=hostkey
Is there any other way to extract the host key and route?
Try playing with the API version, but I would suspect that this is not possible as of now.
Currently, the only way to get the route is by reading the function.json file and parsing that information out, which you can do by using Kudu's VFS API.
For the keys, I would actually recommend using the key management APIs instead of listSecrets. As the latter is meant to address a small set of scenarios (primarily to enable some internal integrations) where the key management API more robust API and will continue to work with different secret storage providers (e.g. Azure Storage, which is what is used when slots are enabled and will eventually become the default).
My requirement is to clear all activities on a notification feed.
Based on this stackoverflow question I understand that there is an undocumented REST API to delete a feed and the dashboard truncate feed functionality uses it.
I tried to replicate the call with the same parameters as dashboard:
DELETE /api/v1.0/feed/notification/f8fa1d12-594a-4b2b-ac58-23c912d1335a/?api_key=...&location=unspecified
Host: api.getstream.io
Authorization: notificationf8fa1d12-xxxx-xxxx-xxxx-23c912d1335a writetoken
stream-auth-type: simple
X-Stream-Client: stream-javascript-client-browser-unknown
Cache-Control: no-cache
Tried to use the same but am getting this error message:
{
"code": null,
"detail": "url signature missing or invalid",
"duration": "6ms",
"exception": "AuthenticationFailed",
"status_code": 403
}
Is this the right way to use this API?
I am using this from Java code and believe that the Java client doesn't have this functionality built in.
There's two ways to do this. You can do it manually from the explorer on the dashboard. Search for the feed, select an activity and press the truncate feed button. This is the easiest way to do this if manually doing this is sufficient.
It's also possible like you found to use the delete API endpoint to do it programmatically. This endpoint is not built in to most clients, including the Java client. The URL and HTTP verb that you used should indeed work.
From what I can tell from your headers and the response it seems like you are having an issue with supplying a correct signature. The easiest way to do this correctly is to use the built in methods in the library you're using to generate them. I'm not an expert in the Java library, but it seems like these methods are inside the StreamRepoUtils class.
How do you update a SharePoint 2013 wiki page using the REST API?
Three permutations:
Reading an existing page (content only)
Updating an existing page
Creating a new page
For reading an existing page, of course I can just to a "GET" of the correct URL, but this also brings down all the various decorations around the actual data on the wiki page-- rather than fish that out myself, it would be better if there was a way to just get the content if that is possible.
Are there special endpoints is the REST API that allow for any of these three operations on wiki pages?
As stated in GMasucci's post, there does not appear to be a clean or obvious way of instantiating pages through the REST API.
You can call the AddWikiPage method from the SOAP service at http://[site]/_vti_bin/Lists.asmx. This is an out of the box service that will be accessible unless it has been specifically locked down for whatever reason.
To read the content of a wiki page through the REST API, you can use the following endpoint:
https://[siteurl]/_vti_bin/client.svc/Web/GetFileByServerRelativeUrl('/page/to/wikipage.aspx')/ListItemAllFields
The content is contained within the WikiContent field. You may want to add a select to that URL and return it as JSON to reduce the amount of data getting passed over if that is a concern.
As for updating the content of an existing wiki page, it is not something I have tried but I would imagine it's just like populating another field through the REST API. This is how I would expect to do it:
Do a HTTP POST to the same endpoint as above
Use the following HTTP headers:
Cookie = "yourauthcookie"
Content-Type = "application/json;odata=verbose"
X-RequestDigest = "yourformdigest"
X-HTTP-Method, "MERGE"
If-Match = "etag value from entry node, returned from a GET to the above endpoint"
Post the following JSON body
{
"__metadata": { "type": "SP.Data.SitePagesItem" },
"WikiField" : "HTML entity coded wiki content goes here"
}
The interim answer I have found is to not utilise REST, as it appears to not be
fully documented
fully featured
supported across Sharepoint 2013 and On-line in the same way
So my current recommendation would be to utilise the SOAP services to achieve the same, as these are more documented and easily accessible.