Refactoring the "complete activity" logic so that tools, gates and grouping screens all complete in the same way. Without this change, when the gates and grouping screens were opened in popup window (after completion), it tried to go to the next activity rather than closing the window.
Breaking the completeToolSession functionality into two parts. Now the tool session is completed but it forwards to another call to complete the activity and calculate the next activity. This is to reduce the chances of collisions when live edit is being started, in a clustering environment. See the live edit wiki page for more details.
Replaced the hardcoded mode parameter in the method 'getFolderContentsExcludeHome' with the mode value supplied by the web service call 'getLearningDesigns'
Added comment explaining the mode parameter for the web service call getLearningDesigns.mode = 1 : AUTHORING mode, both valid and invalid learning designs will be returned.mode = 2: MONITORING mode, only valid learning designs are returned.
Display an error message if the current activity for a user is null and it can't be recalculated without doing resume, or resume automatically if it was a system gate and the gate activity has been removed.
When a design is edited using live edit, we may have added activities on the end. So if anyone has the lesson marked as completed in their learner progress, the completed flag will need to be reset.
More handling for "null" current/next activity - needed for the stop gates being removed.Also now check that any activity being commenced isn't a live edit + not read only activity. This will stop any user that evades the stop gates from making activities after the stop gate read only - they will not be able to do the next activity. Given that the learning design is already loaded into memory, it shouldn't add greatly to the progress engine steps (not compared to everything else!)
