Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Download Release Notes

<< Alps << Alps HF01 << Alps SP1 << Alps SP1 HF01 << Alps SP1 HF02 << Alps SP1 HF03 << Alps SP1 HF04 << Alps SP1 HF05 << Alps SP1 HF06 << Alps SP1 HF07 << Alps SP1 HF08 << Alps SP1 HF09 

 

Customer Fixed Issues and Known Issues

Customer Fixed Issues

This section describes the issues reported by the customers and their fixes in the release, ALPS SP1 HF10. 

#

Issue

Resolution

62598 

Post upgrade of the Windows Operating System, the build number was not getting discovered properly. An incorrect version number was displayed under the Version column of the Software Discovery tab on the ASSET DETAILS page (Asset > User > Manage Asset > Asset Inventory > Under the SELECT THE ASSET TYPE section, click FIXED icon > Click an Asset ID > Click the Software Discovery).

Example: Instead of displaying the Windows OS version as 10.0.18362-64-bit, the Application was displaying the value as OS version--64.

Now, the Windows Operating System build number is discovered properly. The correct version number is displayed under the Version column of the Software Discovery tab on the ASSET DETAILS page.

This issue is fixed in the SummitAI Asset Management Agent (SAM) 2.0.4.29 onward.

67665 

On the NEW CHANGE RECORD page, the Analyst was able to log a CR even though the Planned Start Time was less than the CR log time.

Example: If the Planned Start Time was displayed as 22-04-2020 13:30 and the current time while logging the CR was 22-04-2020 13:35, even then, the Analyst was able to create the CR.

Bug Reproduction Steps:

  1. Log into the Application.
  2. Click Change > User > New Change Record.
  3. Provide data in all the fields.
  4. Verify the time displayed in the Planned Start Time field and the current time.

Now, the Analysts cannot log a CR if the Planned Start Time is less than the CR log time.

66101

Updated field value was not displaying on the CI ID page when Owner Workgroup field was updated on the CI ID page using a related Change Record.

Note:

A related Change Record (CR) should be created for modifying a CI. After the related CR is moved to the Implemented status, the linked CI can be modified.

Bug Reproduction Step:

  1. Log into the Application.
  2. Select CMDB > User > Configuration Item List
  3. On the CONFIGURATION ITEM LIST page open the CI ID for which you want to update the Owner Workgroup.
  4. Select RELATIONSHIP tab.
  5. Click Create drop-down and select Change.
  6. On the NEW CHANGE RECORD page, provide data in all the fields and click SUBMIT.
  7. Update the newly created related CR’s status to Implemented.
  8. Select CMDB > User > Configuration Item List
  9. Click the same CI ID for which CR is created to update the Owner Workgroup.
  10. On the CI ID page, update the Owner Workgroup field and click SUBMIT.

Now, the updated field value is displaying on the CI ID page when any field is updated on the CI ID page using a related Change Record.

67556 

The Auto Closure functionality was not working for a few of the Incidents and Service Requests when Time Zone was not set for the user who logged them. Also, the Status of a few of the Incidents and Service Requests was not getting updated from Resolved to Closed. This issue was occurring as the Application could not find the GMT and location of the user. Also, the default GMT was not auto applied to the user when the Location was not configured for the user. 

Now, the Auto Closure functionality for the Incident and Service Requests is working as expected even if the Time Zone is not mapped for the user. Also, if the Location is not configured for the user, the default GMT is auto applied based on the AD sync code. Accordingly, the Incidents and Service Requests are auto closed, and the Status of the Incident/SR is updated from Resolved to Closed. 

69058 

On the FEEDBACK MODERATION LIST page, the pagination was not working. Due to this, the user was not able to navigate and view the records displayed on the other pages.

Prerequisite:

Configure the Feedback Moderation. For more information, see Configuring Feedback.

