We have stumbled across a bug that I can only assume is a bug with the JSON API code. This is for the old laravel JSON API (in my composer.json file its "cloudcreativity/laravel-json-api": "^2.0")
The issue is when a resource is included multiple times (in different ways), it is possible to not get all the include information you asked for.
In my example, I am dealing with timesheets. Timesheets belong to a user. They are also approved by a user. Those users are usually different users, but not always. If I want to include both, I would add include=user,approved-by, and this works great.
The front end also sometimes needs to know the employeeType of the user, so we instead use include=user.employee-type,approved-by, and again this works, we get the employee type info for the user. The issue arises when the user is the same as the approver. It appears that JSON-API gets the approved-by user (without the employee type include data), then when it tries to get the timesheet user, it sees that is has already grabbed that user, and just stops there.
The difference in the output is:
The include with the related in
"employeeType": {
"data": {
"type": "employee-types",
"id": "1"
},
"links": {
"self": "link url",
"related": "link url"
}
},
Vs the include without all the related info
"employeeType": {
"links": {
"self": "link url",
"related": "link url"
}
},
We have a work around, where we need to include the employee type of the user and a the approver, but that seems cumbersome and annoying.
I was wondering if anyone knows if there is any good fix for this? Or if this has been fixed in the more recent version (could be the kick in the pants we need to actually migrate to the most recent version of the library)
Related
In polkadot-js has provided for developer to define custom types in the pallet, so that polkadot-ui can understand those types (it means can use some underlying API polkadot-js). These types are defined using the json format. This is example
{
"TransactionInput": {
"parent_output": "Hash",
"signature": "Signature"
},
"TransactionOutput": {
"value": "u128",
"pubkey": "Hash",
"sale": "u32"
},
"Transaction": {
"inputs": "Vec<TransactionInput>",
"outputs": "Vec<TransactionOutput>"
}
}
I see that in substrate-node-template/scripts has aggregrate_types.js file that generate types.json. I dont know how to generate it automaticly or I should write by hand.
Example that, in my pallet that i have defined enum RoleID and struct Role. But in UI it doesn't understand what RoleID is. Can you explain more clearly? I believe that it can be related to define types.json.
https://github.com/polkadot-js/apps/blob/master/packages/page-settings/src/md/basics.md#developer
aggregrate_types.json:
Thanks!!!
Presently, generating this by hand is the best way following the docs here. There are not clean ways to automatically generate this to my knowlage, but soon you will not need to worry about at all it once this PR lands in Substrate!
Thanks to https://github.com/paritytech/substrate/pull/8615, you don't have to manually write types.json anymore.
Make sure the metadata version of your node is v14 or higher. Otherwise you need to upgrade your substrate version to make it automagically work for you.
When developing a message extension for Microsoft Teams, is it possible to retrieve the ID of a team where the user is invoking the message extension command without first adding the bot to that team?
I can do this when the bot is added to the team manually based on TeamsInfo.getTeamDetails(), however, I don't really need (or want) to add the bot to the team for my goal. All I need is the channel ID (which is available from the context/conversation) and the ID of the underlying team. Retrieving the team details without the bot being added beforehand errors with "The bot is not part of the conversation roster".
Have a look at the ChannelData property on the Activity class, that should give what you need. You can read more about it here.
Here's an example of the underlying payload, for interest:
"channelData": { "eventType": "channelCreated", "tenant": { "id": "72f988bf-86f1-41af-91ab-2d7cd011db47" }, "channel": { "id": "19:693ecdb923ac4458a5c23661b505fc84#thread.skype", "name": "My New Channel" }, "team": { "id": "19:693ecdb923ac4458a5c23661b505fc84#thread.skype" } }
we had the same trouble with the Team documentation and APIs.
However for that specific case, we found a solution that may work for you. I will say is more a hack than a solution. But it worked on my use case. It will only work on messages with attachments.
When the context is received in a message, the message contains an attachments array. Each attachment object has a contentUrl. Inside that url is the mailNickname for the group. That mailNickname field represents a readeable unique id. The format is something like sites/{mailNickname}/General.
from there you can retrieve the field and use the Groups Graph API.
With a query like this one:
https://graph.microsoft.com/v1.0/groups?$filter=startswith(mailNickname, 'themailNicknameFromcontenturl')
You will get the group full information, including the aadGroupId
In general, is a nightmare to work with Teams documentation. Hope this hack helps you.
I'm currently working on a project in which we perform "Nearby" queries for places using keywords, and then we make follow-up "Detail" requests to obtain more information about specific places of interest.
With Google's new pricing model in the works, the documentation warns about the cost of the Nearby search, but the warning seems to imply that the follow-up detail request will no longer be necessary because our original search should give us everything we need:
By default, when a user selects a place, Nearby Search returns all of
the available data fields for the selected place, and you will be
billed accordingly. There is no way to constrain Nearby Search
requests to only return specific fields. To keep from requesting (and
paying for) data that you don't need, use a Find Place request
instead.
However, I'm not seeing this. When I run a sample request, the results from my Nearby request contains only minimal data related to the places Google finds. To get details, I still have to do a follow-up detail request.
Does anyone know if there's something I may be overlooking? I'm including my request URL (sans API key).
https://maps.googleapis.com/maps/api/place/nearbysearch/json?key=xxxxxxxxxx&location=30.7329,-88.081987&radius=5000&keyword=insurance
And this is an example of one of the results I received:
{
"geometry": {
"location": {
"lat": 30.69254,
"lng": -88.0443999
},
"viewport": {
"northeast": {
"lat": 30.69387672989272,
"lng": -88.04309162010728
},
"southwest": {
"lat": 30.69117707010728,
"lng": -88.04579127989273
}
}
},
"icon": "https://maps.gstatic.com/mapfiles/place_api/icons/generic_business-71.png",
"id": "53744cdc03f8a9726593a767424b14f7f8f86049",
"name": "Ann M Hartwell - Aflac Insurance Agent",
"place_id": "ChIJj29KxNZPmogRJovoXjMDpQI",
"plus_code": {
"compound_code": "MXV4+26 Mobile, Alabama",
"global_code": "862HMXV4+26"
},
"reference": "CmRbAAAAcHM1P7KgNiZgVOm1pWojLto9Bqx96h2BkA-IyfN5oAz1-OICsRXiZOgwmwHb-eX7z679eFjpzPzey0brgect1UMsAiyawKpb5NLlgr_Pk8wBJpagRcKQF1VSvEm7Nq6CEhCfR0pM5wiiwpqAE1eE6eCRGhQPJfQWcWllOVQ5e1yVpZYbCsD01w",
"scope": "GOOGLE",
"types": [
"insurance_agency",
"point_of_interest",
"establishment"
],
"vicinity": "70 N Joachim St, Mobile"
}
I thought about deleting this question, but I guess I'll leave it up in case anyone else is confused like I was.
It turns out the extra detail fields I was looking for in the Nearby Search results were there...sort of.
Google's new pricing model categorizes place data fields into three tiers: Basic, Contact, and Atmosphere (Basic data is free, but the other two add to the cost).
As part of these changes, Place API calls have been expanded to allow users to specify the data fields they want so that they don't have to pay for that extra data if they don't need it.
The Nearby Search query, as per the note in the question, includes all the data fields available, and doesn't support a parameter for controlling the data -- it's always going return data that falls into the [Basic + Contact + Atmosphere] bucket.
So far, that's all well and good.
Where things became confusing to me, though, is the specifics of what is included in the different data tiers. I skimmed through these notes several times before I noticed the contents were different.
This is how the fields break down with the Places details request:
Basic
The Basic category includes the following fields: address_component,
adr_address, alt_id, formatted_address, geometry, icon, id, name,
permanently_closed, photo, place_id, plus_code, scope, type, url,
utc_offset, vicinity
Contact
The Contact category includes the following fields:
formatted_phone_number, international_phone_number, opening_hours,
website
Atmosphere
The Atmosphere category includes the following fields: price_level,
rating, review
And this is how it looks for the Places search request:
Basic
The Basic category includes the following fields: formatted_address,
geometry, icon, id, name, permanently_closed, photos, place_id,
plus_code, scope, types
Contact
The Contact category includes the following field: opening_hours
(Place Search returns only open_now; use a Place Details request to
get the full opening_hours results). Atmosphere
The Atmosphere category includes the following fields: price_level,
rating
I haven't found documentation for it, specifically, but the results from a Nearby Search request seems close (but not identical) to the Place search (including Contact and Atmosphere).
I had originally thought the fact that Nearby Search results now include Contact and Atmosphere data (when available), that meant it would contain all the fields itemized as Contact and Atmosphere data in the Place details documentation, but that's not the case.
As our team ( namely myself and two other developers ) spiked on PACT past week or so, one of the areas of concern is not having the ability associate parameters to provider states. The absence of this key feature ( which is slated for version 3 release ), we likely will not get buy in from each of our respective service sub-teams.
#MattFellows - Any projections on when version 3 might be available for Go? Any chance we can get this feature earlier?
Allow multiple provider states with parameters
In previous versions, provider states are defined as a descriptive string. There is no way to infer the data required for the state without encoding the values into the description.
{
"providerState": "an alligator with the given name Mary exists and the user Fred is logged in"
}
The change would be:
{
"providerStates": [
{
"name": "an alligator with the given name exists",
"params": {"name" : "Mary"}
}, {
"name": "the user is logged in",
"params" : { "username" : "Fred"}
}
]
}
You are correct in that it won't be available until version 3.
You can still achieve what you are after, however. The state itself is just a handle for the Consumer to some set of data on the Provider - that can be a one-to-one or one-to-many mapping - it's completely up to you.
Typically the Provider is notified of the state during verification, it will then setup a test data fixture (often seeding a database) that sets up the 'state' of the entire system based on that reference, which allows the Consumer test to run.
Whilst the ability to pass through parameters and multiple states is nice, it's somewhat an advanced feature and I very much doubt this will be the first problem you run into as a team. I've never needed to use them myself.
For a crude but effective example of this, take a look at the gin code in the examples folder of the project.
We have an internal database ID for each course we have. When using the batch function to create courses, the returned information doesn’t not give us any way to get this ID back so we cannot update our database and let it know that the course has been created.
Also updating the deletion response for the same reason would also be handy.
The response for a batch of deletes looks like:
--batch_123456
{}
--batch_123456
--batch_123456
{}
--batch_123456
--batch_123456
{}
--batch_123456
If they are all successful then it's not really a problem, but if something goes wrong then it's impossible to tell which ones were deleted and which ones were not deleted, because according to the API:
" The server may perform your calls in any order. Don't count on their being executed in the order in which you specified them."
A simple message that said "course #123 has been deleted" would be very helpful. That way I could program the callback code to update the database using the ID
For the course creation the response looks like:
--batch_123456
{
"id": "208571459",
"name": "***",
"section": "***",
"ownerId": "123456",
"creationTime": "2015-09-14T13:13:59.622Z",
"updateTime": "2015-09-14T13:14:02.820Z",
"enrollmentCode": "***",
"courseState": "PROVISIONED",
"alternateLink": "***"
}
--batch_123456
I only put in one response to save space. The ID is the new GoogleID of the course, the ID we actually send in which corresponds to the records in our DB does not get returned. So we have to use a combination of other data (ownerID + name) to get the record and update it, but this is not ideal and may not work fro everyone. Again adding in all of the information that get's sent into the response would be very helpful so we can use the callback properly.
I also want to add the more useful specific information should also be added to all error messages. In fact every batch response should have some sort of ID, that way the callback functions can be more useful.
As mentioned briefly in the documentation, you can pass an alias into Courses.id when creating a course to assign an alias to a course as you create it. The alias can include your internal identifier for the course and can be used in future requests.
Alternatively, each request in a batch can be assigned a unique Content-ID header, which will be returned in the response. Many client libraries provide built-in support for setting and getting these IDs.