Skip to main content

Product Ideas Pipeline

Filter by Idea Status

Filter by Topic

1343 Ideas

Gunnar AndreasSeasoned ⭐️⭐️

Full API access to inspect and update instances in ChartsGathering Interest

Today there is limited to no API access to Charts, creating several issues.One obvious issue is that we cannot automate the setup of Charts. Eg, when an anomaly detection method detects an issue, we would like to be able to auto-create the Charts with the necessary timeseries, timerange, calculations and overlay anomaly insight (CogniteActivity extension). This is not possible today (only pre-build url with instances and range).But another issue is around the maintainability of Charts. Due to the limit on the number or Views/revisions, we need to deprecate and delete old revisions on a regular basis (in particular in periods with heavy data model development). As far as I have seen, Atlas, Canvas and Chart lock the View version to the latest version (or maybe based on the location filter) during config. For Atlas agents and Canvas’ we can find the View versions via the API, allowing us to identify users depending on models that are deprecated, and also auto-duplicate with the updated versions/views. However, with Charts this is not possible. If Charts is supposed to only be a do-my-analysis-and-then-throw-it-away tool, that is ok, but if it is intended to be used for more long term analysis (it does offer functionality for this like calculations and threshold monitoring) we need a way to monitor status and update the views/instances in the Charts on an enterprise level (via API) 

tainabouzanPractitioner ⭐️⭐️⭐️

Ability to configure the PI Extractor to include ptsecurity and datasecurity attributes in the extracted metadataGathering Interest

 As a CDF Platform Administrator,I want the ability to configure the PI Extractor to include ptsecurity and datasecurity attributes in the extracted metadata,So that I can use these source-level access control lists (ACLs) to automate and enforce data access security for groups of users in Cognite Data Fusion.  Configuration OptionsGIVEN a standard PI Extractor installation,WHEN looking at the extractor configuration file (e.g., config.yml),THEN there must be a new, optional configuration parameter (e.g., include-internal-security-metadata: true/false or an override setting).GIVEN the configuration parameter is omitted or set to false,WHEN the extractor runs,THEN it must continue to exclude ptsecurity and datasecurity metadata as it currently does (default secure behavior). Extraction BehaviorGIVEN the configuration parameter is set to true,WHEN the extractor performs discovery and extracts Time Series metadata from PI,THEN the ptsecurity and datasecurity attributes must be successfully captured and populated as key-value pairs in the CDF Time Series metadata block.GIVEN the configuration parameter is set to true,WHEN a source PI point has empty or null values for these security fields,THEN the extractor should gracefully skip writing those specific keys to CDF metadata without throwing errors or halting the extraction process.

tainabouzanPractitioner ⭐️⭐️⭐️

Configurability to arrange the categories to be multilevel (tree) for SearchGathering Interest

As I solution architect I would like to arrange persistently all my categories in my landing “Search page”, in a multilevel (tree) format, with minimal 2 levels, so the “Search page” is not convoluted/big and users still have access to all their categories with minimal clicks. As of today, I see that the only categories that allow multiple levels are the ones that were “inherited” from the old resource types, such as asset, files, time series, activity. Everything else added in the data model will be available view bullets.For PBF we have several data models within the same project, what causes the search page to be very extensive and not user friendly. As a workaround, we created a solution data model and configured a new location to expose a simplified “search page”, but for that we are omitting several of the categories that users would like to see. So if the user wants to access data that is not in this simplified view he/she needs to select the “full” location that has all the data, what is a bad user experience in terms of multiple clicks.. on the other hand if we keep everything exposed it is very hard to find a category and the search page gets convoluted. In the work around we implemented, user can still change location go from the “full” location to the “simplified” location, but it requires multiple clicks, what is not desirable. A better solution would be to allow multilevel configuration for categories (parent/child relationship), so we could groups categories that are related to each other. Also the data would be more organized and friendly from the user point of view. Note: The following it is just and example to show the desirable outcome for a “look & feel” in terms of arranging data, please ignore the “material” reference, once it is not relevant.- Material  - Material Group  - Material Type  - Material Status