when getting back references from Yammer through the dev api, they can be of a few different types. Is there any documentation somewhere that describes the JSON model of returned objects?
Right now I have got the following from just reading the returned JSON.
Type:
- "user"
- "guide"
- "group"
- "thread"
- "topic"
But there could be other types I'm not expecting which could be sent in the future. Is there a list somewhere that describes indepth all the possible return types from the Yammer API?
There's not currently any documentation resource that will provide that information. It's also possible for additional reference types to be added later.
To deal with references robustly, you'll need to add code to handle the reference types you know about and do something reasonable for reference types you don't recognize.
The something reasonable may vary, but a good start would be to somehow log the reference and otherwise ignore it.
Related
I am trying to get and set the forwarded/replied state of an email message in the Graph API. This is the represented in OWA by the little icon in the right column.
It seems there is not a first class way to access this information, at least it does not come out in the unfiltered JSON dump.
Google suggests this is stored in the extended properties for PidTagLastVerbExecuted or PidTagIconIndex, however attempts to access these just give back 404:
https://graph.microsoft.com/beta/me/mailFolders/{id}/messages?$select=SingleValueExtendedProperties&$expand=SingleValueExtendedProperties($filter%3Did+eq+'String+0x1081')
Other extended properties like 0x0070 do work, so it seems the syntax is correct, and 0x1081 comes from here https://learn.microsoft.com/en-us/office/client-developer/outlook/mapi/pidtaglastverbexecuted-canonical-property
This information is stored, you can see it in OWA, the Outlook apps, and you can see it in IMAP.
Is there some way to do this? It seems strange this basic information about the email state is not made available.
Your specifying the wrong datatype that property is defined as a Long in the documentation (but the doco is for MAPI) so its actually an Integer in EWS and Graph eg this is something i used to return both PidTagLastVerbExecuted and PidTagLastVerbExecutedTime (which gives you the time of the last action)for a particular message
/v1.0/users('user#domaincom')/MailFolders/AllItems/messages/?$select=ReceivedDateTime,Sender,Subject,IsRead,inferenceClassification,InternetMessageId,parentFolderId,hasAttachments,webLink,InternetMessageHeaders&$Top=1000&$filter=internetMessageId+eq+%27%3cSG2PR04MB3223962312D5B46D0C9CA1B5C89C0%40SG2PR04MB3223.apcprd04.prod.outlook.com%3e%27&$expand=SingleValueExtendedProperties($filter=(Id%20eq%20'Integer%200x1081')%20or%20(Id%20eq%20'SystemTime%200x1082'))
Please expand your NgxsFormPluginModule description on gitbook.
I just implemented a reactive forms example with #ngxs/form-plugin.
It works great, but it was a bit of a struggle to get it to work; because it was not clear to me that the form state must have these specific properties:
model: YourFormModel,
dirty: boolean,
status: string,
errors: {}
Maybe you could add an explanation of these properties and their intended use?
What are the possible values for status, or is this up to the developer to define?
What type of object is errors and what is it used for? It appears to be empty even when validation fails. errors would suggest it is an array, but the example defines the default as an object?
I am posting this as a question because of your answer here: Where is it best to post questions about ngxs?
status field is supposed to store latest status of FormGroup.
You can see the code that is responsible for its update here.
The possible values for status are defined here.
errors is supposed to contain validation errors for the whole form group.
Its type is ValidationErrors since it's supposed to copy errors from the corresponding form group.
The code responsible for its update is supposedly here.
But there's an unsolved issue with filling it with actual error data., so it's not available yet and you'll have to rely on controls' error data.
I'm trying to understand the plug-in sample from here.
There's this condition:
// The InputParameters collection contains all the data passed in the message request.
if (context.InputParameters.Contains("Target") &&
context.InputParameters["Target"] is Entity)
Speaking generally, not just with regard to this sample, on what prior knowledge should I base my decision to access a specific property? How could I have known to test whether the InputParameters contains a "Target" key (I assume I'm not supposed to guess it)?
And on what basis could I have known to ask whether the "Target" mapped value is of Entity type, and not some other type?
I found this post from 2 years ago, and I've found this webpage, saying (emphasis is mine):
Within a plugin, the values in context.InputParameters and
context.OutputParameters depend on the message and the stage that you
register the plugin on. For example, "Target" is present in
InputParameters for the Create and Update messages, but not the
SetState message. Also, OutputParameters only exist in a Post stage,
and not in a Pre stage. There is no single source of documentation
that provides the complete set of InputParameters and OutputParameters
by message and stage.
From my searchings, a single source still doesn't exist, but maybe the possible values can be found using the Dynamics Online platform, somewhere deep down the Settings menu, maybe? Any source would be great.
I know this is an "old" question that already has been answered, but I think this can be helpful. I've built a small web page that contains all the messages with all the Input/Output parameters. You can access it from here:
The best practice for doing this is to use a strongly typed approach. If, for example, you want to know which propertes are available on a CreateRequest, you would do:
var createReq = new CreateRequest() { Parameters = context.InputParameters };
createReq.Target; // Has type Entity
Take a look at the full blog post explaining this approach: Tip: Proper handling of Plugin InputParameters
Original answer:
It depends on which request we are talking about. See Understand the data context passed to a plug-in on MSDN.
As an example, take a look at CreateRequest. One property of
CreateRequest is named Target, which is of type Entity. This is the
entity currently being operated upon by the platform. To access the
data of the entity you would use the name “Target” as the key in the
input parameter collection. You also need to cast the returned
instance.
Note that not all requests contain a Target property that is of type
Entity, so you have to look at each request or response. For example,
DeleteRequest has a Target property, but its type is EntityReference.
In summary: Look at the actual request, e.g the CreateRequest.
In 2011 someone actually generated typed properties based on the message type. Kind of neat: https://xrmpalmer.wordpress.com/2013/05/27/crm2011-plugin-inputparameter-and-outputparameter-helper/
It would show you want parameters are possible per message.
JSON API REST endpoint with permissions-restricted fields
I am working on a JSON API-compliant REST api. Some endpoints contain fields that should be restricted (read-only or not available) for certain users.
What is the best way to architect the api to allow that certain users have access to certain fields, while others do not? By "best", I mean:
Most compliant with REST standards, ideally JSON API standards
Most clarity in terms of preventing bugs and confusion on behalf of clients consuming the API
I am considering the following options, each with their set of concerns/ questions. I would be more than grateful for any other solutions!
Option 1: Return null on restricted fields for users without permissions
Different data values would be returned per-user. Is this strictly anti-REST?
Lack of distinction between null meaning "null value" and null meaning "You don't have access to this"
In REST/ JSON API architecture, is it okay for an endpoint to return different data per user, based on permissions? I have the impression that this would be contrary to the spirit of resource-based REST architecture, but I could not find anything specific to point to in any doc or standard (e.g. JSON API). Also applies to Option 2.
Is there any paradigm for adding some sort of "You don't have access" flag in the resource's metadata?
Option 2: Exclude restricted fields entirely for users without permissions
Different data values would be returned per-user. Is this strictly anti-REST?
Possibility of "undefined" errors in client, when trying to retrieve field value
Option 3: Move restricted field(s) onto another endpoint, available as an ?include='field_name' relation for those with permission
Example: /api/entity includes attribute field "cost" which is only available to Admin users. Admin users can request cost data via GET /api/entity?include=cost. For all users, "cost" is exposed as a relation in the resource object, with a "type" and "id".
This is the option I am leaning toward. The main con here is endpoint clutter. I have a lot of relations that would need to be made into separate endpoints, simply to support a permissions-quarantined data on an already-existing endpoint.
In the JSON API specs, I am having trouble determining if it's ok for an endpoint to exist as a relation only, e.g. can we have /api/entity/1/cost, but NOT have a top-level api endpoint, /api/cost. My assumption is that if a resource has a "type" (in this case, the relation type being 'cost'), it also has to live on a top-level endpoint.
In this scenario, the client could get a 401: Unauthorized error response if a non-admin user tries to GET /api/entity?include=cost or GET /api/cost/:id
Note: I have already built a separate permissions schema so that the client can determine which CRUD privileges the user has, per top-level endpoint, before making any requests. Permission sets are indexed by resource type.
Any help on the matter would be very much appreciated! And if anything needs to be clarified, feel free to ask.
I would definitely not use undefined or null to indicate fields that the user is not allowed to see. To me, that feels like a lie and represents that the data is really not there. They would have to really know your API in order to get a grasp of what is really going on.
I would recommend something more like your 3rd option, except I would make it a different endpoint altogether. So in your example, the endpoints would be:
/api/entity/1/cost
and for admins
/api/admin/entity/1/cost
or something like that.
This way your server code for the admin endpoint could just be focused on authenticating this admin user and getting them back all the fields that they have visibility on. If a non admin user tries to hit that route, reject them with an unauthorized status code.
I'm not saying that you should not implement the GET param to be able to specify fields as well. You can if you want to, but I don't think it just won't be necessary in this case.
I'm building a FHIR client in .NET using the test server in the following request: http://argonaut.healthintersections.com.au/open/Patient?family=Doe&given=John. I am able to successfully return and parse JSON response for an existing test patient. My use case: Now that I know that my patient of interest exists I want to return problems/medications/immunizations for the patient.
Can someone please tell me how I can turn around the patient information (presumably patient id) received in the JSON response and request all medications or immunizations or problems for said patient? I've tried quite a few ways based on my interpretation of the documentation (trying to leverage resource type of StructuredDefinition defined in the specification, but I cannot seem to get it right. Excerpt from the JSON response showing patient id returned from server:
"entry":[
{
"resource":{
"resourceType":"Patient",
"id":"4705152-patient",
"meta":{
"versionId":"1",
"lastUpdated":"2015-05-04T13:41:19Z"
},
Thank you
Two different answers, depending how you want to go about it. If you want to get a dump of the whole patient record, you can do this:
http://argonaut.healthintersections.com.au/open/Patient/475152-patient/$everything. That will give you Lists, Conditions, Allergies, Medications, etc. - everything in the patient compartment for that patient. (You can filter by "since" and a couple of other parameters).
You can also go after the resources individually:
http://argonaut.healthintersections.com.au/open/Condition?patient=475152-patient
Side-note: I just queried the healthintersections argonaut server for the patient id you specified in your example and didn't find it, so I tested my queries using patient "1".
You'll need to be authorized via OAuth in order to get this data back
EDIT: Updated to reflect that non-availability is due to lack of OAuth authentication, not Argonaut intention
You could also use _revinclude to directly include these associated resources in the query response. See the search specification page.