|
Unfortunately for my suggestion, the encoding and the decoding of the ZIP archive structure aren't centralized in shared code. Instead, the archive is created by the Assignment component (BaseAssignmentService) but parsed in the Assignment web application (AssignmentAction). This isn't ideal from a maintenance point of view, but it also presents a practical issue: for us (and possibly some other schools such as Capetown), the choice of display ID is influenced by ToolManager.getCurrentPlacement(), and this is null in the AssignmentService context.
The context should be available through other means that ToolManager.getCurrentPlacement() however - an assignment is associated with a context. So the service code shouldn't need to depend on a tool placement to work correctly.
The getDisplayId() of User class doesn't take any parameter. How should the service/application pass in the context information?
I notice the changes in " It is easier to pass in context information, e.g. from assignment.getContext(), instead of ToolManager.getCurrentPlacement() Thanks, - Zhen Stephen, to rephrase Zhen's comment, it's true that the AssignmentService code can figure out the correct site context from the assignment object. But the provider code which ends up implementing "user.getDisplayId()" doesn't know from assignment objects, so any translation from assignment-to-context has to be done by Assignment-savvy code.
IMO, handling the URL which downloads the ZIP file of assignments is just as much part of the web layer as handling the URL which uploads the ZIP file, and the request should therefore be going through the Assignments tool with all the usual authorization contexts being set. But I don't know the code well and that may be more refactoring than anyone wants to take on at this time. It's a shame that there's not better support for pushing and popping site contexts from Sakai services -- PortalSiteHelperImpl ends up basically copying-and-pasting code from ToolComponent to get around the "protected" state of setCurrentPlacement -- but that's *also* more change than anyone likely wants to take on. Zhen, the only problem with the approach taken by the QA ENVIRONMENT
Sakai QA Network qa2-us (svn tags/sakai-2.6.0-rc06) using Oracle9i - Built: 07/01/09 09:22 - Sakai sakai-2.6.0-rc06 - Server pomegranate (IE 8.x, XP Home SP3) QA SUMMARY As instructor, created assignment As student, submitted assignment As instructor: ** Downladed All into zip file ** Extracted files, added grades and comments ** Zipped modified file ** Uploaded All back into Sakai QA RESULT: FAIL - ISSUE NOT CLOSED Grades were updated, but new comments still could not be found, either by the instructor or the student Angela:
I think your reported upload problem is related to XP. See last comment in SAK-14493: "Using the Windows XP built-in ZIP functionality (Send To -> Compressed Folder), it matters *where* you create the ZIP. If you create the ZIP from the full folder (bulk_download), the upload will not work (but the grades.csv does work!). If you create the ZIP from the assignment folder (one folder in), it will work correctly." Could you please try upload again based on above suggestions? Or another OS? |
||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Critical
Assignments upload parser assumes that a user's display ID and EID are identical
"DAVIS, Ray(94853905)/comments.txt"
But the code uses the display ID when setting up the hashtable.
My guess as to the best way to resolve this would be to have the downloaded folder embed the display ID instead:
* The display ID is meant to be more understandable to end users than the EID.
* The student's display ID is shown in the Assignments and Gradebook UIs.
* A visible file structure that's been downloaded to the user's desktop could be considered part of the UI.