Transport request is not correctly determined for subobjects (LIMU)

[fabianlupa]

Scenario: Multiple includes in an existing function group are changed using different transports. In the object list in abapGit there is only one transport icon displayed for the whole group (therefore only displaying one transport). More importantly in the staging view the objects are listed separately, each with their own transport id and link. These show the same transport for all objects in the function group even though they are locked in different transports (wrong information).

[fabianlupa]

To reproduce:

1. Clone abapGit-test/FUGR into a transportable package
2. Release the transport used for PULL
3. Change top include in one transport
4. Change function module in another one

The problem is ms_file-local contains two entries for the R3TR object instead of LIMU entries. find_transports uses this as well as find_changed_by which should therefore have the same problem.

https://github.com/larshp/abapGit/blob/d7e2833483719e92a4b1b1424daa2c344742a58b/src/ui/zcl_abapgit_gui_page_stage.clas.abap#L419-L420

NPLK900078 is listed for both objects but does not contain function module Z_ABAPGIT_UNIT_TEST:

Both objects are also listed as FUGR on the stage screen so in that sense it is consistent in some way.

I assume the problem also exists for all other LIMU objects which can be transported without their parent R3TR objects.

[mbtools]

I did some digging... Obviously it can only happen for objects that are split into multiple files. This can be identified by mo_files->add_abap with iv_extra not initial. My search found only CLAS, FUGR, and ENHO which currently use this split. I don't think ENHO has any LIMU logic.

My suggestion would be a new method in ZCL_ABAPGIT_OBJECT_FUGR/CLAS to derive the LIMU entry from the filename. Then find_transport could easily get the LIMU and return the correct transport request. (adding the method to ZIF_ABAPGIT_OBJECT could make it more generic)

[fabianlupa]

That makes sense to me.

Obviously it can only happen for objects that are split into multiple files.

And objects that are merged into a single file. I assume transporting individual method implementations or class definition sections using LIMU-METH, LIMU-CPRI/CPRO/CPUB will have the same problem. We probably cannot do anything for those though.

[mbtools]

By chance, I came across function TR_SHOW_OBJECT_LOCKS. Call it with IV_DIALOG = '' and IV_E071 = R3TR/FUGR/Z_ABAPGIT_UNIT_TEST and - like magic - it will return all transports that contain related locks i.e. where the LIMUs are found.

Sorry, don't have time to implement the mapping of the files to these lock entries but it should't be too hard (as long as different LIMUs have different files). If there's only one file, then maybe instead of the transport number, it should be a link to the TR_SHOW_OBJECT_LOCKS popup (IV_DIALOG = X).