I have a particular scenario where my primary key is a computed field (this is been used to avoid PK collisions in a replication model...). Some primary keys are large numbers (Int64) I can see that from the service end point the value for this particular field is correct (92233720368547761) but when I look at the response object in the dialog
...protected onViewProcessData(response: ListResponse
I always get the same value (92233720368547760) in onViewProcessData regardless of the value I see in the response of the service end point. You could try 92233720368547758 or 92233720368547765...
PS. for small integers it works as expected.
I got this issue too, as I know it dues to javascript
my solution is using a string field for big Id, and overwrite the id in repository
for example
Row.cs

Repository.cs

thank you for your answer, in my case this field is the primary key of the row and Serenity will complain when implementing IIdRow interface. It only supports Int16, Int32 and Int64.
Just simply use StringEditor instead of IntegerEditor etc for those fields, there is no problem with int64 fields in Serenity itself.
Just open a Chrome console and write JSON.parse('{"a":92233720368547761}') you will get back {a: 92233720368547760}
This is due to Javascript, and there is not much we can do about that part.
To handle such issues Serenity has a special converter JsonSafeInt64Converter that serializes such large numbers as string in JSON instead of integer when they pass a certain threshold (9007199254740992).
But i think it only works with request/response classes, not Rows, as rows has custom serialization which simply calls WriteValue(long) method of JSON.NET, and probably it doesn't trigger this converter (maybe it did in the past, not sure).
So i tested your case in Mail queue, by inserting that big long value into row (92233720368547761):

The value in Network tab is correct, so, it's actually trimming the value due to javascript JSON deserialization. We were using JSON2 in the past, maybe it was handling this issue gracefully.
Anyway, i just changed Int64Field.ValueToJson to handle it just like JsonSafeInt64Converter and this is the result:

This might be bit dangerous in cases where the deserializing party expects an integer value in that field and doesn't handle string values properly.
It'll make it into next version, but still make sure you use [StringEditor] if you have show/edit such fields somewhere.
hello @volkanceylan
I see you updated a bit code about Big Id
https://github.com/volkanceylan/Serenity/commit/8786be8dbf9fdbbaa383cf3b92e8ad6df764b085#diff-e671c14b1085acdf0badab6855a4512cR45
I am not sure but I think it should be intvalue >= 9007199254740992 || intvalue <= -9007199254740992
equal or greater/less because max safe integer is 9007199254740991 (threshold)
9007199254740992 is also valid number, try assigning it to a variable
I tested commit 8786be8 it works!. Thank you.
Most helpful comment
Just simply use StringEditor instead of IntegerEditor etc for those fields, there is no problem with int64 fields in Serenity itself.