/api/data/appointments?$select=subject&$filter=regardingobjectid eq a199a199-a199-a199-a199-a199a199a199
This has change to the following in the v8.0 release:
/api/data/v8.0/appointments?$select=subject&$filter=_regardingobjectid_value eq a199a199-a199-a199-a199-a199a199a199
The second thing I spotted is in fact a bug. This may have existed in the preview, but I never spotted it and it had me scratching my head for quite some time. We have the concept of an "event day" which we have name "inv_eventday". When creating this entity CRM creates a collection schema to allow you to reference it via the web api. For example the appointment entity has an equivalent collection schema called "appointments"; notice the pluralisation.
So, on to my event days. What you would expect to find as a collection schema is this:
/api/data/v8.0/inv_eventdays
Unfortunately, this is not the case. You get an error "Resource not found for the segment 'inv_eventdays'." I wondered if I had a case sensitivity issue or something, but every combination of captitals / camel case / pascal case just didn't seem to work.
After some time I decided I should check out the metadata to see if I could uncover the correct casing. For reference the following is how you get a list of all entity metadata:
/api/data/v8.0/EntityDefinitions
This uncovered a definition with the following schema name for the entity:
"SchemaName":"inv_eventday"
Which seems to match my expectations on what it should be. So what's the problem? Reading further down I find the Collection Schema name:
"CollectionSchemaName":"inv_eventdaies"
That's some funky plural we've got there! Looks like the algorythm decides that anything ending in "y" is pluralised as "ies". Obviously this isn't correct for all words. E.g. the word "sky" is indeed "skies", but "day" is in fact "days".
Now... where do you log CRM bugs...
I found this to be an issue too. It also replaces schema names ending in 's' with 'es'.
ReplyDeleteThere is also the secondary issue to this in that if you have an entity with scema name city, it will pluralize it as cities. If you then needed an entity with schema name citis or citie it will not be able to create it as the pluralization of these would also be cities.
I'm guessing that sheep would also incorrectly pluralize to sheeps.
I think a beeter solution for the system would be to base the plural name from the plural display name and allow you to amend it a t creation (as ti currently does for the singular). There are many exceptions to pluralization in English, and probably English pluralizations won't work if your language is not English.
For the record and future visitors - you can edit the generated plural name for the Web API when you run into this - https://msdn.microsoft.com/en-us/library/mt607990.aspx#bkmk_entityTypes (change the name of an entityset)
DeleteIndeed you can, something I found out myself after writing this post. Been meaning to write another blog post about it in fact. I'm still very disappointed that Microsoft didn't by default use the entity pluralization we provide on the entity definition as opposed to forcing us down this route to rename an entityset.
Delete