fix: preserve blocked status of course members in updateCourse SOAP call (0040575)

[sKarki999]

This PR addresses the issue outlined in Mantis #0040575, where blocked course members were silently unblocked after a updateCourse SOAP call.

Steps to Reproduce

1. Create a course (manually or via addCourse SOAP call)
2. Add some students to the course
3. In the Members tab, activate "Access Refused" (blocked) for one or more students
4. Call updateCourse via SOAP using the XML in Scenario 1 below
5. Refresh the Members tab in your browser
6. The "Access Refused" checkbox is now unchecked — members silently unblocked

Test Scenarios

Replace <SID>::<CLIENT_NAME>, <COURSE_REF_ID>, and <USR_ID> with your values.

Scenario 1: Settings-only XML (no <Members> block)

<soapenv:Body>
    <urn:updateCourse>
        <sid><SID>::<CLIENT_NAME></sid>
        <course_id><COURSE_REF_ID></course_id>
        <xml>
            <![CDATA[
                <Course importId="test_course_010">
                    <MetaData>
                        <General Structure="Hierarchical">
                            <Title Language="en">Sample Course</Title>
                            <Language Language="en" />
                            <Description Language="en">Updated description.</Description>
                        </General>
                    </MetaData>
                    <Settings>
                        <Availability><Unlimited /></Availability>
                    </Settings>
                </Course>
            ]]>
        </xml>
    </urn:updateCourse>
</soapenv:Body>

Expected: Blocked user remains blocked after update.

Scenario 2: XML explicitly sends blocked="No"

<soapenv:Body>
    <urn:updateCourse>
        <sid><SID>::<CLIENT_NAME></sid>
        <course_id><COURSE_REF_ID></course_id>
        <xml>
            <![CDATA[
                <Course importId="test_course_010">
                    <MetaData>
                        <General Structure="Hierarchical">
                            <Title Language="en">Sample Course</Title>
                            <Language Language="en" />
                        </General>
                    </MetaData>
                    <Settings>
                        <Availability><Unlimited /></Availability>
                    </Settings>
                    <Members>
                        <Member id="il_0_usr_<USR_ID>" blocked="No" passed="No" action="Attach" />
                    </Members>
                </Course>
            ]]>
        </xml>
    </urn:updateCourse>
</soapenv:Body>

Expected: User is unblocked

Scenario 3: XML sends action="Detach" (user removed, not re-blocked)

<soapenv:Body>
    <urn:updateCourse>
        <sid><SID>::<CLIENT_NAME></sid>
        <course_id><COURSE_REF_ID></course_id>
        <xml>
            <![CDATA[
                <Course importId="test_course_010">
                    <MetaData>
                        <General Structure="Hierarchical">
                            <Title Language="en">Sample Course</Title>
                            <Language Language="en" />
                        </General>
                    </MetaData>
                    <Settings>
                        <Availability><Unlimited /></Availability>
                    </Settings>
                    <Members>
                        <Member id="il_0_usr_<USR_ID>" action="Detach" />
                    </Members>
                </Course>
            ]]>
        </xml>
    </urn:updateCourse>
</soapenv:Body>

Expected: User is removed from course

If approved, must be picked for 11 and trunk.

[GitHamo]

Looks good, I have tested it, but during my testing, I found that all the checkboxes are unchecked, not just blocked users. Maybe this ticket scope should be widened or a new separate ticket for it.

The issue occurs on trunk as well.

[sKarki999]

Hi @GitHamo ,

Thank you for catching that as well. On my quick investigation, i think this would require separate fix and hence i think a separate soap ticket would make more sense imo. Currently, since this bug report is primarily about the blocked users being unblocked, we can limit the scope of this PR to only this current fix.
Do you agree ? Let me know :)

[GitHamo]

@sKarki999 As discussed, we keep the scope of this PR small. Collect the discovered issues in a new ticket with effort calculated.