Ask a Dev

# Question How can I access information about the currently logged-in user on a custom admin page? # Answer With Angularjs, you can inject the `adminService` and use the `getInfo()` function to get an object containing details about the current user. ```js (function () { module.controller( 'MyCustomController', MyCustomController ); MyCustomController.$inject = ['$scope', '$log', '$http', 'adminService']; function MyCustomController( $scope, $log, $http, adminService) { adminService.getInfo().then(function(res) { console.log(res.data); }); } } )(); ``` Here we create a new controller called `MyCustomController` and specify to angular to include `adminService` in the injections. Once inside the controller function, we can then call `adminService.getInfo()` to get the http promise. The `res` object is the response, and the data about the user is in `res.data`. The structure of this data looks like this: ``` { "BannerHtml": null, "DataPoints": [...], "Settings": { ... }, "User": { "FirstName": "Joe", "Id": 123456, "IsDiscoUser": true, "LastName": "Schmoe", "RoleId": 100, "Username": "myUserName" }, "Permissions": ["ACTIVITY_LOG_VIEW", ... ] } ``` The `data.User` object contains details related explicitly to the logged-in user, such as username, first and last name, and role ID.

# Question How do I place a person in a tree in custom Extension code? # Answer Sometimes in code, you'll need to place a person in a tree. The Extension makes that possible quite easily, but the syntax isn't readily clear. ### A word of caution: > Trees are important to the business, so making mistakes here can result in a lot of work. Please make sure you're comfortable with tree structure, tree types, and that you know how to test and check the results of moves in Corp Admin. The concept of a **node** is used. This is a spot in the tree, and it "knows" about itself: who its parent is, and who it contains. The "ValidatePlacement" call you see is to make sure you don't create circular references. Here, we're placing in the "Enroller Tree". For Unilevel and Enroller tree, you need to specify the LegName as "LegName.Empty", not just "null", or you'll get a null reference exception. For Binary or Matrix trees, you can use the appropriate LegNames in that enumeration. ```csharp var _nodeId = new DirectScale.Disco.Extension.NodeId(_associate.AssociateId); var enrollernodeDetail = _treeService.GetNodeDetail(_nodeId, TreeType.Enrollment); try { _treeService.ValidatePlacements( new Placement[] { new Placement() { Tree = TreeType.Unilevel, NodeDetail = new NodeDetail() { NodeId = _nodeId, UplineId = enrollernodeDetail.UplineId, UplineLeg = LegName.Empty } } }); _treeService.Place(new Placement[] { new Placement() { Tree = TreeType.Unilevel, NodeDetail = new NodeDetail() { NodeId = _nodeId, UplineId = enrollernodeDetail.UplineId, UplineLeg = LegName.Empty } }; }); } ```

