Uploaded image for project: 'Sakai'
  1. Sakai
  2. SAK-32174

Improvements over group blocking feature (SAK-27980)

    XMLWordPrintable

    Details

    • 11 status:
      Won't Fix
    • Test Plan:
      Hide

      1. Create a group (or use existing group) on the site
      2. Start a new assignment with "Group Submission" ticked
      3. Submit as one of the group members (submission will show when logged in as instructor)
      4. The group/section does not allow to be deleted. The checkbox for deleting it is hidden. A warning message is shown in groups screen.
      5. Deleting the assignment makes the deletion checkbox is visible again.

      Show
      1. Create a group (or use existing group) on the site 2. Start a new assignment with "Group Submission" ticked 3. Submit as one of the group members (submission will show when logged in as instructor) 4. The group/section does not allow to be deleted. The checkbox for deleting it is hidden. A warning message is shown in groups screen. 5. Deleting the assignment makes the deletion checkbox is visible again.

      Description

      Improvements over group blocking feature (SAK-27980)

      Improvements:
      JavaDoc all public methods in the API, explaining how to use them and why you should be locking something.

      Methods shouldn't fail silently, either changes signature to return boolean or throw exception.

      As code should be checking to see if it's locked before attempting to remove members I'd probably:

      leave removeMember(String) as is, possibly deprecate, but if nothing else JavaDoc it to say calling code should handle locks.

      add deleteMember(String) that checks the lock and throws IllegalStateException if it's locked.

      Update calling code to use deleteMember(String) in all cases that it should.

      This is just from a quick look, what do you think?

      Also doing this locking/unlocking in the service would have been a better place as then as the tool evolves it's easier for the locking/unlocking to continue to work.

      Also when requests are made through entitybroker the unlocking/locking works.

      I'm not sure this is the right way to handle deleting of a Group and warning users about the problems it may cause. We'll have other problems if there's a group used by a signup and someone removes the group. Having a listener that allow tools to register to hear about changes allows all tools to have a veto on changes and doesn't bind the group code to all the tools. But doing this is more work.

      Side note, if a user doesn't have permission to update the site but can remove assignents could that result in a group remaining locked without any linked assignments?

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  jcebellan Jose Cebellán (Entornos de Formación)
                  Reporter:
                  farreri Miguel Pellicer
                • Votes:
                  1 Vote for this issue
                  Watchers:
                  21 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:

                    Git Source Code