As of April 12th, you must go to Progress SupportLink to create new support cases or to access existing cases. Please, bookmark the SupportLink URL and use the new portal to contact the support team.
On iOS, some of the records in the data store are being loaded in with the metadata times both set to nil. I can't find any rhyme or reason to it. Some of them were created in the console interface, some were created using the kinveyEntity() module in business logic and then populated using a uri request. Both have worked and both have not worked. All show their dates in the data store interface (though some created with a uri request have strangely rounded-off times)
Has anyone else run into mysterious fantom creation and last modified dates?
OK, I thought that might be the case, good to know.
M
Mike
said
over 9 years ago
There is a bug in kinveyEntity(), we're working on a fix.
E
Ed Ragsdale
said
over 9 years ago
I think a teammate figured out what was causing it. When we stopped using the kinveyEntity() module to generate the record and just sent it to be created in a raw state it was initialized properly.
I think we had a similar problem when we were trying to directly create a record within a collection hook using the collectionAccess module, but it was a while ago so I can't be sure.
E
Ed Ragsdale
said
over 9 years ago
More info on the headers. We have a similar script that uses the request's authorization and works correctly
var headers = { 'Authorization': request.headers.authorization };
On this one which causes incorrect metadata, we're creating a new sent message when the user is created. The request's authorization is not sufficient when the user is being created since it is not being called from an active user, so we are manually creating the auth headers for the master user to do the creation. The record is being created, but with this one issue of incorrectly formatted metadata times.
Right now, we are using base64 to encode the app key and master secret to generate the headers:
How is your object saved? "2014-03-25T06:22:00+00:00" is not a valid date string (for our library). It expects it in the form "2014-03-25T06:22:00.000Z"
E
Ed Ragsdale
said
over 9 years ago
Here is the response from the API Console. It is a sent message which resolves a _message and its messageType. The only difference I can see is the order which the times are listed. The parent object is the one which is created with nil times on iOS.
Ed Ragsdale
Has anyone else run into mysterious fantom creation and last modified dates?