In our current project, we have to implement a stand-alone HR Renewal
project, with the leave request management as the main application. We
had a problem with the validation of a request. While the manager could
accept or reject a leave request, it could not see the detail of the
request.
Problem
In our current project, we have to implement a stand-alone HR Renewal project, with the leave request management as the main application.
We had a problem with the validation of a request. While the manager could accept or reject a leave request, it could not see the detail of the request.
Resolution process
Using the POWL_COCKIPT transaction, we can see the POWL types registered with our POWL (MANAGER_MSS_INBOX_UI_1). In our case, we are interested by the "MSS_POWL_LEA_APPROVAL" type.
Using the POWL_TYPE transaction, we can now see that the type is associated with the feeder class "CL_HRMSS_PTARQ_LEAVREQ_POWL".
In this class, we look at the member function "IF_POWL_FEEDER~HANDLE_ACTION". Examining the code, we see that the "accept" and "reject" actions are performed immediately, while the "detail" action try to launch another application (which seem logical).
A break-point allows us to see that the launch parameters are based on the MSS/NAV launchpad. Reading applications data for this launchpad further show that theses applications are "OBN" (object based navigation"). As far as I know, stand-alone HR Renewal is not based on OBN (I've seen OBN used in portal).
No comments:
Post a Comment