I'm attempting to get all OrgUnits using Valence that are the "Department" type. When I do the call to /d2l/api/lp/1.4/orgstructure/?orgunittype=Department, I get a paged result set containing all the OrgUnits
The docs are a little unclear. They specify that
You can use the orgUnitType, orgUnitCode, and orgUnitName query parameters as filters to further narrow the list of org units this action retrieves.
and also
orgUnitType (string) – Optional. Filter to org units of this type.
However, "string" is a bit ambiguous considering OrgUnitType is a composite type with both a code and a name as a string. Both my Code and my Name for this type is "Department yet it still gives me everything.
You should provide an org unit type identified by a valid orgUnitTypeId (for course offerings, this will be 3.
For custom org unit types, like "Department", the value will most likely vary LMS to LMS:
You can use the call to retrieve the list of all known org unit types to determine the type corresponding to "Department" for your LMS.
Or, because "Department" is one of the very common custom org unity types, you can use the specific get department-org-unit-type call to find out what the ID is for that type on your LMS (there's also a specific call like this to get the type ID for "semester" org units).
Related
The descriptions of the property modifiedProperty do not contain a list of (or a link to) its possible values, which makes it difficult to utilize APIs that return this resource type.
Document Details
Content: modifiedProperty resource type - Microsoft Graph v1.0
Content Source: api-reference/v1.0/resources/modifiedproperty.md
Product: microsoft-identity-platform
Technology: microsoft-graph
Link : https://github.com/microsoftgraph/microsoft-graph-docs/blob/master/api-reference/v1.0/resources/modifiedproperty.md
It would be helpful if the list of possible values could be provided.
I highly doubt you're going to be able to find such a list. The values of the modifiedProperty property are going to vary based on which type of Azure resource you're looking at and which property on that resource was modified. The only thing you can be certain of is that the modifiedProperty will be empty or it will contain a property name, the old value, and the new value, according to the documentation you linked.
If you are trying to code for a particular type of Azure resource or a particular type of property, you should look into the documentation for that resource or property instead of the documentation for getting that information.
I am trying to create a OData service that returns user parameters found in the databasde usr05. Those can be accessed by the ABAP statement:
GET PARAMETER ID 'XXX' FIELD YYY.
This means, that basically do not need a key value.
In SEGW it is impossible to create an entity type without one though.
The solution of course could be a dummy key field, that is simply ignored in the backend implementation.
Does anyone know a better solution?
Thanks in advance,
Eric
it is not a shame it is by design and follows the OData specification.
Every entity type must have a key.
What you can try to use instead is to use a property that is based on a so called complex type within an entity type that is used for your users.
The latter should have a key.
Like the complex type address that is used in the entity type Supplier
https://services.odata.org/OData/OData.svc/$metadata
I'm a bit confused on how we are supposed to update a group using the Valence API.
According to documentation, "Name,Code & Description" are required for updating, but the FETCH group block only returns "GroupID,Name, Description and Enrollments". If Group Code is not returned in the fetch, what value are we supposed to use in the update block if we only want to update the name? Since description is provided I can just feed that back, but what am I supposed to do about code ... just lose that data?
Perhaps there a way to send an update that will update only specific fields in the update block? When I omit fields from the update block I currently receive an error (ie in the case I only want to update the name).
The Code property for Groups is intended to be the "org-defined code" for the group (for a course offering, this is often called the "course code"), the one that might appear in the organization's SIS system, for example.
Because groups in Desire2Learn's Learning Suite are considered "org units", when you create one, you need to provide it with an appropriate org-defined code (Code) -- if your organization doesn't use org-defined codes for groups, then you can decide to systematically use some other kind of data by convention (a name, a descriptive string, and so on). You are correct that's inconvenient for the Fetch form of the GroupData structure not to provide this value for you, but the value will be accessible to callers through the organization structure routes (because the newly created group is just an special kind of org unit).
In Learning Suite v10.2 (LP API v1.3+) and later, you can use a single GET call to fetch back the properties for an org unit. In versions prior to v10.2, you will need to fetch the list of parents for the group to get a parent org unit ID, or if you already know the org unit ID for the course offering that owns the group you can use that; then you use that org unit ID to fetch its list of children: your group will be in that list. The OrgUnit and OrgUnitProperties structures both contain the Code property that you need here.
I would like to extend the types generated by the LinqToSQL TypeProvider with additional members. Is this possible? For example if the TypeProvider is pointed to a DB with a table called Company it will expose a type Company with access to the columns. As an example can I a member Company.employees to the generated type which will return all current employees from the employees table?
I don't see why you could not.. provided you have the source for the type provider!
That said, creating or extending a type provider, while not being overly complicated, is not trivial either.
So depending on how central this type generation aspect is for you, it might be best to use existing type providers, and build a layer on top of them on the 'client side'.
Once you have refined a compelling scenario where this would really yield value, then you can reuse this layer anyway.
What is your end-scenario ?
Doesn't the existing SQL Type provider cover the Company.employees case ?
It sounds like what you want to do could be accomplished by using a type extension.
Type extensions can be added to any accessible type, which should include types generated by the type provider.
I understand that in MVC pattern and in REST services it is common to use URIs like /items/{id} but what is bad thing about using query parameters in the URI?
GET /items/{id} vs GET /items?id={id}
Further, lets say an entity has 'referenceId' field that points to some related (say parent) entity, and I need to create REST service to get all items for parent entity, which way is better:
GET(POST) /items/parent/{parentId}
or
GET(POST) /items?parent={parentId}
Will be grateful for insights that would help to resolve my subjective issues on constructing URLs for REST services.
I would use the following schemes.
/items/id
This uniquely addresses a resource of items with id id. We are not using parameters as a parameter to uniquely address this resource (as is the case with the other option). Just as
miguelcobain suggests.
/parent/id/items
Here id is an id to uniquely address a resource of parent and from those we collect/retrieve the items it references. From what you have said in the question it seems that parent references multiple items, like a container or collection.
The convention I use for this is to narrow down the scope going from left to right. Therefore in case items could be active or inactive. Thusly items have a property or attribute to be active or inactive. Narrowing down on this I get the following scheme:
/items/active
/parent/id/active
For your first question:
/items/{id} should retrieve a single resource with the specified id or 404 if it doesn't exist.
/items/?id={id} should retrieve an array (even if only one in the array) because you are querying the collection.
For your second question:
I agree with #miguelcobain's assessment - if the item is a specific resource/entity, just use the proper resource path to retrieve it.
To make this easier on the consumer, create a link header with rel="parent" and/or include the uri in the child resource. For an example of link headers, see GitHub's pagination api.
Of course, REST principles don't care about aesthetic details on URLs. It just imposes that every resource should be uniquely addressable.
Furthermore, using the query parameters to uniquely address something "kind of" violates the semantics of a "parameter", doesn't it? A parameter should be something optional, something additional and parameterized. Something like a detailed search on a collection of items, for example.
What you wrote may make sense in some cases. It depends.
In your example, is the item really a resource? If not, you could just do GET(POST) /parents/{parentId}.
If parent is, say, a boolean, and you want to search the items that have parent equals to true, then using the parameters makes sense. But since you're explicitly saying that you want a parent with a specific id, I assume that parent is a resource itself and I would uniquely address that resource using your option 1.
I hope I made myself clear.
It seems to me there are no rules to follow.
items/{id} - this convention is suitable for GET item by given id. If user doesn't provide id then it returns 404 status code.
items/id={id}&name={name} - this type of convention is suitable for search multiple items by given criteria. If no items are found, it is not a 404 situation, you simply say "I successfully found nothing matching your search criteria"