I call SPO Rest API and in response I found two type of dates. I am not able to find any documentation on their difference especially the one with Dot (.)
Both Dates are shown here
We want to use one with Dot as its in standard format, but not sure about its authenticity. We are using RenderListDataAsStream as end point to get data.
Any documentation of properties coming with Dot(.) will be helpful to understand it. In attached image count is also another same example having dot.
P.S: here are the differnt ways to access them
I think the value of the normal named key (like technical field name) represents the value shown in UI to a user. So it is affected by the regional settings of the web.
The value of the additional "."-key (technical field name plus ".") represents the UTC-0 value in ISO format (like the data is stored in DB internaly).
For example:
"Created": "0;#2022-09-07 06:17:37", // timestamp by Regional Settings
"Created.": "2022-09-07T13:17:37Z", // UTC-0 in ISO format
Related
Is there a functionality in Tabluau to create a variable that can be used in few places by referring to its name? I'm asking because I need to prepare a dashboard and the data loaded and displayed on the dashboard can contain two different variables in column called value. So I would need to define such a 'variable' that would be filled with the type of value column (ex. type 1 or type 2) and use it as a axis name, in a tooltip etc. Of course, I'm trying to avoid a necessity to change all the axis names and tooltips manually.
In Tableau, they are called parameters. Please refer to following articles to learn more about this.
Parameter basics
Swapping Measures using parameter
I believe what you are asking is covered in link 2.
so my company wants me to learn ABAP for SAP and I have started on the road to learn this. My background is mainly VB.net and sqlserver with T-SQL but also have experience in c#.
With ABAP though I am needing some clarification or confirmation on the understanding of Data Types and Domain. If anyone can help.
My understanding currently is we have a table, in the table we have fields and the fields have data types and lengths if needed. Example: We have a table Customer, I could have a customerNumber field with the data type of char(10). To me this mean in the table customer we have a field called CustomerNumber that will have 10 characters.
However with ABAP we have Domains, Data elements then the field, does this mean we have a field named whatever we want. As the field could mean anything we assign a data element which has the descriptions of the sort of data stored within the field. However to store the format and data type we need to assign the Domain to the Data element.
For example I call a field ZCUSNO, currently this means nothing however if I assign the ZCTNMR (with description of customer number) Data element this tells us that the field ZCUSNO is ZCTNMR so ZCUSNO is a customer number field.
Now within the data elements we would have a domain and for our example ZCTNMR data element (the customer number) we could assign ZCTDOM as the domain which would be what I recognise as the data types so Char 20, Char 100 or integer field etc.
Is my understanding correct on this? and could someone give me a clear indication of what the difference between a Domain > Data Element is against what I would know as data types in sqlserver.
Thanks
I don't know if it's 100% correct, but that's is the way I use, like you say.
You can reuse the Domain, If you don't plan to reuse you can use direct the Data Element and refer this to a built-in-type.
Data Element is to define semantic of the field, like label, translation, etc
Domain is to define techinical info of the field, like Type, conversions, predefined Values,e tc
E.G.
Domain:
DOM_VALUE you define it's 10 position and 2 Decimals
Data Element:
UNIT_VAL you refer it to DOM_VALUE and define label as "Unit Value"
TOTAL_VAL you refer it to DOM_VALUE and define label as "Total Value"
Your understanding is pretty correct and not much can be added here.
You should clearly get the main thing.
Domains store technical data (decimal points, length, type, predefined values and so on)
Data elements store semantic data (labels, texts, search help binding, etc.)
Not every table field has data element (they can possess builtin type) but every field has type (either primitive or wrapped in data element).
If you wanna use your field in screens (Dynpros), ALV grids or other reports, then create data elements that will bear business meaning of your field.
If you use this field just for calculations or other utility internal tasks, then don't bother yourself.
As usual table date field (type of variable) uses data element which uses domain.
When you create fields in table and use predefined types instead of data elements you will have some problems in future, when you'll need to see the data on alv_grid.
Actually, you will see that you have some problems even before this (when you will try to make a maintenance view the header will have something like "+" symbol).
And of course we usually try to create 1 domain for 2 and more Data Elements.
In domain you talk about main logic.
In Data Element I always talk about Field label settings (how it'll show in future and some other things)
Final: Actually, the good practice, as I think to create a domain for data element, it may help you in future.
I hope that it helps you. Good luck!
Anyone been able to successfully update the custom_field_values for a matter via Clio's API?
I'm trying to update the value for custom_field_values under a single matter. I'm able to send a JSON string using PATCH and update the default values for a matter like location or description using the following format
{"data":{"location":"Orange"}}
But when it comes to updating a "custom field value" I'm getting a 422 Unprocessable Entity error. I'm following Clio's v4 API Documentation and my understanding is that to update a custom_field_value you need the following JSON:
{"data":{"custom_field_values":[{"id":658213,"custom_field":{"id":139385},"value":"New Value Goes Here!"}]}}
However here is the message coming with the 422 error:
{"error":{"type":"ArgumentError","message":"An invalid argument was supplied: invalid custom field value id provided, acceptable format is <type>-<unique id>"}}
I can't interpret the part suggesting the acceptable format!
I've also tried sending the JSON in the following format which is closest to Clio's V2 API Docs for updating a custom field:
{"data":{"custom_field_values":[{"custom_field":{"id":139385},"value":"New value goes here"}]}}
But then this is what I get back:
{"error":{"type":"ArgumentError","message":"An invalid argument was supplied: custom field value for custom field 139385 already exists"}}
Please note that this is being tested in POSTMAN regardless of my development environment. I appreciate your response!
I've successfully created queries to update custom field values in matters many times, and these run all the time for me. I've compared your json to some examples of the json I'm successfully sending. Your syntax appears correct, but there's enough missing for me to only guess at where your mistake might be.
First, you're sending a PATCH to https://app.clio.com/api/v4/matters/{matter id}.json right? It took me a while to learn that you can't update the value of a matter's custom field with a query to https://app.clio.com/api/v4/custom_fields/{id}.json.
Second, just to clarify, the 658213 id you used above (the first id field) should be the unique id of this instance of your custom field. You won't get this until you've created an instance of the custom field particular to this matter. The second id field, where you've put 139385 is the id for the custom field itself, which you could get with a query to https://app.clio.com/api/v4/custom_fields.json.
If you're looking in the V.4 docs under Custom Fields, you won't find this, or at least I didn't. BUT you can find it in the intro section to the Matters portion fo the documentation: https://app.clio.com/api/v4/documentation#tag/Matters
Hope this helps. I'd imagine someone at Clio could help by verifying your error string is delivered when you have an incorrect custom field value unique id.
To further clarify Jacob's answer for everyone else:
custom_field{id} is the id given to a custom_field when it's created and will be the same for all matters or contacts it's used in.
custom_field_value{id} is the id given to an instance of the custom_field added to a particular matter and unique only to that matter
To add a custom_field to a matter for the first time the following format is used:
{"data":{"custom_field_values":[{"custom_field":{"id":123456},"value":"string or integer depending on the type of CF"}]}}
To update a custom field already added to a matter the following format should be used:
{"data":{"custom_field_values":[{"id":"text_line-1234567", "custom_field":{"id":123456},"value":"string or integer depending on the type of CF"}]}}
To delete a custom field already added to a matter the following JSON format is sufficient:
{"data":{"custom_field_values":[{"id":"text_line-1234567", "custom_field":{"id":123456},"_destroy":true}]}}
Format for updating a custom field already added to a matter:
{"data":{"custom_field_values":[{"id":"unique_instance_of_your_custom_field", "custom_field":{"id":'custom_field_id'},"value":"value which should be updated"}]}}
Here, the first id field should be the unique id of this instance of your custom field. To get this value follow this documentation section, app.clio.com/api/v4/documentation#tag/Matters and the second id field is the id for the custom field itself.
In CRM, when I'm, trying to set up a work flow, I get to choose the timeout to be related to a certain entity's creation time. There are three fields to relate to.
Record Created On
Created On
Modified On
While the last one is very obvious, I can't see any logical difference between the two others.
The difference is that Created On (createdon) is filled out automatcally by the server when you actually create the record, while Record Created On (overriddencreatedon) will usually be null (unless the record was imported into CRM and you chose to explicitly override the record creation date to match when it was created in another system).
You should use the first and skip the latter, as it's not supported (as far I've got it right when I talked to a MVP about it). Why it show, she had no idea and neither do I. Maybe #JamesWood has a shot. He usually does. (sucking-up in progress)
I've never used the latter and I believe you'll keep your hair off-grey and on-head if you stick to the same approach.
From the SDK:
The createdon attribute specifies the date and time that the record was created. To import data in the createdon attribute, map the source column that contains this data to the overriddencreatedon attribute.
During import, the record’s createdon attribute is updated with the value that was mapped to the overriddencreatedon attribute and the overriddencreatedon attribute is set to the date and time that the data was imported.
If no source value is mapped to the overriddencreatedon attribute, the createdon attribute is set to the date and time that the data was imported and the overriddencreatedon attribute is not set to any value.
Link to BlogSpot
Link to Social MSDN
I have a REST URL to get all users formatted like this:
http://example.com/users
To get an individual user by id:
http://example.com/users/12345
To get all user's bids:
http://example.com/users/12345/bids
To get all user's bids between two dates:
http://example.com/users/12345/bids/?start=01/01/2012&end=01/31/2012
or should it be like this:
http://example.com/users/12345/bids/start/01012012/end/01312012
I'm leaning towards the 1st date range URL as start and end are not entities in the domain. What is the proper way to format a REST URL with a date range?
Thanks,
Tom
http://example.com/users/12345/bids?start=01-01-2012&end=01-31-2012
Have the query parameters on the same "level" as the bids (remove the slash before the question mark). But you would probably want to have support for if they only provide one query parameter. So if they only provided "start" then it would get all bids after that date, or if they only provided "end" it would get all bids before that date.
The reasoning being that query parameters are good for GETting a subset of results from a GET request. They don't go on another level because the next level is usually one specific item with a unique identifier.
I would go with http://example.com/users/12345/bids?start=2012-01-01&end=2012-01-31.
There shouldn't be a slash before the query string.
Avoid using slashes in the query string. It'll be easier that way.
If you use the path separator / to delimit the values you're likely to encounter numerous issues. If you decide you want the start and end dates to allow ISO formats e.g. 2021-10-12T01:00:00.000Z, 2021-10-01T18:00:00.000+05:00, those formats contain characters that will break the URL. Much better to use querystring parameters.
I'd recommend using the querystring and ISO format for dates so your URL will look something like this:
https://example.com/users/12345/bids?start=2022-08-08T00:00:00.000Z&end=2022-08-09T00:00:00.000Z
Your API method that retrieves by date range can then be differentiated from the GET request that retrieves all bids for the user, simply by using a different method signature that expects additional start and end date parameters in the request.
if example.com/users/12345 gets the user with id 12345, then to get all users by id it should be example.com/users with the id included in the response as a relationship. (usually a hyperlink to that resource).
Now to get them by date ranges it should be example.com/users/start=01-01-2012&end=01-31-2012
The 12345 part is the id of an individual user, it's a resource, therefore it should not be included to get the rest of the users.
As the name of the parameter it should be meaningful. start could mean anything, but start_date is more meaninful.