This commit is contained in:
@@ -80,34 +80,8 @@ TODO CLIENT STUFF
|
||||
|
||||
TODO SERVER STUFF
|
||||
|
||||
|
||||
- Boot server and seed with debug log turned on,
|
||||
- see what is being tracked by EF that doesn't need to, seems some of that shit is being tracked.
|
||||
- Microsoft.EntityFrameworkCore.ChangeTracking|DetectChanges starting
|
||||
|
||||
2018-12-19 12:19:44.9942|DEBUG|Microsoft.EntityFrameworkCore.ChangeTracking|'AyContext' generated temporary value '-9223372036854774807' for the 'Id' property of new 'Locale' entity.
|
||||
2018-12-19 12:19:45.0490|DEBUG|Microsoft.EntityFrameworkCore.ChangeTracking|Context 'Locale' started tracking '{Id: -9223372036854774807}' entity with key 'AyContext'.
|
||||
...
|
||||
2018-12-19 12:19:49.2317|DEBUG|Microsoft.EntityFrameworkCore.ChangeTracking|Foreign key property 'LocaleItem.LocaleId' detected as changed from '-9223372036854774807' to '1' for entity with key '{Id: -9223372036854774080}'.
|
||||
2018-12-19 12:19:49.2317|DEBUG|Microsoft.EntityFrameworkCore.ChangeTracking|Foreign key property 'LocaleItem.LocaleId' detected as changed from '-9223372036854774807' to '1' for entity with key '{Id: -9223372036854774079}'.
|
||||
2018-12-19 12:19:49.2317|DEBUG|Microsoft.EntityFrameworkCore.ChangeTracking|Foreign key property 'LocaleItem.LocaleId' detected as changed from '-9223372036854774807' to '1' for entity with key '{Id: -9223372036854774078}'.
|
||||
...
|
||||
2018-12-19 12:19:52.2781|DEBUG|Microsoft.EntityFrameworkCore.ChangeTracking|The 'LocaleItem' entity with key '{Id: 1129}' tracked by 'AyContext' changed from 'Added' to 'Unchanged'.
|
||||
2018-12-19 12:19:52.2781|DEBUG|Microsoft.EntityFrameworkCore.ChangeTracking|The 'LocaleItem' entity with key '{Id: 1128}' tracked by 'AyContext' changed from 'Added' to 'Unchanged'.
|
||||
2018-12-19 12:19:52.2781|DEBUG|Microsoft.EntityFrameworkCore.ChangeTracking|The 'LocaleItem' entity with key '{Id: 1127}' tracked by 'AyContext' changed from 'Added' to 'Unchanged'.
|
||||
2018-12-19 12:19:52.2781|DEBUG|Microsoft.EntityFrameworkCore.ChangeTracking|The 'LocaleItem' entity with key '{Id: 1126}' tracked by 'AyContext' changed from 'Added' to 'Unchanged'.
|
||||
...
|
||||
|
||||
|
||||
|
||||
- See what warnings are displayed about sql usage
|
||||
|
||||
- Docs: pagingOptions, sort and filter need to be documented for API
|
||||
|
||||
- LICENSING: can we support additive user licensing to avoid a lot of fuckery or...? I.E. can a license contain multiple subitems that are techs with their own count and expiry?
|
||||
- or is this more of a shareit issue than our issue as AyaNova will not care and there can still be one item
|
||||
- This came about because a guy bought a second 5 user thinking that's how you get a 10 user today
|
||||
|
||||
-----------------
|
||||
|
||||
TODO AFTER CLIENT block ABOVE:
|
||||
|
||||
@@ -5,6 +5,42 @@ No other data formats are supported, your code must supply and consume JSON form
|
||||
|
||||
All developer interaction with the AyaNova API is via the REST server interface only.
|
||||
|
||||
DATES, TIMES, TIMESTAMPS - All dates and times sent or retrieved from the REST interface must be in UTC / GMT time zone. It is the client's responsibility to display and accept dates in local format but interaction with the server is in UTC only.
|
||||
## API documentation
|
||||
|
||||
Your primary source of information on how to make API requests is the [API explorer console](api-console.md) where every route is documented and can be tested manually before coding.
|
||||
|
||||
## Date and time
|
||||
|
||||
All dates and times sent or retrieved from the REST interface must be in UTC / GMT time zone. It is the client's responsibility to display and accept dates in local format but interaction with the server is in UTC only.
|
||||
|
||||
## Localization
|
||||
|
||||
Every User account in AyaNova has their own UserOptions object which contains their personal localization settings such as time zone offset, currency symbol and numeric formatting options you can use this value to correctly display and interpret values at a client level.
|
||||
|
||||
In addition every user has their own locale setting ID which can be used to fetch and display text in the correct locale by using the methods in the Locale routes.
|
||||
|
||||
## Paging, sorting and filtering lists
|
||||
|
||||
Most list routes have a common method for paging sorting and filtering via query parameters provided to the route:
|
||||
|
||||
### Offset
|
||||
|
||||
This parameter controls the paging offset and is expected to be an integer. If no value is specified the default is 0.
|
||||
|
||||
### Limit
|
||||
|
||||
This parameter controls the number of items returned starting at the offset provided. The maximum allowed value is 1000, the default value is 25 if no value is specified.
|
||||
|
||||
### Sort
|
||||
|
||||
This parameter controls the sort order of the data returned. It is expected to be a JSON array of objects that contain two fields a `fld` property that contains the string name of the field to be sorted by and a `dir` property that controls the direction of sorting and is one of two values "+" for Ascending or "-" for Descending. Multiple objects may be specified to sort by multiple columns in order from first to last specefied in the array.
|
||||
|
||||
For example the following Sort array will sort a list by Name first in ascending order and then by StartDate second in descending order:
|
||||
|
||||
```[{fld:"name", dir:"+"},{fld:"startdate", dir:"-"}```
|
||||
|
||||
To determine which field names are valid for a particular list you can make use of the `/FilterOptions` API route for that object which is available for any objects with sort and filterable lists.
|
||||
|
||||
If no sort parameter is provided the default is to sort by Id Descending so the most recently created objects appear first in the list.
|
||||
|
||||
|
||||
**TODO FILL THS OUT**
|
||||
Reference in New Issue
Block a user