I believe that the put GradeObject Put api call has a bug when trying to update the ShortName field.
I believe that the ShortName is not being updated (other fields appear updated correctly). The Post new grade object works as expected.
I am receiving a 200 result, and fields are updated as expected, however, the ShortName is not being updated.
The response I receive contains the correct ShortName (ie the one that I passed and would expect D2L to change to), but it's not updated on D2L.
We use the same Grade object to Add (Post) as we do to (Push), so we are interested in your thoughts.
I can confirm that I am using the same spelling and case as documented here: http://docs.valence.desire2learn.com/res/grade.html
I can also confirm that the SAME OBJECT works correctly when 'posting' the object, only put fails to update that field, and it's only that field that doesn't get updated.
Is this a D2L Bug?
Can somebody from D2L or otherwise confirm that updating the Shortname works as expected?
This is a known issue with the Valence Learning Framework API's GradeObject update APIs. It has not yet been addressed.
Currently, there is no way through the APIs to set or update the ShortName property of a grade object.
Related
When calling the Microsoft Graph API to get a specific user, the createdDateTime field is returned without any data.
https://graph.microsoft.com/beta/users/user#domain.com
However, when searching for the user, the field is returned correctly.
https://graph.microsoft.com/beta/users?$filter=startsWith(userPrincipalName, 'user#domain.com')
The bug can be reproduced using the GraphExlorer web-site: https://developer.microsoft.com/en-us/graph/graph-explorer
I'm not sure where to report this, so I posted it here.
I think I might have found the answer.
When I do a GET operation using the Azure AD 'id' the createdDateTime is populated. When I retrieve the same user using the userPrincipalName, the createdDateTime value is returned as null. I suppose the issue is that the value is retrievable by the back-end query when the Azure AD 'id' property is used while the userPrincipalName (which is a mutable/changeable property) is not. Bizarre but at least there seems to be an answer. Hope this helps.
The documentation for resourceVisualization resource type (Trending endpoint) says that one of the properties that gets returned as part of the object is type.
However, when I use Graph Explorer to test the endpoint I don't see this property. Is it going to be added soon?
We have that identified and we are working on updating the API schema to have that property available by the end of next week.
Mario
I've an array of objects containing title and salary which is used in typeahead directive.
I display department name and get entire object as value.
If none of the options match, I want user entered string to be converted to object still. Is there any way to update that?
This answer is pretty late, but I would just use ng-blur (to trap the end of the users input) along with a variable bound to typeahead-no-results. Then test if the variable is true in the method bound to ng-blur, and, if so, make an object out of the String supplied by the user and push it to your data source. Simple example found here.
I am currently creating an MVC application that is currently getting a value from a post from a webhook. I think that the problem is that the application is getting the value from the POST verb but then it is not displaying it because the Get verb is being used to display the View so both Verbs are counter acting each other.
The webhook will fire A Json payload to my application successfully because I have code in it that will send the Json payload in a variable via email to my email account.
Dim body = issue.issue.key
mail.Body = body
That is in a try catch block because in order for it to have a value it must have a value in it and the application will perform the GET first, so there is a null value in the body variable, then it does the POST to get the value but it will not display the value, refreshing will just perform the GET preventing it from being displayed. How can I perform both actions at the same time so I can display a value in a ViewBag for example.
ViewBag.response = status + key
This is the type of structure that I would like to implement to try and fix the error but I do not know how to complete all of the steps:
This is what I have got so far:
The POST is coming in from a webhook and I am reading it like this.
Dim reader As System.IO.StreamReader = New System.IO.StreamReader(HttpContext.Request.InputStream)
Dim rawSendGridJSON As String = reader.ReadToEnd()
Dim tempVar As Rootobject = JsonConvert.DeserializeObject(Of Rootobject)(rawSendGridJSON)
System.Diagnostics.Trace.TraceError(rawSendGridJSON)
I am then trying to store the post values in a table like this:
Public Function CallBack(tempTable as temporaryTable)
Dim tempVar As Rootobject = JsonConvert.DeserializeObject(Of Rootobject)(rawSendGridJSON)
tempVar = temporaryTable.tempVar
I then save the new items in the actual table in the database, then I try to display it in a view on another page. This is not working correctly and the problem lies with this line, as the post is not being correctly read in at the right time. (The value is processing correctly as I can use an email method to send the variables in an email back to the application but this application needs to be real-time efficient code).
Is there a better way to use this method and how can I invoke this process that I want to do properly so that I can display the correct information?
Update
To clarify, there are two posts that are happening, the first one is when the user enters in information and submits it. This is then stored in a database and send to JIRA via email. Once JIRA receives the information, it is sends a HTTP POST webhook JSON Payload back to my application with updated information. I then have deserialized the JSON Payload into a variable called issueKey.
The problem is that on the View page that the information is sent to will automatically display a null value first before the value is sent to it, I want the application to work so that it will actually display/store in a database the values from the Webhook JSON Payload but I cannot figure out how to display the values.
I have now set up a communication channel from SignalR to my MVC application, at the moment it is being received by the MVC and I have set up a SignalR chat Hub in my MVC application, but I don't know how to integrate them, how can this be done?
As I understand it, there are two flows at work here. The user posts data, which triggers an email to Jira. Then sometime later (usually quite fast, but not always) JIRA triggers a webhook in the web application with some updated information, and you want to display this updated information to the user somehow, or at least inform the user when the updated information comes back from JIRA.
I would implement a standard Post-Redirect-Get for the user initiated part (as per br4d's comment). I.e. a post to store the data in the database and send email to jira, which returns a redirect to a get which shows the data stored in the database.
Now for the other part I would use signalr to set up some sort of communications channel to the user. The webook could then send a signal (of sorts) through the communication channel to the users browser and either display the data, or trigger a refresh of the page (if you are updating the database with data from Jira).
It is unclear if you are doing straigt mvc, or some sort of SPA application, but it is not really important. The users browser has no way of knowing about the webhook (which is a part of the webapplication and unrelated to the users session), and you need some sort of communication between the webapplication and the browser, and for this signalr is very very good.
The object extraMetadata is undefined and throwing an error on line 247 of breeze.labs.dataservice.sharepoint.js
rawEntity.__metadata = { 'type': aspect.extraMetadata.type };
I suspect it is because I have not defined the type found in __metadata object on my entity definitions for breeze. Any suggestions on how to define my type correctly would be very welcome! Here is my type definition for one of the objects.
models.Project = {
name: 'Project',
defaultResourceName: 'getbytitle(\'Projects\')/items',
dataProperties: {
ID: {
type: breeze.DataType.Int32
},
Title: {
nullable: false
},
StatusId: {
type: breeze.DataType.Int32,
nullable: false
},
SelectedApproverId: {
type: breeze.DataType.Int32,
nullable: false
},
Created: {
type: breeze.DataType.DateTime
},
Modified: {
type: breeze.DataType.DateTime
}
},
navigationProperties: {
Status: {
type: "Status",
foreignKeyNames: ['StatusId'],
hasMany: false
},
SelectedApprover: {
type: "User",
foreignKeyNames: ["SelectedApproverId"]
}
}
};
UPDATE: 11/11/2013
If I run the following query:
return breeze.EntityQuery
.from(metadataStore.getEntityType('Project').defaultResourceName)
.orderBy('Created desc')
.using(manager)
.execute()
.then(function (data) {
console.log(data.results);
return data.results;
});
the results are an array of simple JavaScript objects, not Breeze Entities, that lack an __metadata properties. I'm trying to figure out why this is the case.
Update: 11/12/2014
I have confirmed that this issue presents itself when I have multiple entities defined under navigationProperties.
Please be sure you are using BreezeJS v.1.4.12 or later.
To be clear, the code to which you refer is on line 147 (not 247) of the breeze.labs.dataservice.sharepoint.js file in my possession.
It's located within the _createChangeRequest where it is preparing to save a modified entity. I'll assume that you have queried a Product entity, made changes to it, and are saving it back when the error occurs.
I don't believe the problem will be traced to how you defined the metadata for your Product type.
You should NOT define a __metadata property for your type. The __metadata property is something we expect SharePoint (any OData source in fact) to add to the JSON entity data that it sends to the client when you query that OData source for entities.
__metadata wouldn't be defined for results returned by a projection but then your issue concerns a modified entity so I'm assuming that you acquired this entity through a normal query ... one that did not have a select clause.
I'd like to know if you see the __metadata property in the JSON payload of a query that retrieved the entity you were modifying. Please examine the network traffic from the query request. If you don't see it there, we have to find out why the server didn't send it.
Background
The __metadata property on the JSON node is a crucial part of the contract with the SharePoint OData server. That's how the Breeze client learns about the entity's type and its etag.
Look at the jsonResultsAdapter.visitNode and updateEntityNode methods. You'll see how the adapter uses __metadata to determine the EntityType for that data. You'll also see that the adapter moves the __metadata to the adapter result's extraMetadata property. BreezeJS subsequently moves that "extra metadata" from this result object to the entity's entityAspect.extraMetadata property.
Does this seem tortured? It is tortured. OData requires extra information to be carried around with the entity (specifically the etag) without which the server simply will not update or delete the entity. We have to squirrel that info away somewhere, out of your hair, and then bring it back when we make save requests to the server. We put it on the entityAspect in keeping with that property's role as the keeper of the "entity-ness" that has nothing to do with your object's business purpose and everything to do with how it is persisted.
So much for the why. Where is the bug?
The bug
The underlying bug is that this __metadata from the SharePoint OData source has disappeared. We don't know how it disappeared yet. But we're in big trouble without it.
The sharepoint adapter should give a better message when extraMetadata is missing. We actually look for that problem a few lines later; see adjustUpdateDeleteRequest:
var extraMetadata = aspect.extraMetadata;
if (!extraMetadata) {
throw new Error("Missing the extra metadata for an update/delete entity");
}
That test appears too late. I'll make a note to move the test up.
But such a fix will only cause the save to fail with a better message. It won't tell you how to fix it.
So let's work on finding where the __metadata disappeared ... starting with whether it ever arrived in the first place.
I await your report.
Update 17 July 2014
I'm still waiting to hear if you are seeing the __metadata property in the payload of the response to the original entity query.
Meanwhile, I checked the OData specs (plural) for references to the __metadata property. It appears that the __metadata property has always been optional. It follows that an OData provider need not send or honor the etag ... and we know that this is possible because Web API 2 OData didn't support etags ... a defect soon to be corrected.
See the OData v.2 spec where it describes JSON format. Search for the term "__metadata".
The OData v.3 spec also calls for the __metadata property in a JSON response (at least a JSON verbose response).
But ... heavy sigh ... it appears that the __metadata property is gone from the v.4 spec and that the metadata information is supplied entirely through JSON annotations. The DataJS library (used by many but not all BreezeJS OData adapters) may map those annotations into the node's __metadata property but I can't confirm it yet. We have some work to do coping with all of these variations.
In the meanwhile, I think all BreezeJS OData dataservice adapters should take a more defensive position regarding extra metadata and should simply ignore the omission rather than throw exceptions.
We'll make these defensive changes very soon.
Of course the server will reject your update or delete request if the OData service actually requires an etag or other metadata. I don't know what we can do about that just yet.
There hasn't been a post in a while but I am going to share what I found as the problem and how I resolved it for me (because it took me a long time).
Basically the breeze.labs.dataservice.sharepoint adapter has a function serverTypeNameToClientDefault() that expects the SharePoint custom list type as returned by REST/OData in the __metadata "type" field to be in the exact format of:
SP.Data.**mylistname**sListItem** (notice the "sListItem" suffix; ; Ex. SP.Data.CustomersListItem)
This function does a string regex to extract the Breeze entity name from the SharePoint type and uses that name to look up the entity in the metadata store ("Customer" in the above example). If there is no match, Breeze will not find your entity and will return a basic object instead of a Breeze entity. Therefore your REST JSON result returned from SharePoint, even though it does have the __metadata property is not converted into a Breeze entity that contains the property entityAspect.extraMetadata, among other things. This is what leads to the error "Unable to get property 'type' of undefined or null reference"
For my solution, since in my case I don't care as much what the URL of my custom lists are, I just made sure that when my custom list was provisioned by SharePoint that it resulted in a name according to what Breeze expects. You accomplish this by setting the Url attribute of the ListInstance element like this:
<ListInstance
Title="My Customers"
OnQuickLaunch="TRUE"
TemplateType="10000"
Url="Lists/Customers" <!-- List/Customer will not work -->
Description="My List Instance">
...
The better solution would be to make the serverTypeNameToClientDefault() function more robust or fix it to my needs locally but hopefully this can be addressed in a future version of the adapter.
Note that I have tested this solution with the following configurations (not all dependencies listed):
Breeze.Client 1.4.9 with Breeze.DataService.SharePoint 0.2.3
Breeze.Client 1.5.0 with Breeze.DataService.SharePoint 0.3.2
Also note that the 0.3.2 version of the adapter now displays a better error message when this happens as mentioned above -- "Missing the extra metadata for an update/delete entity"; but it doesn't fix the problem.
Hope this helps someone.
For breeze v1.4.14 and breeze labs sharepoint 2013 v0.2.3 i am using small fix in file breeze.labs.dataservice.sharepoint.js.
At the end of function
function visitNode(node, mappingContext, nodeContext)
just before
return result;
i just set property extraMetadata like this:
result.extraMetadata = node.__metadata;
This seems to fix problem when i try to save modified entity back to sharepoint.
Sorry folks for the long overdue aspect of this, but I got the bug with the extra "s" resolved today... FINALLY. You can track the issue here: https://github.com/andrewconnell/breeze.js.labs/issues/6
This all stemmed from a very incorrect assumption I made. It's been fixed in version 0.6.2 of the data service adapter for SharePoint. Note that you MUST use the same name for your entity when creating it in the metadata store as the list where the data is coming from.
I resolved my issue with multiple navigationProperties on an entity by editing line 319 of breeze.labs.dataservice.sharepoint.js v.0.10.0
I changed:
if (entityType._mappedPropertiesCount <= Object.keys(node).length - 1)
to:
if (entityType.dataProperties.length <= Object.keys(node).length - 1)
It looks like the _mappedPropertiesCount includes the navigationProperties count too. e.g. dataProperties.length + navigationProperties.length
The query node was then thought to not contain a full set of properties for the entity (it was assumed to be the result of a partial projection).
It therefore wasn't being treated as an entity, its metadata wasn't being set, and it ultimately wasn't being added to the cache.
It worked with only one navigationProperty as there were two extra items in Object.keys(node), __Metadata and ID. So it would still pass the test with one navigationProperty, but not two or more.