Advanced Schema Configuration
When creating a search type, the "Search Type" property defines the project schema (project_namespace) and name for the search type. For example, if your current project is called media then adding a new search type named "artwork" into the interface will automatically generate "media/artwork" and it will be added to the media project’s schema
Schema XML Structure
<?xml version='1.0' encoding='UTF-8'?> <schema> <search_type name='media/training_videos'/> <search_type name='media/script'/> <connect to='media/script' type='hierarchy' from='media/training_videos'/> <search_type name='media/fonts'/> </schema>
To add a new search for a different schema, all that is required is an explicit definition of the full Search Type "<project_namespace>/<name>".
For example to add an "artwork" search type in the "media" namespace, you would define the search type as "media/artwork". The specific schema information will be added to your current project only.
Advanced Access Rule Configuration
XML Access Rules
Security access rules are XML documents attached to user groups. Each user’s security clearance is based in a union of all of the rules coming from the groups they are planned to. Admin users have no rules because, by default, everything is allowed in TACTIC.
In the Groups table, the Access Rules column shows the XML rules which are automatically generated by either the TACTIC Manage Security tool or by manual editing for very specific and custom control. The default security version for TACTIC 3.7 is security version 1 and for TACTIC 3.8 is security version 2. In general, for security version 1, the access level is ranked like this from bottom up: deny < view < edit < allow. For security version 2: the access level is: view < edit < allow (where "allow" provides the most permissions).
The security version is specified in the TACTIC config file as follows:
<security> <version>2</version> </security>
Note
If no security version is specified for TACTIC 3.7, the default is security version 1. For a fresh install of TACTIC 3.8 (i.e. not an upgrade), the default is security version 2.
If upgrading from TACTIC 3.7 to 3.8, the security version will remain set at version 1 (which is the default for 3.7, since the security version is not specified).
Security Version 1
The following section applies to Security Version 1.
Access rules for the Client group: In this sample, any users in the Client group can see only a project named "game" and cannot access the side_bar items (which have been denied).
<?xml version='1.0' encoding='UTF-8'?> <rules> <rule key='admin' access='deny' group='side_bar'/> <rule key='site_admin' access='deny' group='side_bar'/> <rule key='Level_Manage' access='deny' group='side_bar'/> <rule key='levels_folder' access='deny' group='side_bar'/> <rule key='characters_folder' access='deny' group='side_bar'/> <rule key='myTactic_folder' access='deny' group='side_bar'/> <rule group='project' access='deny'/> <rule group='project" key="game" access='allow'/> </rules>
Global Rules
The global rules can be configured in the Groups page or the Groups List tab in the Manage Security page. Here is a list of the existing rules:
'view_side_bar', 'title': 'View Side Bar', 'default': 'allow' 'view_site_admin', 'title': 'View Site Admin' 'view_script_editor', 'title': 'View Script Editor' 'side_bar_schema', 'title': 'View Side Bar Schema' 'view_save_my_view', 'title': 'View and Save My Views', 'default': 'allow' 'view_private_notes', 'title': 'View Private Notes' 'view_column_manager', 'title': 'View Column Manager' 'view_template_projects', 'title': 'View Template Projects', 'default': 'deny' 'create_projects', 'title': 'Create Projects' 'export_all_csv', 'title': 'Export All CSV' 'import_csv', 'title': 'Import CSV' 'retire_delete', 'title': 'Retire and Delete'
Project level Examples
XML Examples
The following are examples of different access rules which can be used to customize group access rules. Make sure the <rule/> tag is a child of the <rules/> tag.
Project level Examples
This rule denies access to all projects except for the "sample3d" project. In the following example, the "default" project is a home page the user needs to use to select projects. Because it is part of the group, you must explicitly allow viewing access to this default project when you deny access to all projects. It is also needed for XML-RPC communication to the client computer.
<rules> <rule group='project' default='deny'/> <rule group='project' key='sample3d' access='allow'/> <rule group='project' key='default' access='view'/> </rules>
All projects can be viewed by default.
<rule group='project' default='view'/>
Search Type level Examples
The layer search type is not viewable in all projects
<rule group='sobject' search_type='prod/layer' project='*' access='deny'/> or <rule group='sobject' search_type='prod/layer' access='deny'/>
The task search type is not viewable in project sample3d. Note that this is not the same as tasks assigned in project sample3d is not viewable. It merely restricts the user’s ability to view tasks when he is in a particular project.
<rule group='sobject' search_type='sthpw/task' project='sample3d' access='deny'/>
The note search type is not viewable in project sample3d.
<rule group='sobject' search_type='sthpw/note' project='sample3d' access='deny'/>
The note search type is not editable in project sample3d. This currently only applies to the main TableLayoutWdg used in most places. NoteSheetWdg and DiscussionWdg which also handle note entry are not bound by this rule.
<rule group='sobject' search_type='sthpw/note' project='sample3d' access='view'/>
The shot search type is editable in project sample3d
<rule group='sobject' search_type='prod/shot' project='sample3d' access='edit'/>
The 3d Asset search type from project sample3d is not viewable. This is also applicable when you are in a different project looking at a task in sample3d and the parent of which happens to be a 3d Asset in project sample3d.
<rule group='sobject' search_type='prod/asset' project='sample3d' access='deny'/>
User Interface Column level Examples
These examples affect the display of the columns in different views
The 3d Asset search type’s code and description are not editable in all projects
<rule group='element' search_type='prod/asset' key='code' access='view'/> <rule group='element' search_type='prod/asset' key='description' access='view'/>
The Shot search type’s status is not editable in the sample3d project
<rule group='element' search_type='prod/shot' key='status' access='view' project='sample3d/>
The Shot search type’s description is not visible in the sample3d project
<rule group='element' search_type='prod/shot' key='description' access='deny' project='sample3d/>
Database level Examples
While Search Type and Search Type Column level examples affect the display of the main TableLayoutWdg and EditWdg, the following database level examples are applied when attempts are made to edit or insert data into the database. It can block even server or client API script access to the databases.
This rule prevents the display and writing of the "is_current" field for snapshots found in the Checkin History.
DEPRECATED and UNSUPPORTED format:
<rule group='sobject|column' key='sthpw/snapshot|is_current' access='deny'/>
New format:
<rule group='sobject_column' search_type='sthpw/snapshot' column='is_current' access='deny'/>
The description column for Shot cannot be edited in any widget or any script. It is view only.
<rule group='sobject_column' column='description' search_type='prod/shot' access='view'/>
The status column for Task cannot be edited in any widget or any script. It is view only.
<rule group='sobject_column' column='status' search_type='sthpw/task' access='view'/>
The custom sType project/asset is view-only and not editable by a particular group.
<rule group='sobject' search_type='project/asset' access='view'/>
The custom sType project/asset is not viewable by a particular group. The search result will always come up empty.
<rule group='sobject' search_type='project/asset' access='deny'/>
Search Filter Examples
To enforce what can be searched or filtered out in any situation like script query or UI view, search_filter rules can be applied. The access attribute is not required here.
This rule filters out tasks belonging to project "pacman" and "sample3d". Notice you don’t need "access" here.
<rule group='search_filter' column='project_code' value='pacman' op='!=' search_type='sthpw/task' /> <rule group='search_filter' column='project_code' value='sample3d' op='!=' search_type='sthpw/task' />
This rule retrieves task that is assigned to the current login user, applicable when navigating in project sample3d. Notice the value attribute can accept an expression. $LOGIN and $PROJECT are also supported.
<rule column='assigned' value='@GET(login.login)' search_type='sthpw/task' op='=' group='search_filter' project='sample3d'/> or <rule column='assigned' value='$LOGIN' search_type='sthpw/task' op='=' group='search_filter' project='sample3d'/>
Miscellaneous Examples
This rule blocks a user from seeing the options "Approved" and "Complete" in the task status drop-down
<rule access='deny' key='Complete' category='process_select'/> <rule access='deny' key='Approved' category='process_select'/>
Security Version 2
The following are examples of how to fine tune control access to TACTIC in security version 2. (Some of these example may be repeated in security version 1 above.)
Project Access:
This allows the group to see the project with the code "toy_factory".
<rules> </rules>
Link Access:
This allows the group to see the link named "block_set_list" in the project named "toy_factory".
<rules> <rule group="project" code="toy_factory" access="allow"/> </rules>
sType (Search Type) Access:
This allows the group
to see the sType "toy_factory/design" in the project named "toy_factory".
to hide the sType "sthpw/task" in the project named "toy_factory".
<rules> <rule group="project" code="toy_factory" access="allow"/> <rule group="link" element="block_set_list" project="toy_factory" access="allow"/> </rules>
Process Access:
This allows the group to see the process named "packaging" in the project named "toy_factory".
<rules> <rule group="project" code="toy_factory" access="allow"/> <rule group="link" element="block_set_list" project="toy_factory" access="allow"/> <rule group="search_type" code="toy_factory/design" project="toy_factory" access="allow"/> <rule group="search_type" code="sthpw/task" project="toy_factory" access="deny"/> </rules>
User Interface Column level Access:
This allows the group to:
-view the element description
-edit the element name
<rules> <rule group="project" code="toy_factory" access="allow"/> <rule group="link" element="block_set_list" project="toy_factory" access="allow"/> <rule group="search_type" code="toy_factory/design" project="toy_factory" access="allow"/> <rule group="search_type" code="sthpw/task" project="toy_factory" access="deny"/> <rule group="process" process="packaging" project="toy_factory" access="allow"/> </rules>
There is no user interface in TACTIC to remove a project. This is because the complete removal of a project has some pretty significant consequences. When a project is created, a number of elements are created. These are listed below.
Note
This task may need to be carried out by the Tactic System Admin as it involves manually accessing both the Tactic File system and the Tactic Database
In all of the following examples, <project_code> represents the code of the project when the project was created.
A complete removal of a project should be handled with care. This is most often desirably when a project has been created in properly. It is one of the few operations that is not undo-able in TACTIC, so it is recommended to be careful when proceeding with the following steps. It is also recommended that a complete backup of TACTIC is performed before carrying out this process.
Remove the project directory
cd <project_install_dir>/sites rm -rf <project_code>
Remove the database
psql -U postgres sthpw drop database "<project_code>";
Remove the assets directory
cd <project_asset_dir> rm -rf <project_code>
Remove the entry in the projects table in the database
psql -U postgres sthpw delete from project where code='<project_code>';
Remove connected entities in the sthpw database;
In this process, Tactic may not allow removing a particular project due to there being child tasks, notes, snapshots, files, wdg_settings etc. If Tactic denies revoval because, for example there is a connection in the file table, you will need to do the following
delete from file where project_code='<project_code>'; delete from snapshot where project_code='<project_code>'; delete from task where project_code='<project_code>'; delete from note where project_code='<project_code>'; delete from wdg_settings where project_code='<project_code>'; delete from pref_setting where project_code='<project_code>';