MIME Upload: Operation is not allowed (M_APP_P) take #2

Question

Hello folks,
with respect to the following thread: Operation is not allowed (M_APP_P)
System Info:
NW AS 7.03 ABAP Stack 731 Level 9, ECC 606 (EHP 6) with SAP_HR 604 Level 73 and EA_HR 607 (HR-Renewal 1) Level 24
Background:
One of our external colleagues is currently developing some Themes for certain WDA Applications. He recently applied and deployed them with means of the report WDG_MAINTAIN_UR_MIMES. A few weeks later I had to apply several Unified Rendering Notes because the upgrade to 731 Basis Stack 9 wrecked quite some functionalities concerning keyboard-accessibility. Whilst doing that, I ran into the Problem, that the archive ur_mimes_nw7.zip had been locked by the said colleague (apparently the lock was set implicitly by using the Download Option of the Report WDG_MAINTAIN_UR_MIMES which was used to save away the unmodified archive before uploading the modified one) and this also provoked the error message mentioned in the thread over here: Operation is not allowed (M_APP_P). After removing the lock from the archive I used the workaround approach Jean Clappier described in the said thread and I was able to implement the respective UR-Notes.
Problem/Question:
Today our external colleague wanted to recommence the implementation of the themes and now receives the same error message "Operation is not allowed (M_APP_P)" when trying to upload an archive via WDG_MAINTAIN_UR_MIMES.
Now, we could be using the workaround in the linked thread again, but none of us knows for 100% sure if there isn't something "extra special" the Report does which we would miss. So, this is one part of the actual question of this thread:
Is there any difference between uploading/overwriting ur_mimes_nw7.zip hard via SE80 and uploading it via WDG_MAINTAIN_UR_MIMES?
The other part is the understanding what's actually happening here. I attached a screenshot for the part of the coding where the error message ultimately originates from. My problem is understanding the very cryptic functional reason why the upload supposedly "isn't allowed", because what I see is, there's an attempt to save the archived File via Form routine phio_store_as_update in FM SDOK_PHIO_STORE_AS_UPDATE, so apparently an update of something that's already supposed to be there? However at some later point of the coding (screenshot) the PHIO appears to be initial and that's probably why the error occurs. Could be true, could be entire nonsense; either way I don't get it. Screen:
What I tried so far / Analysis:
Debugging into the delicious spaghetti-code
Any help/input is highly appreciated!
Cheers, Lukas

Answer 1

Hello community,
as a co-worker of Lukas Weigelt I also examine that problem and found it’s reason. In the Report “WDG_MAINTAIN_UR_MIMES“ the LOIO of the uploaded data will be used to determine the corresponding PHIO. Therefore the Function Module “SKWF_LOIO_ALL_PHIOS_GET” is used. In the deep of it’s code it selects the PHIO from the table “SMIMPHIO” through the LOIO. But instead of only one PHIO to the LOIO the table offers three records with three different PHIO’s. In the further runtime of the report “WDG_MAINTAIN_UR_MIMES“ only the first found entry will be considered – and that’s the wrong PHIO which causes the error. This PHIO even has (as you can see in the attachment) the state '0000' which may means 'invalid' and indicates the error. By altering the PHIO to the right one, which is the one with the state '0002', the report works well.
Now the question is whether I can delete the two assumed 'invalid' PHIO-records in the table “SMIMPHIO” or not. Until then I’m able to use the report “WDG_MAINTAIN_UR_MIMES“ correctly by altering the PHIO to the right one in the debugger.
Regards, Marvin