From Russell: Calling custom-created Extension functions from Retail and Web Office can be tricky, but it's not bad when you know what's happening. This interaction I think will help clear things up, and I've added a couple of notes below.  Please note that there are two proxy pathways used in the Retail/Web Office API space, "Proxy" (for logged-in users), and "AnonymousProxy" (for anonymous users). The "AnonymousProxy" you were calling required a status code of "0" (worked with non-Extension API calls from our previous Client DLL). There's a new one we added recently that allows you to call Extension APIs without requiring weird data structures. (the only difference is calling the "AnonymousProxySimple"). var request = {   Region: "us", }; var baseUrl =   "/AnonymousProxySimple/demo/get-enrollment-activation-kits?timeout=30000"; // "demo" is the client ID. Put yours here. $RestService   .V3Post(baseUrl, request, true, true)   .then(function (result) {     var response = JSON.parse(result.data.ResponseBody);     console.log(response); })   .catch(function (err) {     console.log(err); }); **Note to widget developers**: This same rule applies in the Back Office code. "ProxySimple" and "Proxy" behave differently. You can get rid of that "Status" ID and any other structures and just work directly with results if you use "Simple" **There are extensive notes on the topic. This is from a document in the DS internal help site**:   # Authenticated Customers There are two proxy endpoints that authenticated customer accounts can use: Simple and Standard. These are called by custom content pages and widgets in the back office and retail site. ### Simple Endpoint The simple endpoint is recommended over the standard endpoint because the requirements are less stringent for the Disco client API that is called. Let's walk through what happens when a call is made to the simple endpoint. 1. Suppose the following is posted to the simple API endpoint: Request URL: https://api.directscale.com/ProxySimple/Associates/GetEyeColor Request Body: { associateId: 4567 } Notes: A request to the proxy endpoint must be a POST. Even if you are not sending a request body to the proxy endpoint, you must still use a POST. The authentication token of the logged in customer account is required in the request header in the same manner as all other customer API endpoints. 2. The API proxy sends the following request to Disco: Request URL: https://{clientname}.corpadmin.directscale.com/Command/ClientAPI/Associates/GetEyeColor Request Body: { associateId: 4567, authenticatedAssociateId: 1234 } Notes: The proxy API will determine the correct clientname to use on the domain of the request to Disco by looking at the passed user auth token. It has embedded in it the client the user belongs to. You should not pass an authenticatedAssociateId parameter on the post to the proxy. The proxy will add the authenticatedAssociateId parameter when it prepares to call Disco. If a call to the proxy includes this parameter, it will be overwritten by the API proxy with the logged in user Id. If a Disco API does not need this parameter, it is ignored. All Disco custom client API endpoints begin with the root level path /Command/ClientAPI. This is automatically prepended to the passed path from the proxy call. So, do not add /Command/ClientAPI to your proxy call or it will be sent to Disco as /Command/ClientAPI/Command/ClientAPI. Note on Timeout: By default, the request to Disco will timeout after 10 seconds. If you need to adjust that timeout, an optional timeout query parameter timeout may be passed on the call to the proxy. The value is the number of seconds to use for the request timeout on the call to Disco. 3. Disco returns some kind of message back to the proxy like this: Response Status Code: 200 Response Body: { Color: 'Green' } Notes: Custom client Disco API endpoints should make use of the authenticatedAssociateId parameter when they need the logged in user Id. In the case of the example above, the Disco API should check that the associateId passed is in the downline of the authenticatedAssociateId or perform whatever other security checks are prudent for the endpoint.  4. The proxy returns the data from Disco like this: Response Body: { ResponseBody: { Color : 'Green' }, ResponseStatus: 200 } Notes: The ResponseStatus is set to whatever HTTP response status code the call to the Disco endpoint returned. The ResponseBody is set to whatever response body the Disco endpoint returned. If the call to the Disco API timed out or had a TCP error, the proxy will return a 500 HTTP response with an empty response body. The Intranet logs time outs and TCP errors on the Exception Logs page. ### Standard Endpoint The standard endpoint is the first version of the proxy. It expects Disco endpoint responses in a certain format. Let's walk through what happens when a call is made to the standard endpoint. Notes from the simple endpoint apply here too except where otherwise noted. 1. Suppose the following is posted to the standard API endpoint: Request URL: https://api.directscale.com/Proxy/Associates/GetEyeColor Request Body: {associateId: 4567 } 2. The API proxy sends the following request to Disco: Request URL: https://{clientname}.corpadmin.directscale.com/Command/ClientAPI/Associates/GetEyeColor Request Body: { associateId: 4567, authenticatedAssociateId: 1234 } 3. Disco returns some kind of message back to the proxy like this: Response Status Code: 200 Response Body: { Status: 0, Message: null, Data: { Color: 'Green' } } Notes: The API proxy is expecting that the Disco endpoint will return a JSON object in the response body with the properties Status, Data and Message. 4. The proxy returns the data from Disco like this: Response Body: { ErrorMessage: null, Response: { Color: 'Green' } } Notes: The response JSON object of the API1 proxy includes two properties: ErrorMessage and Response. ErrorMessage contains the value of the Message property returned in the Disco response when the Status property is set to a non-zero value. Otherwise it will be null. Response contains the value of the Data property returned in the Disco response when the Status property is set to zero. Otherwise it will be null. If the Disco call returned a non-zero value of Status, the Intranet will log the error and the proxy will return an empty 500 HTTP response in the same manner as the simple endpoint error handling. # Unauthenticated Customers The unauthenticated proxy endpoints are called by enrollment or other sites that do not have a logged in user auth token to pass. The endpoints behave in the same manner as the authenticated customer endpoints except: No authenticatedAssociateId parameter is added to the requests to Disco because the user is not logged in. The paths of the endpoints require the name of the client be passed. Simple Endpoint: https://api.directscale.com/AnoymousProxySimple/{client}/{the rest of the path} Standard Endpoint: https://api.directscale.com/AnonymousProxy/{client}/{the rest of the path} # Authenticated Admin Users There is only one authenticated admin user proxy endpoint. It is called by custom content admin pages. The admin proxy endpoint behaves in the same manner as the authenticated customer simple endpoint except: The authenticatedAssociateId that is passed to Disco by the proxy is, of course, the Id of the logged in admin user not the Id of a logged in customer. The path of the admin endpoint is: https://api.directscale.com/Admin/Proxy/{the rest of the path} Read more: [Client API Proxy: Corporate Office (Disco)](https://developers.directscale.com/docs/disco-client-api-proxy)

