Forum

This is done through the workflow setup in the Domain Setup Wizard (found at:  Phire Architect > Architect Administration > Domain Setup Wizard).  Go to Step 14. Workflow Definitions, and drill into the details for the migration step in question.  Change the Task Trigger from “Migration” to “Migration w/Baseline” that forces the selection.

In the templates delivered with Phire this option is used for the production migration, and the regular “Migration” is used for the lower environments.  Often, in test environments customers don’t really rollback changes (if there’s a problem found in testing they just fail it in the workflow and re-migration after the developer has fixed it).  But it is important to ensure that the baseline is done migrating to production.

Also, note that this aspect of the workflow is set in the CR at the time it’s created and the setup will only affect new CRs moving forward.  The CR Workflow Reset component is available to address existing CRs if necessary.

Phire utilizes the same Application Designer mechanism to perform the Project Build that developers and administrators are all familiar with.  So the “Build Order” flag on the view record definitions controls this when performing a migration and build in Phire.

Looking at the workflow setup, the step named “Create Migration Set” is typically set with a source database and thus only gets marked complete when the developer successfully creates a Migration Set from that particular source database.  So you can be sure that the workflow will not advance to the later migration steps without that requirement being met.

Next, the migration steps themselves have an optional source in the setup, which locks it into migrating only from a Migration Set created from a particular source.  The source database value is often left blank allowing more flexibility, but can be entered to provide this tighter control.

Developers can access files (SQRs, COBOLs, etc.) that are residing on the servers for the various environments from the Objects page within the Change Request. First, the developer needs to add the file name to the CR Object list. Then to download or upload the file from/to an environment, the developer needs to click the download or upload button next to the file name in the CR Objects. The prompt page will offer a list of databases available to the developer.

The list is controlled by setup in the Domain Setup Wizard on Step 14. Workflow Databases (found at Phire Architect > Architect Administration > Domain Setup Wizard).  There you will find the “File Upload” and “Object View/Download” options listed for each database within each CR Type.  The file upload option is further limited by “Restore Object” security and the lock status of the particular file within Phire.

How to test a fuse without a multimeter? This may sound difficult, but it is actually something that anyone could learn. Check this and much more in this link and find out about the best in the world of electronics

The option to show the domain throughout the application is on the configuration page:  Phire Architect > Architect Administration > License Code;  in the checkbox labeled “Display Domain Name”.  This will take effect immediately in many of the work list and result list pages in Phire.  With this turned off CR numbers for example will be shown like this: “CR000001”.  With this turned on, they will be displays like this:  “HCM-CR000001” (where “HCM” is the name of the domain).

For customers that have just one domain in their Phire implementation, it’s reasonable to turn this off and keep the display simple.  But if there are multiple domains in the implementation, then it is important to distinguish the domain associated with a CR or Issue and it make sense to turn it on.

You can disable the auto-assign checkbox on the issue component without customizing. This is done through Phire security. Navigate to:  Phire Architect > Security Administration > Domain Security

Select the Role from which you want to take away the auto-assign checkbox.
Click the Permission List link next to your Domain.
Uncheck the “Override Auto Assignment” permission.

Note: If the user belongs to multiple roles, you need to make you take away the above permission from all the roles. If at least one role assigned to a user has this permission, then the auto-assign checkbox will still be enabled.

The “Directory Import” function is meant to be a feature for the developer to facilitate the inputting of the CR object list. Security implications of this feature is minimal since the files are not being imported; instead, this feature is simply determining the list of the files in a directory that is accessible from the Phire application server to make it easier to add the file names to the CR without having to type each file name.

Since this is a development function, there is usually not a requirement to disable this feature.  So, if you want to completely disable this function, you can do so by updating the PHI_CR_FILE_ADD page and making the “Directory Import” button invisible.

During implementation of Phire, or in a “development” instance of Phire, you may not want email being triggered as you test aspects of the application.  An easy way to halt this is turn off the email notifications completely.  This is done on the Domain Setup Wizard (Phire Architect > Architect Administration > Domain Setup Wizard), Step 2. Domain Definition, by unchecking the box: “Enable Email Notifications”.  It can still capture the history of the email events; it just doesn’t send them.

This information is captured in the history as the objects are processed, and is visible on-line in the View Version Set page.  From the CR Objects page, use the View Version Sets button to see all of the Version Sets created for the CR, then click the “History” hyperlink for the set of interest.  At that point, you will see each object that was processed with a success column and a result message.  You can easily isolate the error, including the objects not found, by selecting the “Show Errors Only” checkbox at the top.

There is an option available to delete version sets, found at:  Phire Architect > Architect Administration > Purge Object Versions.  This administrative component allows you to search for and delete version sets using a variety of criteria.  This component was intended to be used only by administrators, so there is no direct access to it from the CR component.  The permission to use this component is controlled by the normal PeopleTools role/permission list access to the component.