Support Forum

[admin]

What's new:

1) Now TrackStudio support templates-configurations. You can create configuration (workflows, categories, users, tasks, permissions) using server manager and move them between server. Configuration is just difference between old saved XML exoirt and current database state.
2) If only one category is available for user - it will be default in the "Create a task or a project" pulldown.
3) If user have no subordinates or task have no subtasks TrackStudio will jump to Task/User page, instead of Subtasks/User List.
4) SVN diff now with changes highlighting.
5) Enter in editor don't add empty line now.
6) You can set login/password in URL directly now:

Code: Select all

http://trackstudio.company.com/TrackStudio/task/123?autologin=login&autopassword=password


7) E-mail notification template imporovement: use the following to attach files to e-mail:

Code: Select all

<#-- includeAttachments-->


Many bugs were fixed, especially related to Opera Browser.

[vadimk]

1) Now TrackStudio support templates-configurations. You can create configuration (workflows, categories, users, tasks, permissions) using server manager and move them between server. Configuration is just difference between old saved XML exoirt and current database state.

What about moving the configurations between different "roots" on the same server? What about reports and filters?

[admin]

What about moving the configurations between different "roots" on the same server?

But TrackStudio configuration is just an XML file, you can edit it yourself, replace IDs of external objects to new values and import it on another server with different root.

What about reports and filters?

No problems, TrackStudio will import all objects.

This means, that this feature can be quite usable for copy/paste configuration between projects, but some (minor) XML editing can be required.

[vadimk]

But TrackStudio configuration is just an XML file, you can edit it yourself, replace IDs of external objects to new values and import it on another server with different root.

I am trying to find an alternative to the method how I am replicating my project structures within the same instance of TrackStudio (by roots I mean different parent tasks - what I have under parent "Template" I need to replicate under parent "Project A").

Is this mechanism (exporting configuration to XML, importing configuration from XML) available through API?
Will it be possible to specify which objects to include to export / import and which not (apart from removing them from XML manally)?

[admin]

I am trying to find an alternative to the method how I am replicating my project structures within the same instance of TrackStudio (by roots I mean different parent tasks - what I have under parent "Template" I need to replicate under parent "Project A").

Yes, I remember.

Is this mechanism (exporting configuration to XML, importing configuration from XML) available through API?

No, this is feature of server manager, which have no external API.

Will it be possible to specify which objects to include to export / import and which not (apart from removing them from XML manally)?

Comment them in XML ?

This is very new feature, which have many possibilities, but we still not sure who and how will use it. Please try to play with it and tell us how to improve.

[vadimk]

This is very new feature, which have many possibilities, but we still not sure who and how will use it. Please try to play with it and tell us how to improve.

I am using WAR configuration. Do I have the server manager? How else I can access the configuration templates.

[admin]

This is very new feature, which have many possibilities, but we still not sure who and how will use it. Please try to play with it and tell us how to improve.

I am using WAR configuration. Do I have the server manager? How else I can access the configuration templates.

No, it's supplied with SA only. But you can install SA somewhere and connect to the same database - it should work.

[vadimk]

You are suggesting to have 2 instances of TS against the same database.
When I first time start the second instance will it alter the database, which would affect the original instance in any kind?

[vadimk]

Just installed SA version and played a bit with the test database (in fact just took a look into the configuration management and the base configuration file (/etc/sql/en.xml).

From what I see is the good dump of the database tables that contain the needed configuration. It shold serve well when migrating to the new database (between test database and production database - a very valuable tool indeed).

But applying this to the target issue of cloning pieces of the existing database - I am not sure how useful it is going to become.

Here are pros and cons:
* the obvious value is to list ALL tables that are related to the configuration (about 10% of saved effort comparing to what I was doing my cloning script)
* when preparing the project template I would need to manually strip off XML nodes for records attached outside the template task (10-25% of effort when I was doing my cloning script; additional 20% of effort comparing to same logic if done in relational database)
* when importing hopefully the configuration management would merge / append configuration records without removing records not found in the XML file (showstopper if not)
* the problem would still remain of remapping GUIDs - basically the part of the configuration management would be to generate the import configuration template from the seed template, which would include producing the new XML from the pre-existing XML, and generate and properly propagate all GUIDs changes (about 50% of effort in the cloning script)
* the obvious value of database independence (but it is mostly value for you - I always use and will use SQL Server)
* another value is stability - instead of going after the details of database structure (including ways of handling long text) using this method would allow to abstract the logic and stay reliable (reliability + 10% of saved effort)
* the issue where I failed with my cloning script is cloning filter definitions since very special internal structure that needs to be parsed espocially in cases of UDFs; preparing the new filter definitions would require as much effort to update it in XML as inside the database itself (failed effort, but took about 10% of effort while I was working on my cloning script)
* both methods would require the server restarts after executing; however, going after database could be programmable while using ServerManager is the multi-step manual activity - assuming the pre-existing XML is prepared the first step would be running the process to clone XML and then there will be manual step of using configuration management to apply it; and the third step would be to restart the run-time environment

[admin]

* when preparing the project template I would need to manually strip off XML nodes for records attached outside the template task (10-25% of effort when I was doing my cloning script; additional 20% of effort comparing to same logic if done in relational database)

Ideally, this shouldn't be too complex - "configuration" shouldn't have major external dependency. I expect, that parent task GUID/parent user GUID will be enough for most cases, and it's simple to remap them using text search/replace in XML file.

* when importing hopefully the configuration management would merge / append configuration records without removing records not found in the XML file (showstopper if not)

Yes, it's just add new values and don't touch existing.

* the problem would still remain of remapping GUIDs - basically the part of the configuration management would be to generate the import configuration template from the seed template, which would include producing the new XML from the pre-existing XML, and generate and properly propagate all GUIDs changes (about 50% of effort in the cloning script)

Yes, problem will occurs if you apply config to the same database. The good news - remapper can be text processing utility, which parse XML, search for GUID and replace each GUID to another one.

* the obvious value of database independence (but it is mostly value for you - I always use and will use SQL Server)

Yes, we rarely have DBMS specific problems.

* another value is stability - instead of going after the details of database structure (including ways of handling long text) using this method would allow to abstract the logic and stay reliable (reliability + 10% of saved effort)

ok

* the issue where I failed with my cloning script is cloning filter definitions since very special internal structure that needs to be parsed espocially in cases of UDFs; preparing the new filter definitions would require as much effort to update it in XML as inside the database itself (failed effort, but took about 10% of effort while I was working on my cloning script)

Can copy/paste GUIDs in text XML file help there ?

* both methods would require the server restarts after executing; however, going after database could be programmable while using ServerManager is the multi-step manual activity - assuming the pre-existing XML is prepared the first step would be running the process to clone XML and then there will be manual step of using configuration management to apply it; and the third step would be to restart the run-time environment

Yes, it's difficult to modify DB this way because TS store a lot in internal caches/buffers, we cannot update in-memory structures after database changes.