From Russell: **Q**: Do we need to call `SaveCoupon` from `couponService` or not while creating a custom coupon and applying it on the order on the fly? Also, does adding a newly created coupon mean that only its couponCode should be added to the `string[]` of the `orderCoupons` object? **A**: When using the **ProcessCouponHook**. You have two options: 1. Add an existing coupon code to the `string[] CouponCodes`, then call the base functionality `func(request)`. If you use this method, the coupon code has already been set up in the system and will determine its discount amount. You are just adding to the order automatically. 2. Build your own Discount. Sometimes you want to build a discount that is different for everyone. In this case, you will run the base functionality and develop your `OrderCoupon` object. Using this method, you can create the discount amount very custom per person and order. This object asks for a `couponID`, which is looking at coupons that already exist, but you do not have to give a valid `couponID` if you don't want to. If you give it a valid `couponID,` the only thing that it will do is show that a coupon was used on this order in the UI.

Because the Client DLL is not part of the new Extension, `ServiceLocator.Instance.Logger` logs to Azure. Unfortunately, we can't provide Azure access as you would be able to access all client logs, not just your own. The new Extension logs to the ExtensionLog table. Read more: [Extension Log](https://developers.directscale.com/docs/extension-log)

From Russell: I had a question from a client about problems creating a customer through the Retail Shop. Retail and Back Office use the same authenticated call via the Angular v3Post call. In this case, the client struggled to figure out which fields were missing from the call and was running into problems with the Validation hook in Disco. Here's my response to them: On the Customer Create issue, I'm seeing missing elements on the call in, and the ValidateApplicationHook is not managing them well when they're missing. The payload you sent in that failed is missing the following two elements: 1. PrimaryPhone 2. PostalCode must be passed in on the addresses, but as "Zip". (because the Azure Gateway does the mapping from PostalCode to Zip when you have used the public API in the past. You're calling through the Retail pathway now. Here is the swagger page for API2 (retail), focused on the CreateCustomer call: https://api2.directscale.com/swagger/ui/index#!/Customers/Customers_CreateCustomer) (see payload below) **FYI**: On a CreateCustomer call from Retail, it looks like you only need to pass in "PrimaryAddress". The Retail API code creates a Disco "ShippingAddress" and "DefaultAddress" based on the Primary Address. If you want to set a shipping address differently, you'll need to call UpdateCustomer or the like, but I haven't looked into that. This is at least what I'm interpreting as I look through the code. I also recommend you do some different null checking on validation elements in the WriteApplication hook (which is called in Create Customer, too). Something about the way it's done is blowing up if something is missing (this may be an artifact because I had to decompile the code, but I think you need to check for null or missing elements before using the reflection you've set up). But, if you get those two fields added from above, it'll work fine. **Note**: this prompted the actual inclusion of the API payload. This is a little different than the public API because we do some mapping to fields you see here slightly differently. That said, it makes the same Disco call. Payload of /api/Customers/CreateCustomer (I removed the DefaultAddress and ShippingAddress because they're stripped out on their way into Corpadmin) { "BackOfficeId": "string", "BirthDate": "2021-01-18T23:14:02.081Z", "CompanyName": "string", "CustomerStatus": 0, "CustomerType": 0, "EmailAddress": "string", "ExternalReferenceId": "string", "FirstName": "string", "LanguageCode": "string", "LastName": "string", "Password": "string", "PrimaryPhone": "string", "SecondaryPhone": "string", "SendEmails": true, "SignUpDate": "2021-01-18T23:14:02.081Z", "SponsorId": 0, "TaxExemptId": "string", "TaxId": "string", "TermsAccepted": "string", "TextPhone": "string", "Username": "string", "WebAlias": "string", "RomanizedFirstName": "string", "RomanizedLastName": "string", "LegalFirstName": "string", "LegalLastName": "string" "PrimaryAddress": { "ID": 0, "Line1": "string", "Line2": "string", "Line3": "string", "City": "string", "State": "string", "Zip": "string", "CountryCode": "string" } }

From Russell: Sometimes, it's essential to know whether you're running in a Sandbox or the Live environment and to verify the Client ID of the instance you're running on. This can be done in the extension using the following: ExtensionContext is part of the SettingsService (ISettingsService), which can be injected. Once you've got the handle to SettingsService, do this: ``` string clientId = _settingsService.ExtensionContext().ClientId; // IE, "demo" DirectScale.Disco.Extension.EnvironmentType envType = _settingsService.ExtensionContext().EnvironmentType; // EnvironmentType is an enum, and can be either Sandbox or Live ``` Read more: [Verifying Extension Environment and Client ID](https://developers.directscale.com/docs/verifying-extension-environment-and-client-id)