Jump to content
  • To Search the Seeq Knowledgebase:

    button_seeq-knowledgebase.png.ec0acc75c6f5b14c9e2e09a6e4fc8d12.png.4643472239090d47c54cbcd358bd485f.png

Search the Community

Showing results for tags 'admin'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Community Technical Forums
    • General Seeq Discussions
    • Seeq Admin Forum
    • Training Resources
    • Product Suggestions
    • Seeq Data Lab
  • Community News
    • Seeq Blog Posts
    • News Articles
    • Press Releases
    • Upcoming Events
    • Resources

Categories

  • Seeq FAQs
  • Online Manual
    • General Information

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me


Company


Title


Level of Seeq User

Found 3 results

  1. A great question came in today through the support portal and I wanted to share the current best practice workflow. In the admin panel for long running requests you can click on the (+) icon and get some important additional information. For our workflow the most important of these categories is the formula Parameters. This will take the form of "series = <id>" or something similar Copy the ID from this field and open up the API Reference from the upper right hand corner. If there are multiple IDs in the parameter field pick the first. In the API Reference Docs navigate to the Items/<id> Endpoint and paste your ID from the step above and click the "Try it Out" button. Scroll down to the Scoped To section of the response and copy the <id>. This is the ID of the workbook that the calculation is scoped to The final step is to copy the workbook ID from the Step above into the get Workbooks/ID endpoint The response from this endpoint will contain a bunch of information but the most important pieces will probably be the document owner, workbook location & workbook name
  2. Seeq administrators often limit the access of people to Seeq based on an external authentication system. Some examples of this are Windows Authentication, LDAP Authentication, or the built-in Seeq authentication. These mechanisms only limit access to Seeq, not access to the datasources or items within Seeq. Here, we'll discuss how to restrict access to datasources based on user groups developed through authentication mechanisms. Step 1: Creating the group in Seeq First, we'll have to ensure the group is brought into Seeq. If using Seeq Authentication, please refer to https://seeq.atlassian.net/wiki/spaces/KB/pages/239304838/Users+and+Groups#UsersandGroups-CreatingGroups. If not, the external authentication mechanism will only bring in the groups that are the children of the groups that are allowed access. For example, if "Seeq_Users" and "Seeq_Admins" are two groups underneath "Seeq" and "Seeq" is the group allowed by the authentication mechanism, then "Seeq_Users" and "Seeq_Admins" will be brought in as groups. Note that "Seeq" will not be brought in as a group, only its members will be brought in. In the case that "Seeq" would also want to be brought in as a group, as of Seeq version R22.0.45.00, you can modify the IdentitySynchronization parameter to specify bringing in the "Seeq" group. An example configuration is shown below where the "DOMAIN\\Seeq" is being brought into Seeq as a group too. More information can be found in https://seeq.atlassian.net/wiki/spaces/KB/pages/554041498/Identity+Synchronization+using+Windows+Authentication+Connector { "Version" : "com.seeq.link.connectors.windowsauth.config.WindowsAuthConnectorConfigV1", "Connections" : [ { "Name" : "Windows Auth: grant access to only specified Windows groups", "Id" : "7393a87e-611a-4f43-b4a5-20e56f28f5d3", "Enabled" : true, "Indexing" : { "Frequency" : "1w", "OnStartupAndConfigChange" : true, "Next" : "2020-03-13T16:55:31.050979100Z[UTC]" }, "Transforms" : null, "VerboseLogging" : false, "AllowGroups" : [ "DOMAIN\\Seeq" ], "AllowUsers" : null, "IdentitySynchronization" : { "Enabled" : true, "GroupsToSync" : [ "DOMAIN\\Seeq" ] } } ], "Help" : "For examples and documentation, see https://telemetry.seeq.com/support-link/wiki/spaces/KB/pages/420053401" } Step 2: Datasource Permission After the group is available in Seeq, we can restrict who has access to the datasource. The steps listed below discuss the connector property transform approach but additional methods are discussed in https://seeq.atlassian.net/wiki/spaces/KB/pages/596607096/Datasource+Permissions. The connector property transform is applied on the connector json file located on the Seeq server or remote agent. In the example below, we are modifying all items within the datasource so the "Everyone" group has read access. Note that this security is appended to existing access control, not replacing it. "Transforms" : [ { "Inputs" : [ { "Property" : "Name", "Value" : ".*" } ], "Outputs" : [ { "Property" : "Security String", "Value" : "Auth/Seeq/Everyone:r,rd", "UnitOfMeasure" : null } ], "Enabled" : true, "Log" : false } ] The value of Security String can be applied to any group where "Auth" is the datasouceClass of the authentication mechanism, "Seeq" is the datasourceID of the connection, and "Everyone" is the dataID of the group. For Built-in Seeq Authentication, these items are based on readable names but for external authentication mechanisms these tend to be GUIDs. The datasourceClass tend to stay the same without any purposeful modifications. The table below outlines the typical configuration and their mappings. Authentication Mechanism datasourceClass Built-in Seeq Authentication Auth Windows Authentication Windows Auth LDAP Authentication LDAP OpenID Connect OAuth 2.0 The datasouceID will vary based on the connection specified in the json connector file. You can access this in the connector json file through the ID of the connection or by going to the Seeq API Reference and querying the endpoint GET /datasources with a filter for the datasourceClass. The dataID will also change for each group. There is a two part process for accessing this dataID. First, you will have to get the Seeq ID from the endpoint GET /usergroups . You can filter the query by the name of the group you're looking for. There you can copy the id. This id is located in the group json section, not in the datasource. This id should be a Seeq ID, meaning it contains uppercase alphanumeric characters. Second, you paste this id in the GET / usergroups/{userGroupId} to get the dataID of the user group, which will be located towards the bottom of the response body. With these items, you can modify the security string value and specify the level of access with r,rd being read, read data, w,wd being write and write data and m being manage. Additional groups can be separated using |
  3. Microsoft Access databases are contained in a (.mdb) file. To connect Seeq to this file, think of them like an Excel or csv file. The .mdb files must be continuously imported it into an RDBMS, most naturally MSSQL as it is in the Microsoft software family. After that, Seeq can connect to it via our SQL v2 connector. The .mdb file import can be scripted/automated/scheduled, but it is basically like bringing an arbitrary file into MSSQL. This link provides good instructions on the steps to import Access data into MSSQL: https://docs.microsoft.com/en-us/sql/integration-services/import-export-data/connect-to-an-access-data-source-sql-server-import-and-export-wizard?view=sql-server-2017 (edited)
×
×
  • Create New...