Hi @asncari  I just started going through this Splunk UI Toolkit and was able to resolve the issue using the following method. There needs to be an update made in the webpack config. My setup: node -v  v21.7.1 npm -v 10.5.0 yarn -v  1.22.22 Do the following 1. Install querystring-es3 and querystring using npm npm i querystring-es3 npm i querystring 2. Update the webpack.config.js file (MyTodoList\packages\react-to-do-list\webpack.config.js) const path = require('path'); const { merge: webpackMerge } = require('webpack-merge'); const baseComponentConfig = require('@splunk/webpack-configs/component.config').default; module.exports = webpackMerge(baseComponentConfig, { entry: { ReactToDoList: path.join(__dirname, 'src/ReactToDoList.jsx'), }, output: { path: path.join(__dirname), }, resolve: { fallback: { querystring: require.resolve('querystring-es3'), }, }, });   3. Now re-run the setup steps and let it build successfully and re-link any modules and then head into the react-to-do-list and execute the yarn start:demo command your build should be successful and if you navigate to localhost:8080 you should be able to see the react app. Note: I had a socket error ERR_SOCKET_BAD_PORT NaN exception for port 8080. I updated the build.js file to enforce use of 8080 (/packages/react-to-do-list/bin/build.js)   demo: () => shell.exec('.\\node_modules\\.bin\\webpack serve --config .\\demo\\webpack.standalone.config.js --port 8080'),   If the reply helps, karma would be appreciated.  

Dear Karma,   We tried to use the suggested option. Can you please guide us where to update the file as we suspect on location where we writing Regex. Currently, we have updated windows folder on deployment server and /etc/system/local/ directory on HF level. Thanks, Suraj

There are some fields which are always present - source, sourcetype, host, _raw, _time (along with some internal Splunk's fields). But they each have their own meaning and you should be aware of the consequences if you want to fiddle with them. In your case you could most probably add a field matching the appropriate CIM field (for example the dvc_zone). It could be a calculated field (evaluated by some static lookup listing your devices and associating them with zones) or (and that's one of the cases where indexed fields are useful) an indexed field, possibly added at the initial forwarder level.

The search might get cancelled if - for example - your user exceeds resource limits. If you are trying to reproduce the issue with user with another role having differently set limits (or not having limits at all) you might not hit the same restrictions.

Yes, certain source it's a bit hard for me to override the source name, I will try to see what can be done. I was looking at source as it's one of the few fields that seems to be common across multiple models, eg network, authentication, change etc

Well, see into CIM definition and check which fields might be relevant to your use case. "zone" is a relatively vague term and can have different meanings depending on context. For example, the Network Traffic has three different "zone fields" src_zone, dest_zone and dvc_zone Of course filtering by source field is OK but it might not contain the thing you need.

Join command (which should not really be used unless as a rule of thumb; unless there is a very good reason for it and there is no other way) uses two searches. So the .csv file you're talking about must be referenced somehow withihn such search. You can't just search from a file.

It might be true. There are two important things here. 1. You can only distribute _apps_ from the deployment server. So the apps get pulled by the deployment client (in this case your UF) and put into your $SPLUNK_HOME/etc/apps directory 2. Splunk builds the "effective config" by layering all relevant config files according to precedence rules described here https://docs.splunk.com/Documentation/Splunk/latest/Admin/Wheretofindtheconfigurationfiles So depending on where the install wizard puts those settings, you might or might not be able to overwrite them with an app deployed from DS. You can check where the settings are stored by running splunk btool inputs list --debug This will show you effective config entries along with the file in which it is defined. If it's in some app/something/... file, it can be overwritten, possibly with some clever app naming in order to put the config file alphabetically before/after another app. But if it's in system/local... you can't overwrite it with an app. And that's why it's not advisable to put settings in system/local unless you're really really sure you want to do that. If you put settings there you can't overwrite it in any way later unless you manually edit the system/local/whatever.conf file on that particular Splunk component (ok, there is an exception for clustered indexers, but that's for another time).

Hey @PickleRick  2. You are absolutely right. I just tried with different users on the same accelerated model, same query but different roles, and the restricted users has much less results. So, can I say the way forward seems to be one common data model then? Is there any recommended or easy way to perform filtering between Zones in a summary search for example?  Is using Where source=ZoneA* alright then?

Thanks for the hints. In terms of data retention all the sections will have similar policy. However, access grants can be an issue. In my use case, the dashboards will be monitored by section personnel and also by the SOC. Therefore in terms of access, SOC will be able to see DMZ, ZoneA and ZoneB while the respective members of each section should only be able to see their zones (need-to-know basis policy) At the moment I am using different indexes so I can perform some transforms specific to each zones, as the syslog log sending formats are different due to the different log aggregator used by each zones. By using the different indexes in the heavy forwarder, I am able to perform some SED for particular log sources, and host & source override on the HF. I remember that I can limit access based on indexes, but I guess this is not possible with data models but will this be a concern? If I put them all in a data model, is it still possible to restrict access? For example, if the user can only manipulate views from dashboard and not be able to run searches themselves, that will still be OK. Pros and Cons in my mind: Separate data model: - Pro's: I can easily segregate the tstats query - Cons: Might be difficult to get an overview stats need to use appends and maintain each additional new zone. Each new data model will need to run periodically and increase the number of scheduled accelerations? Integrated data model: - Cons: might be harder to filter, eg between ZoneA, ZoneB and DMZ. Seems like I can filter only based on the few parameters in the model, eg source, host - Pros: Easier to maintain, as just need to add new indexes into the data model whitelist. Limit the number of Scheduled runs. - And as mentioned the point on data access? Will it be still possible to restrict? I am still quite new to Splunk so some of my thoughts might be wrong. Open to any advice, still in a conundrum.