Hi Yaniv!

As @Chris Thompson mentioned you can use DSTIME for automatic records changes tracking which will be stored in a special global. But I doubt if it works for classes with non-standard storage schema just by adding DSTIME=auto;

How do you add/update records in your application? You need to introduce special calls in your "create/update" procedures to track changes. DSTIME=auto; does exactly same adding "tracking" logic in SQL and Object requests for class changes. Maybe you can use some calls with DSTIME=manual; mode.

@Alexander Koblov  do you know if it is possible to use DSTIME somehow in this case?

Another approach which may work in your case is to use AUDIT to track the changes users made to DB and then analyze this data, e.g. like here. But I never did it for non-standard storage schema.

Hi Harkirat!

You have two questions here) Answering on the limits for a particular user.

Yes, you can limit the data user see via DeepSee interfaces.

Implement the callback %OnGetFilterSpec of your Cube which will introduce an extra filter on all the queries to the cube. You can use the $User or $Role of the current user and tie it to a dimension and so filter the data, which is available to a certain user or group of users. So all your dashboards and pivots will use this extra filter to all the data sources.

HTH

Hi, Steve!

Thanks for your feedback! 

Does it have to be a Github repo or can I use BitBucket ?

It can be any public repository: Github, BitBucket or Gitlab. But today we have the embedded support only for Github. E.g. if you submit Github repo in the application OE will use README.md as description, LICENSE.md as license and we plan to introduce more support in the near future.

You can add the request for BitBucket support in Open Exchange issues.

Also - if we find an error  (eg WebTerminal on IRIS), can we leave a comment generally or for the developer ?

Every application has either repo with issues or the support link which are intended to receive feedback, bug reports, and feature requests.

If you find an error on Open Exchange, please submit it here! )

Hi, Stefan!

In this situation, I would suggest using RELEASES approach for different InterSystems Data Platforms. E.g. you can generate XML release package from the code base in git and then replace all the specific places for a given version on a build release phase. As a result you will have different XML packages for Ensemble and for InterSystems IRIS and have one code base, say in IRIS.

For example, you can see that approach @Eduard Lebedyuk used for RESTForms distribution. There are 2016.1 and 2016.2 release packages which can be installed in 2016.1 and 2016.2+ Caché or Ensemble versions respectfully.

To simplify release building I can recommend ISC.DEV utility which can export a release or patch file(upon git commits) for a given mask of classes.

HTH