During TRIRIGA install, what SQL GRANT statements are executed for the install to be successful? Are there specific object names that you can grant access to TRIDATA on those objects other than granting to PUBLIC?
Granting PUBLIC access to database objects goes against security policy. The problem is that you don’t know which objects TRIRIGA might need. You need to get specific object names so that you can potentially grant access to TRIDATA on those objects, rather than granting to PUBLIC.
You might have tried to revoke public access to a database object which caused an ERROR on com.tririga.architecture.security.dataaccess.AuthenticationDAO and caused TRIRIGA to freeze while restarting TRIRIGA.
The following SQL GRANT statements are executed during TRIRIGA install…
In TRIRIGA, how do I go about changing fonts for tabs inside the Style Manager?
Out of the box, the tabs inside of forms do not specify a style class. To change the fonts, you must go to the Form Builder, modify the form, and then specify a style class in the Style Class field… After the form has a style class associated with the tab, publish the form, and then you can go inside of Style Manager to change the font of the selected style class.
[Admin: This post is related to the 01.10.17 post about finding the right color options with the Style Manager.]
How do I verify that a user has access to the TRIRIGA Admin Console? For example, the user is in the Admin group and can log into TRIRIGA, but cannot log into the Admin Console.
Users who are in the Admin group are not automatically granted access to the Admin Console. This must be manually granted. It is best to log into the Admin Console as the system user and go to the Admin User Manager. Then grant access to the user who should have access to the console. There is a listing of all the users and a radio button that shows No Access, Read Access, and Full Access. Access to the console should be limited, so not everyone in the Admin group should be granted access.
How can I revert back an IBM TRIRIGA upgrade? Is there any way to do so? I need to get prepared and revert my system to a previous state in a case where there were system problems after an IBM TRIRIGA upgrade.
There is no uninstaller or code to revert back or downgrade your current IBM TRIRIGA Application or Platform version to a previous version. You must keep a reliable and preferably offline backup of the database (cold backup), in case you need to revert to a previous version.
Important note: If you have any new user or agent transactions during the period since the backup, they will be lost when you rollback the database. Bottom line: To manually “revert” to previous IBM TRIRIGA version you must…
[Admin: This post is related to the 06.10.16 post about object labels and revisions.]
What are the concerns about stopping my database for maintenance and leaving IBM TRIRIGA JVMs (JBoss, WebLogic, WebSphere) up and running at this point? Will they be reconnecting automatically after my database is up and running again? I need to programmatically schedule database maintenance for my TRIRIGA system.
When the database is down, the application server (JBoss, WebLogic, WebSphere) will be receiving connection issues to the JDBC component and JVMs will stop responding after that. If the database comes up again, the application server will not reconnect the JVM automatically. The JVM needs to be restarted manually after that.
The best practice for database maintenance requiring database shutdown will always be to shutdown all applications and sessions connected to it BEFORE the database itself. It gives systems the time to close the ongoing transactions gracefully.
If you need to coordinate database maintenance and JVMs automatic restarts, you need to create a batch script to manage that. This is a customized script (not under IBM TRIRIGA support) that will be stopping the JVMs first, then starting the database maintenance itself (likely stopping the database first), then restarting the database and firing commands to restart the application server IBM TRIRIGA JVMs.