Databases Reference
In-Depth Information
When you drill into an individual feedback record, you find a wealth of data and information that can make
your life as a developer much easier. The Feedback region contains a read-only description of each feedback
record. The disposition region is where you track feedback status, tags, developer comments, and public response.
In addition, there are three buttons: Log as Bug, Log as To Do, and Log as Feature. These buttons create a new
Team Development entity and copy data from the feedback record to the new entity, which saves time and ensures
accuracy. The Follow Up region is like a diary; it's a list of remarks that are added over time as the feedback is
processed. This is handy when several people must review the feedback before action is taken. The extra attributes
that you added to the Feedback page are displayed in the Additional Attributes region. The remaining regions display
read-only data that describes the application context, the runtime environment (browser type and version), and the
entire session state. If a bug is reported, the developer has all the information required to reproduce the bug, which is
a valuable benefit.
Responses to Feedback
The feedback mechanism contains a response table. In principle, responses should be sent to the users who
initiated the feedback. However, there is no easy and declarative mechanism that enables you to send responses to
users. If you want to send responses to users, you first need to address a number of design issues. For example, do you
want to broadcast responses to all users or send individual responses to individual users? Do you want to use e-mail
or create reports? Do you want to send responses to a team? Do you want to route the responses based on a feedback
classification scheme?
After you design your response strategy, you can then build a tool that fulfills the requirement by writing some
PL/SQL code and accessing the APEX views that expose all of the Team Development data. The details of building this
tool are beyond the scope of this topic.
Communication Between Workspaces
Team Development is a property of a workspace. Many professional shops maintain multiple workspaces for
production, testing, and development environments. This means that if an end user enters a feedback record, that
record resides in the production workspace and the developers can't see it. This situation is easily remedied by using
APEX's existing export/import functionality. APEX version 4.0 and above has added feedback to the list of entities that
can be imported and exported to and from a workspace. This makes it possible to export the production feedback
and import it to the testing environment where the business analysts can evaluate it. If required, the feedback can
be exported from the testing environment and imported to the development environment where the developers can
evaluate and then log it as a bug, to-do, or feature.
Team Actions
Team Actions (see Figure
15-28
) are a miscellaneous set of utilities that help you manage the Team Development
environment. The links to the individual Team Actions are found on the right side of the Team Development
home page.
