In a Request type, all users belonging to security groups in user access tab will be able to do a search by selecting the request type in the search screen. But users belonging to security groups that are identified dynamically is not able to find the request type in search requests screen.
For instance, In Bug request type user access i have a token called TEAM_MEMBERS which will be populated by a security group by a rule based on the nature of the bug. There is another security group called "Project Managers" which is given directly in the user access tab.
Users belonging to Project Managers group can find Bug RT in the search screen Request Type dropdown. But users belonging to team members1, team members2 are not able to see Bug RT in the search screen drop down eventhough they can search for the request by request no.
This is by design within PPM application, and I remember reporting this as an issue to HP sometime back. As a workaround, we provided a request list portlet with the ability to list all the requests (bugs in your case) and made it available to users (Team members).
Since we had the ability to take action on the request based on the request status, we could achieve listing only relevant requests to specific user within the group (by using Eligible for My Action)
before 9.12, any user was able to search for any request type. In my point of view, this is the correct approach, since request-level security is anyways applied in the search results.
In 9.12, Hp changed this behaviour without documenting this feature. They did not want to document this even after support cases were raised to them.
Anyways, since our implementations are heavily using tokens in the request access tab (nb: in order to overcome the missing features in the PPM security models), we implemented a workaround by changing the specific view used by the Request Type field in the Request Search form.
--remember to kudos people who helped solve your problem