How to delete obsolete email templates?
You cannot delete email templates online. You have to delete email templates using SQL delete statement:
DELETE FROM PS_PHI_EML_TBL WHERE PHI_EML_ID = ‘<template name>’;
You cannot delete email templates online. You have to delete email templates using SQL delete statement:
DELETE FROM PS_PHI_EML_TBL WHERE PHI_EML_ID = ‘<template name>’;
When you initiate the Rollback feature in Phire, objects that do not exist in the target at the time the baseline version is taken will be automatically deleted. The driver for the action Phire takes during a rollback (either copy or delete) depends on the state of the object in the target when the baseline backup is made. If the object exists when the baseline is taken, then the action for the rollback is set to COPY. If the object does not exist when the baseline is taken, then the action for the rollback is set to DELETE.
You can view the action Phire will perform for each object when the rollback is initiated by looking at the baseline Version Set. From the CR, navigate to the “Objects” tab and click on the “View Version Set” icon below the CR Number. Click on the “Objects” link next to the Baseline backup from <TARGET>. For each object, the Action to be taken for the restore will be displayed.
One possible cause for the restore action to not be set to DELETE is if you perform multiple migrations to the same database. The rollback of the last migration will not result in the “new” objects to be deleted since those objects may not have existed when the first migration was done, however, they do exist when the last migration is performed. In this scenario, you can Restore the baseline backup taken prior to the first migration to delete the objects.
You can delete a workflow by deleting the CR Type which it is based on. That is, navigate to Step 3. Application Codes of the Domain Setup Wizard (Phire Architect > Architect Administration > Domain Setup Wizard), open the section for the Change Request Type, and delete the row. That will also remove the setup on Step 13 and 14 associated with that type.
At this time there is no on-line method of deleting a domain. But it can be done pretty easily using a SQL script that we deliver named DELETE_SETUP_DATA.SQL. This can be found in the Script folder in the original Phire download package, or by contacting Phire Technical Support.
Here’s how to handle this in Phire Architect. A developer can create a version set that is a combination of the objects in an existing Version Set and a live database by first restoring the objects from the old Version Set into the live database and then creating a new version set that is a combination of the objects from the old version set and the live database.
A workflow in Phire is derived from the Change Request Type definition. So you would first create a new CR Type, and then you can create the task list that’s associated.
So start by navigating to: Phire Architect > Architect Administration > Domain Setup Wizard, Step 3. Application Codes. In the section for Change Request Types, you can create a new type with a description. Then on Step 13. Workflow Definitions, you can create the series of tasks that make up the workflow. Alternatively, if you have an existing workflow that’s pretty close to the one you’re trying to create, you can use the Copy Workflow button after you’ve create the new CR Type value. Also, complete the setup on Step 14. Workflow Databases for the new workflow. At that point it should be ready to test and begin using the new workflow.
We deliver a role that is designed to provide a read-only view for users, which is named PHI_CR_READONLY_ROLE. Remember to setup Domain Security for the role within Phire so it can access the domain and search for Change Requests. The only permission the role needs is “Open Existing CR” to open CRs in that domain and look around.
If your Phire installation is made on a dedicated database, it would have most likely been installed onto a PeopleTools-Only SYS database. If that is the case, the default local node will be PT_LOCAL. To verify the default local node, do the following:
1. Login to the Phire application.
2. Navigate to: PeopleTools > Portal > Node Definition and click Search
3. The local default node will have “1” in the Local Node and “Y” as the “Default Local Node”.
To add content references in your Portal application to point to Phire components, follow these directions. This example shows you how you can add the Phire Architect home page as a link to your Portal application.
1. Login to Phire. Define PSFT_PA as a trusted node.
PeopleTools > Security > Security Objects > Single Signon
Add PSFT_PA as a Message Node Name and Save.
2. Login to Portal. Define PT_LOCAL as a trusted node.
PeopleTools > Security > Security Objects > Single Signon
Add PT_LOCAL as a Message Node Name and Save.
3. Specify the content URI text and Portal URI text for the PT_LOCAL node.
PeopleTools > Portal > Node Definition (Portal tab)
4. Add content reference.
PeopleTools > Portal > Structure and Content (Add Content Reference)
Node Name = PT_LOCAL
URL Type = PeopleSoft Component
Menu Name = PHI_MENU
Market = GBL
Component = PHI_HOME
Unfortunately, there is no relationship that ties the Functional Area list items to Issue Types to achieve what you described. But you definitely can do it with a “Flex Field”. You’ll just need to create a table that defines that relationship, and name it as the prompt view in the Flex Field configuration. Also, I suggest that you make it a “required” Flex Field, then it will be shown on the Help Desk version of the Issue page – otherwise it will be hidden.
We provide the ability to copy the workflow setup from one domain to another using a Data Mover script. You will find a DMS named “COPY_WORKFLOW.DMS” in the scripts folder in the Phire release package. Prior to running this script, you will need to replace the tag values that are in brackets. Also, after the workflow is copied over, be sure to define domain security for the new CR Type.