Bug Reproduction Steps:

  1. Log into the Application as Feedback Moderator.
  2. Select Incident > Configuration > Others > Feedback Configuration.
  3. On the FEEDBACK CONFIGURATION page, try to navigate the multiple pages of records using pagination.
  4. Records displayed on the first page are replicated on all the other pages.

Now, on the FEEDBACK MODERATION LIST page, the pagination is working as expected and the user can navigate to the other pages and view the records.

68972 

On the AUTO ESCALATION DETAILS page, the Administrator was not able to create multiple Auto Escalation configurations for the Service Request module if an Auto Escalation was already configured for the same set of Workgroup, Location, and Customer. Due to this, the Administrators had to disable the existing configuration to add a new configuration.

Bug Reproduction Steps:

  1. Log into the Application.
  2. Click Admin > Advanced > Productivity > Escalations > Auto Escalations.
  3. On the AUTO ESCALATION page, select Module as Service Request on the FILTERS pop-up page and click SUBMIT.
  4. On the AUTO ESCALATION page under the LIST - SERVICE REQUEST section, click on an existing Escalation configuration.
  5. Configure a new Escalation for the same set of Workgroup, Location, and Customer Click SUBMIT.
  6. The new Escalation configuration is not getting submitted.

Now, the Administrators can configure multiple Auto Escalation configurations for the same set of Workgroup, Location, and Customer.

64550 

On the New Service Request page, the End Users were able to log an SR using a Service Catalog to which a Workgroup was mapped, where the Workgroup was not having any mapped Analysts.

Note:

The issue was found in the SummitAI web application only.

Prerequisites

Configure a Catalog using a Workgroup with no Analysts mapped to the Workgroup. Publish the Catalog.

Bug Reproduction Steps:

  1. Log into the SummitAI web application.
  2. Click Request > User > New Service Request.
  3. On the New Service Request page, select a Tenant and click the same Service Catalog, which is created and published in the prerequisites section.
  4. On the New Service Request page, provide data in all the other fields. Click SUBMIT.
  5. A Service Request is logged successfully even though no Analyst is mapped to the selected Service Catalog Workgroup.

 

Following enhancements are made in the SummitAI web application to ensure that there are no Service Catalogs mapped to Workgroups, which do not have any Analysts.

  • The Application does not allow the Service Catalog Approvers to approve Service Catalogs, which are mapped to Workgroups with no Analysts. A validation message is displayed.
  • The Application does not allow the Administrators to remove the last Analyst from a Workgroup, which is mapped to a Service Catalog. A validation message is displayed.

The above controls are for the new configurations.  

Note:

  • The End Users can continue to log SRs for the existing Service Catalogs with Workgroups having no Analysts.
  • It is recommended to revise all such Service Catalogs, which have Workgroups with no Analysts mapped to them. For all such Workgroups, at least one Analyst should be mapped.

68005 

On the Analyst Workload pop-up page, the user was not able to view the Service Requests that were in In-Progress and Pending statuses. Due to this, the workload of the Analyst could not be estimated.

Bug Reproduction Steps:

  1. Log into the Application.
  2. Click Request > User > Manage Service Requests > Service Request List.
  3. On the SERVICE REQUEST LIST page, click an SR id.
  4. On the Service Request Details page under the GENERAL tab, click Assigned To icon. 
  5. On the Analyst Workload pop-up page, the Service Requests with In-Progress and Pending statuses are not displayed.

Now, on the Analyst Workload pop-up page, the user can view the Service Requests that are in In-Progress and Pending statuses and estimate the overall workload of the Analyst.

 

69402 

Duplicate Incidents were getting created due to multiple clicks on the SUBMIT button while logging a new Incident. This issue was occurring when the SUBMIT button was not getting disabled on the New Incident page after an Incident was created.

Bug Reproduction Steps:

  1. Log into the Application.
  2. Select Incident > User > New Incident.
  3. On the New Incident page, select a Tenant and specify the required details under the Details section. Click on the SUBMIT button multiple times.
  4. Select Incident > User > Manage Incidents > Incident List.
  5. On the INCIDENT LIST page, click Filters on the ACTIONS panel and specify the details of the same incident that is logged in step 3. Click SUBMIT.
  6. On the INCIDENT LIST page, multiple Incidents with the same details are logged.

