RT @MicroFocusEDU: Silk Performer Accredited Software Professional: Micro Focus Education Services is pleased to announce the release of it…
The SBM User fields currently use the SBM User accounts' "Name" field for search and display purposes in Single User and Multi-User Fields. In large organizations, it is common for multiple people to share the same name. In cases where the data comes into SBM via LDAP imports, there is no way to maintain a unique display name for each user unless it is stored in LDAP.
Ideally, there would be some way to have SBM control how it renders the user in the user field value lists (in at least forms and report contexts). Possible approaches could include a VDF (Value Display Format) type of mechanism that allows the mapping of different LDAP attributes (aka User, Contact and Resource attributes) into the value displayed for the user fields. Additional options for forms could include a hover over action that shows additional attributes (such as simple hover text or a contact card) which may be too large to show within the value list directly.
In our use case, we would like to have at least the business unit displayed in addition to the users name to help make the value distinct.
Ideally, the exposed values would also factor into the search results. Or better yet, allow the search to search against the other User, Contact, and Resource fields).
Currently, the Editable Grid template for listing reports does not have the Action menu option "Requery QAR Parameters" when the report contains Query at Runtime parameters. To be able to work around this limitation, a user must close and reopen the report OR first use Back to Listing, then Requery QAR Parameters (which assumes the template saved with the report). If the report was saved with the listing report template and not the editable grid template, an additional step is required to get back to the editable grid view again.
To address this, it would be preferred that "Requery QAR Parameters" was added directly to the Editable Grid Action menu when the report contains Query at Runtime parameters.
It would be preferred that when implemented, that the value shown is derived from the strings tables as is currently done in the listing report menu so that the actual string displayed can be customized if needed.
SBM allows users with the "Logon as Another User" privilege the ability to choose ANY user. In some cases, this might be an otherwise lesser privileged user who could then impersonate an administrator. As such, this feature often is only used by administrators due to concern for an abuse of this feature.
It would be ideal if there was a way to control which users a given user could impersonate. For example, a test lead might impersonate a list of test users. Or a Manager might impersonate a direct report (to set up out of office settings, delegate settings, etc). Ideally it would allow an Administrator to specify who can be impersonated. But there might be use cases where an individual could specify someone who could act on their behalf as well (like delegate, but allow for changing user settings too).
Relational fields can be created against Aux or Primary Tables. However, when using them for Primary tables, projects are often a factor. For example, if a user doesn't have permission to see items in the project, they probably shouldn't be able to see them when selecting values for a relational field against that table. Additionally, even if they have permissions, maybe the SBM Developer only wants the list of values to come from a particular project.
I could see part of this being addressed by an option in the SBM Web Admin as a field override.
The permission thing is a slighly different matter as I believe it is enforced on the advanced lookup form, but not the quick search directly on the field control.
As a customer's database needs change, it is common to have a need to copy database components such as the Application Engine or Application Repository tables from one database/schema to another and even to copy from one rdbms to another (such as SQL Server to Oracle). It would be useful to have a built in way (possibly in Configurator) to achieve this reorganization.