Currently, we have two teams each with a domain ID they own. Team A has domain ID DM1 and Team B has DM2. Team A can only search for the change requests under their domain ID. Is there a way for Team A to search for the change requests under Team B’s domain ID?
Is there a way to remove the – from the CR Name? For instance – Our Domain name is FMS92. When we create a CR our CR is FMS90-XXXXXXX
Is there a way to NOT have the – in the CR Name?
What is the difference between CR type and Issue type?
What are the these options used for? Do they prevent users from making object or script changes?
This is in reference to the component found at Phire Architect > Change Requests > CR Workflow Reset. It is designed to reset an open CR to the currently configured workflow setup.
Here is when you SHOULD use this component: If you have made changes to the workflow steps and you want those changes to be reflected in an open CR.
As many Phire administrators know, some changes to the workflow only affect newly created CRs. Workflow changes made on page 13 of the Domain Setup Wizard are primarily what this is referring to, including: the number and sequence of tasks, fail/skip options on tasks, default assignments and task trigger. Most other changes take effect universally for all CRs without needing to reset, including changes to email setup, task assignment queue, workflow databases, security and database/server credentials.
Resetting the workflow preserves most of the history and status of a CR, but it is a harsh step to take in some ways. Because all of the task level detail is removed and reloaded, there is some loss of data to be expected, including manual task assignments and task-level comments. Tasks are reset and assignments redone as if starting the CR from scratch. However, everything else is retained including CR-level history, objects and version history, migration and script history.
Here is when you SHOULD NOT use this component: If the current task needs to be reset to another step.
If the CR is a position where nobody has the options to skip or fail to the correct current task, then it indicates a deficiency in the workflow setup itself. Chances are the workflow steps need to be re-evaluated to be sure it best meets the business requirements. Plus, someone on the team needs to have permission and options to skip/fail when necessary or else the workflow is too rigid. At the very least, the Phire administrator should have the special permissions to “Skip Any Task” and “Fail Any Task” so that they can always re-position the current status.
As usual, if you have any questions about your particular setup, circumstance, or any of the options described here, don’t hesitate to contact Phire support to discuss it.
For example, can a Project Build be done through Phire that will handle a project that contains:
1. Create a new table
2. Alter a table to contain new columns
3. Alter a table to change column definitions
4. Alter a table to drop columns that contain data
5. Migrate a table with no structural differences
Yes. In the Phire email configuration, any email notification can include and “Additional To”, “Additional CC” or “Additional BCC” address.
For the Issue Tracking module, you’ll see the options on Page 3: Application Code Definitions of the Domain Setup Wizard (Phire Architect > Architect Administration > Domain Setup Wizard). The email notification link opens the details for each Issue Type. Notice the grid tabs for “Additional To”, “Additional CC” or “Additional BCC”. That entry can include a hard-coded email address, a listserv address or a reference to a user/role following the syntax described on the page help.
For the Change Request module, you’ll see the options on Page 13: Workflow Definitions of the Domain Setup Wizard (Phire Architect > Architect Administration > Domain Setup Wizard). The email notification link opens the details for each step in the workflow. The same tabs are available here to enter an address or a user/role.
A powerful feature of Phire is its ability to automatically perform the App Designer “project build” following a migration. This of course is the process of synchronizing the database tables/views/indexes with any updated record definitions in the project. Without this feature in Phire, a user needs to log into the target environment using App Designer following a migration to manually perform the build.
The trick however, is that the PeopleTools App Designer program only operates on Windows, thus Phire needs a Windows server to run it on. So there are two choices if you want to automate the project build in Phire – either put Phire on a Windows application server, or setup a Windows process scheduler. If using a Windows app server then the build can run in-line as part of the migration. If using a Unix/Linux app server, then a Windows process scheduler can be used. In that setup then the build is submitted as a separate process on the scheduler after the migration is complete.
The choice is set on Page 2: Domain Definition in the Domain Setup Wizard (Phire Architect > Architect Administration > Domain Setup Wizard). The option “Build Method” includes options to perform the build on either the App Server or on the Process Scheduler (or None, if that’s your choice). Additional setup for the process scheduler is shown if that choice is selected.
On the Migration page of the Change Request component are two buttons: “Standard Migration” and “Ad hoc Migration”.
When entering a Standard Migration, the target is assumed based on the status of the workflow (see the Task page of the CR). This generally represents the common migration path and business process that all work follows. And controls in the workflow will prevent migration to a given target until prerequisite steps are completed, and then only by the assigned user or a member of the assigned role. When complete, the workflow will automatically advance to indicate that the migration has occurred.
The Ad hoc Migration on the other hand, is intended to request a migration to a target that is not likely to be in the normal workflow, or in special circumstances to work outside of the controls of the workflow. The Ad hoc Migration does not advance the workflow upon completion. A common example is a training or sandbox database that is not normally part of the migration path, but occasionally needs to receive code as it moves through testing. Another example is a test database that has been refreshed and needs a CR re-migrated – the ad hoc migration allows this to be done without having to fail the CR workflow back to the earlier migration step. The list of available targets is setup on Page 14: Workflow Databases in the Domain Setup Wizard (Phire Architect > Architect Administration > Domain Setup Wizard). Additionally, only a user with permission to migrate to the selected target will be able to initiate the migration.