Now, on the New Incident page, when the End User clicks the SUBMIT button, an Incident is logged, and the SUBMIT button is disabled.

68452 

The Response Time was not getting captured in the Change History of the SRs when an Analyst was assigning the SR to self, using the Assign to Me icon on the SERVICE REQUEST LIST page.

However, after changing the SR Status from New > In-Progress > Assigned > In-Progress and Service Window, the Response Time was getting captured in the Change History.

Bug Reproduction Steps:

  1. Log into the Application as an Analyst.
  2. Select Request > User > Manage Service Requests > Service Request List.
  3. On the SERVICE REQUEST LIST page, click Filters and select Status as New. Click SUBMIT.
  4. On the SERVICE REQUEST LIST page, click Assign to Me icon on the SR ID columns. Click OK.
  5. On the Service Request Details page, click CHANGE HISTORY icon on the ACTIONS panel.
  6. The Response Time is not captured on the CHANGE HISTORY pop-up page under the Service Request History section.

Now, the Response Time is getting captured in the Change History after an Analyst assigns the SR to self, using the Assign to Me icon.

 

Known Issues

This section describes the known issues detected by the SummitAI Dev and QA team in the release, Alps SP1 HF10.

Issue

Consider a scenario where an Asset is first allocated to Multiple Users without Maker-Checker configuration and deallocated with Maker-Checker configuration. Again, the same Asset is allocated to Single User without Maker-Checker configuration. The Asset is displayed in the In-Store list instead of getting displayed in the Allocated Asset list., (#70998)

Bug Reproduction Steps:

  1. Log into the Application.
  2. Make sure that the Maker Checker configuration is disabled on the TENANT
  3. Add an Asset. For more information on adding an Asset, see Adding Fixed Assets.
  4. Select Asset > User > Manage Assets > Asset Inventory.
  5. Click FIXED on the ASSET INVENTORY On the FIXED ASSET page, click In-Store count.
  6. On the FIXED ASSET list page, select the check box corresponding to the Asset and click ALLOCATE on the ACTIONS
  7. On the ALLOCATE FIXED ASSETS page, under the ALLOCATION DETAILS section, select Multiple User in the Allocate To field and specify other fields. Click SUBMIT.
    Example:

    Allocate the Asset to multiple Users, such as sam.123@symphonysummit.com, and john.1@symphonysummit.com.

  8. On the TENANT page, enable the Maker Checker configuration.
  9. Select Asset > User > Manage Assets > Asset Inventory.
  10. Click FIXED on the ASSET INVENTORY On the FIXED ASSET page, specify the filter criteria and search the same Asset that is Allocated in steps 4 to 7. Click SUBMIT.
  11. On the FIXED ASSET list page, select the check box corresponding to the Asset and click DEALLOCATE on the ACTIONS panel.
  12. On the DEALLOCATE FIXED ASSET page, specify the required fields and click In-Store count.
  13. Make sure that the Asset Deallocation request is sent for approval on the Maker-Checker Approval page.
  14. Log into the Application as Checker Approver.
  15. Approve the Asset on the MAKER-CHECKER ASSET APPROVAL For more information on approving Maker-Checker Asset, see Approving Asset Using Maker-checker.
  16. Log out and log into the Application as an Administrator.
  17. On the TENANT page, disable the Maker-Checker configuration.
  18. Select Asset > User > Manage Assets > Asset Inventory.
  19. Click FIXED on the ASSET INVENTORY On the FIXED ASSET page, click In Store count.
  20. On the FIXED ASSET list page, select the check box corresponding to the same Asset that was allocated to Multiple Users and click ALLOCATE on the ACTIONS panel.
  21. On the ALLOCATE FIXED ASSETS page, under the ALLOCATION DETAILS section, select Single User in the Allocate To field and specify other fields. Click SUBMIT. 
  22. On the FIXED ASSET page, specify the filter criteria for Status as Allocated and click SUBMIT.
  23. On the FIXED ASSET page, the Asset is not displaying in the Allocated Assets list.
  24. On the FIXED ASSET page, specify the filter criteria for Status as In-Store and click SUBMIT.
  25. On the FIXED ASSET page, the Asset is displaying in the In-Store Asset list.

The Incident Description is getting cropped when an Analyst (with edit-rights) is editing the Incident Description using the Google Chrome browser. (#69984)

Bug Reproduction Steps:

  1. Log into the Application as an Administrator.
  2. Select Admin > Basic > Infrastructure > Tenant.
  3. On the TENANT page, specify the Filters criteria.
  4. On the TENANT LIST page, select a Tenant and click CONFIGURE DETAILS under ACTIONS panel.
  5. Select INCIDENT MANAGEMENT under MODULES and select Allow Analyst to Edit Description check box under the For Analyst section.
  6. Log into the Application as an End User.
  7. Select Incident > User > New Incident.

  8. On the New Incident page, in the Description fields enter text and an image copied from Web or other sources. Specify the other fields and click SUBMIT.

    Note:

    Make sure that the Description field includes both an image and text.

  9. Log into the Application as an Analyst using the Google Chrome browser.
  10. Select Incident > User > Manage Incidents > Incident List.
  11. On the INCIDENT LIST page, specify the Filter criteria and open the same Incident.
  12. Verify the Description field content. The Incident description is getting cropped.

The Username, E-mail ID, Emp Id, and values for few of the columns are not displayed in the columns under the DEALLOCATED ASSETS section on the ASSET DETAILS pop-up page when the Checker refers back Assets of Deallocation Transaction type.(#67805)

Precondition:

  1. Make sure that the Asset is allocated to Single User with Maker-checker.
  2. Make sure that the Asset is sent for Deallocation and Checker refers back the Asset.

Bug Reproduction Steps:

  1. Log into the Application.
  2. Select Reports > Asset >Maker-checker Dashboard.
  3. On the FILTERS pop-up page, select a Tenant, Location, and specify Referred Back in the Status. Click SUBMIT.
  4. On the MAKER-CHECKER DASHBOARD page, click Deallocated count hyperlink.
  5. Check the Username and E-mail ID for the Asset. The Username, Email ID, Emp id and values for few of the columns are not displaying under the DEALLOCATED ASSETS section on the ASSET DETAILS pop-up page

On the FIXED ASSET INVENTORY page, only added Assets with Maker Checker configuration are displayed when Referred Back is selected in the Checker Status drop-down list on the FILTERS pop-up page. (#65848).

Required configuration:

  1. Log into the Application
  2. Select Admin > Infrastructure > Tenant.
  3. On the TENANT LIST page, select a Tenant.
  4. On the TENANT page, click CONFIGURE DETAILS under ACTIONS panel.
  5. Select ASSET MANAGEMENT under MODULES.
  6. Select Enable Maker-Checker check box.

 Bug Reproduction Steps:

  1. Select Asset > Manage Assets > Asset Inventory.
  2. On the ASSET INVENTORY page, select FIXED under SELECT THE ASSET TYPE.
  3. On the FIXED ASSET page, select a Tenant.
  4. On the FILTERS pop-up page, select Referred Back in the Checker Status drop-down list. Only the added Assets with Maker Checker configuration are displayed.

On the ADMIN DETAILS page (Admin > Advanced > Password Management > Administrator > Click ADD NEW on the ACTIONS panel > Specify all the details > Click SUBMIT > Select the Domain Name on the LIST page), the Password field is not displaying the GUID or Encrypted ID of the password and the field is empty. This issue is found when the user is logging into the SummitAI application using Microsoft Internet Explorer browser.

On the Incident Management FORM BUILDER page (Admin > FORM BUILDER > Select a Tenant > Select Module as Incident Management > Click Add on Actions panel> Select Display At as Additional Information or General Area or TFS Area > Click Next), when a user configures single Parent and multiple Child using Common Master, the collective values of both Child 1 and Child 2 are displayed in Child 1 and Child 2 drop-down lists.

On the Service Request Management FORM BUILDER page (Admin > FORM BUILDER > Select a Tenant > Select Module as Service Request > Click Add on Actions panel> Select Display At as Additional Information or General Area or TFS Area > Click Next), when a user configures single Parent and Multiple Child using Common Master, the collective values of both Child 1 and Child 2 are displayed in Child 1 and Child 2 drop-down lists.

Overlapping of content is observed on the Pagination bar of all the pages having lot of records (typically in the range of 5 digits).

The configured Bulletin Board (Admin > Advanced > Notifications > Bulletin Board > Select the Tenant > Click ADD NEW to configure the Bulletin details > Click SUBMIT) is displayed on the END USER DASHBOARD page even if the user does not have access to the selected Tenant and Domain.

Broken image of the logo is displayed in the application when the logo image is deleted from the APPLICATION SETTINGS page (Admin > Basic > Infrastructure > Application Settings).


Workaround: The users need to re-login to the SummitAI application after deleting the logo.

On the AUTO-RESOLUTION SERVICE REQUEST CONFIGURATION and AUTO-RESOLUTION INCIDENT CONFIGURATION page (Admin > Basic > Infrastructure > Tenant > Select Domain > Select Tenant which is configured with Service Request/ Incident Management module > Click CONFIGURE DETAILS on the ACTIONS panel > Under the For End Users tab, select a reason form the Enable Reminder to Callers for Pending Reasons drop-down list > Enable Auto-Resolve Service Requests/ Auto-Resolve Incidents check box > Click Set Fields for Auto-Resolving Service Requests/ Set Fields for Auto-Resolving Incidents link), the users can set the auto-resolution criteria by specifying only white space (not numbers and alphabets) in the Response SLA Reason, Resolution SLA Reason, and Solution fields.

The following issues are observed in BI Custom Reports:

  • When a user downloads the report (in any format), the data is displayed with hyperlinks.
  • When a user places the mouse cursor on the count link, the tooltip is displayed as [Object Object].
  • In the exported report, report name is displayed with '+' instead of space.

The Change Record is not created when the CR Requester and Customer Approver are same. This issue occurs even though Do Not allow Customer Approval of CR check box is selected on the Change Management TENANT configuration page. This issue occurs only for the first time when the Tenant is configured.

Workaround: The Administrator needs to unselect and again select the Do Not allow Customer Approval of CR on the Change Management TENANT configuration page (Admin > Basic > Infrastructure > Tenant > Select the respective Tenant for which this issue is occurring > Click CONFIGURE DETAILS on the ACTIONS panel > Enable Do Not allow Customer Approval of CR check box and click SUBMIT > Clear Do Not allow Customer Approval of CR check box and then click SUBMIT, again).

The new SLA Value of an Incident is not displayed on the CHANGE HISTORY pop-up page (Incident > User > Manage Incidents > Incident List > Select the required Incident ID from the list > Click CHANGE HISTORY on the ACTIONS to view the change history of the selected Incident) when an incident is moved from New status to In-Progress using Notification Services.

The Pending Reason of an incident is still displayed on the CHANGE HISTORY pop-up page (Incident > User > Manage Incidents > Incident List > Select the required Incident ID from the list > Click CHANGE HISTORY on the ACTIONS to view the change history of the selected Incident), when an Orchestration Script fails and the respective Incident is moved back from Pending to In-Progress.

The notification e-mails related to escalation and jobs are triggered only in English language irrespective of the configured language on the NOTIFICATION TEMPLATE page for all the modules (Admin> Advanced> Notification> Notification Template> Select a Tenant > Click ADD NEW > Specify all the required fields > Click SUBMIT).

   

  • No labels