Moodle
  1. Moodle
  2. MDL-37633

Digest emails of Forum do not work when upgrade to 2.3.3 and 2.3.4 from 2.3.2

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.3.3, 2.3.4, 2.4.1
    • Fix Version/s: None
    • Component/s: Forum
    • Environment:
      CentOS 6.3
    • Database:
      MySQL
    • Testing Instructions:
      Hide

      Test1:

      1. Install site and enrol users to some courses.
      2. Go to define roles page (Site administration ► Users ► Permissions ► Define roles)
      3. Edit Authenticated user on frontpage and make sure user has "mod/forum:allowforcesubscribe" capability

      Test2:

      1. Edit front page settings (Site administration -> Front page -> front page settings)
      2. Set "News items" for frontpage and frontpageloggedin
      3. Set defaultfrontpageroleid to "Authenticated user on frontpage"
      4. Go to front page and add a new topic in site news (check 'Mail now')
      5. Turn editing on and Edit this topic
      6. click "Subscription mode and click "Force subscription"
      7. Change digestmailtime appropriately, so cron can be run after this. (Site administration ► Plugins ► Activity modules ► Forum)
      8. Log in as a student and edit profile.
      9. Set Email digest type to Complete
      10. After digestmailtime elapse run admin/cron.php
      11. Make sure digest is posted to users, with "Email digest type" to Complete/subject.
      Show
      Test1: Install site and enrol users to some courses. Go to define roles page (Site administration ► Users ► Permissions ► Define roles) Edit Authenticated user on frontpage and make sure user has "mod/forum:allowforcesubscribe" capability Test2: Edit front page settings (Site administration -> Front page -> front page settings) Set "News items" for frontpage and frontpageloggedin Set defaultfrontpageroleid to "Authenticated user on frontpage" Go to front page and add a new topic in site news (check 'Mail now') Turn editing on and Edit this topic click "Subscription mode and click "Force subscription" Change digestmailtime appropriately, so cron can be run after this. (Site administration ► Plugins ► Activity modules ► Forum) Log in as a student and edit profile. Set Email digest type to Complete After digestmailtime elapse run admin/cron.php Make sure digest is posted to users, with "Email digest type" to Complete/subject.
    • Affected Branches:
      MOODLE_23_STABLE, MOODLE_24_STABLE
    • Pull 2.4 Branch:
      wip-mdl-37633-m24
    • Pull Master Branch:
      wip-mdl-37633
    • Rank:
      47325

      Description

      Digest emails works on news forum in frontpage when I use 2.3.2.

      I upgrade it to 2.3.3,2.3.4 and 2.4.1, emails were not sent when I posted a new topic on the news forum in frontpage.
      (even executed /admin/cli/cron.php)

      But, digest emails in courses works also 2.3.3 and 2.3.4.

      Here is the steps of repoduce the problem.

      1.Install 2.3.3 and enroll users.

      2.upgrade to 2.3.4

      3.post a new topic to the news forum in frontpage.(check 'Mail now')
      (Subscription mode is forced, which the site administrator changed)

      4.execute admin/cron.php

      expected result:send a digest email to all users.

      currently resulet:NOT send mails.

      Here is the cron's log. '0 users' seems wrong.

      Processing module function assign_cron ...done.
      ... used 6 dbqueries
      ... used 0.037925958633423 seconds
      done.
      Processing module function chat_cron ...... used 5 dbqueries
      ... used 0.0039098262786865 seconds
      done.
      Processing module function forum_cron ...0 users were sent post 9, 'test'
      Starting digest processing...
      Cleaned old digest records
      ... used 14 dbqueries
      ... used 0.0086209774017334 seconds
      done.

        Issue Links

          Activity

          Hide
          Jun Nakamura added a comment -

          I tried to search the cause using by git bisect. It says,

          fd7255ace0d0b07c33ef169170a51fe8c639d559 is the first bad commit
          commit fd7255ace0d0b07c33ef169170a51fe8c639d559
          Author: Rex Lorenzo <rex@oid.ucla.edu>
          Date: Mon May 21 16:23:59 2012 -0700

          MDL-33166 Forum: Adding capability mod/forum:allowforcesubscribe

          Conflicts:

          mod/forum/version.php

          :040000 040000 50d8f2463d1df5dce91c8fa487d5174fffc16142 dd37ee5fae71a51654fbe07caa5e6ad564c00359 M mod

          Here is the log of git bisect.

          if the message, 'Processing module function forum_cron ...0 users were sent post' appears, input git bisect BAD.

          git bisect start

          1. bad: [ff63a3ad58dd985e27279e3495b0d85b23584a54] Moodle release 2.3.3
            git bisect bad ff63a3ad58dd985e27279e3495b0d85b23584a54
          2. good: [7413ce9896042b028a85cb5bf59bc75554ca2084] Moodle 2.3.2 release
            git bisect good 7413ce9896042b028a85cb5bf59bc75554ca2084
          3. bad: [5e6f2cda64df1b26998337a5bc4e501308d4290e] Merge branch 'MDL-35767-MOODLE_23_STABLE' of git://git.luns.net.uk/moodle into MOODLE_23_STABLE
            git bisect bad 5e6f2cda64df1b26998337a5bc4e501308d4290e
          4. bad: [c366bea3cfc5229717d9fff59197d336306d758b] weekly release 2.3.2+
            git bisect bad c366bea3cfc5229717d9fff59197d336306d758b
          5. good: [bdd6847fc2a9d1989b6738ef8a29dafe8171a4f5] Merge branch 'MDL-30829-23' of git://github.com/FMCorz/moodle into MOODLE_23_STABLE
            git bisect good bdd6847fc2a9d1989b6738ef8a29dafe8171a4f5
          6. good: [1530136c2086c3d90cce63f8ca43e3ddeb871fb9] MDL-35344 Ignore available updates info with invalid format
            git bisect good 1530136c2086c3d90cce63f8ca43e3ddeb871fb9
          7. good: [85aa469960fecc7d595cf58e9527944b8c21728c] Merge branch 'MDL-30909-23' of git://github.com/FMCorz/moodle into MOODLE_23_STABLE
            git bisect good 85aa469960fecc7d595cf58e9527944b8c21728c
          8. bad: [e6084683c8b7ef6fe215a3950c9b618b071a67ad] Merge branch 'wip-mdl-33166-m23' of git://github.com/rajeshtaneja/moodle into MOODLE_23_STABLE
            git bisect bad e6084683c8b7ef6fe215a3950c9b618b071a67ad
          9. good: [631aedabb4f1e656ac401a5fa1f8bc45deb3a297] Merge branch 'w38_MDL-32572_m23_authdbduplicates' of git://github.com/skodak/moodle into MOODLE_23_STABLE
            git bisect good 631aedabb4f1e656ac401a5fa1f8bc45deb3a297
          10. good: [ec5c45c4edc550825e63fb648b11426881f9bc05] MDL-33198 book: Adding h tags to book title to increase accessibility
            git bisect good ec5c45c4edc550825e63fb648b11426881f9bc05
          11. bad: [fd7255ace0d0b07c33ef169170a51fe8c639d559] MDL-33166 Forum: Adding capability mod/forum:allowforcesubscribe
            git bisect bad fd7255ace0d0b07c33ef169170a51fe8c639d559
          Show
          Jun Nakamura added a comment - I tried to search the cause using by git bisect. It says, fd7255ace0d0b07c33ef169170a51fe8c639d559 is the first bad commit commit fd7255ace0d0b07c33ef169170a51fe8c639d559 Author: Rex Lorenzo <rex@oid.ucla.edu> Date: Mon May 21 16:23:59 2012 -0700 MDL-33166 Forum: Adding capability mod/forum:allowforcesubscribe Conflicts: mod/forum/version.php :040000 040000 50d8f2463d1df5dce91c8fa487d5174fffc16142 dd37ee5fae71a51654fbe07caa5e6ad564c00359 M mod Here is the log of git bisect. if the message, 'Processing module function forum_cron ...0 users were sent post' appears, input git bisect BAD. git bisect start bad: [ff63a3ad58dd985e27279e3495b0d85b23584a54] Moodle release 2.3.3 git bisect bad ff63a3ad58dd985e27279e3495b0d85b23584a54 good: [7413ce9896042b028a85cb5bf59bc75554ca2084] Moodle 2.3.2 release git bisect good 7413ce9896042b028a85cb5bf59bc75554ca2084 bad: [5e6f2cda64df1b26998337a5bc4e501308d4290e] Merge branch ' MDL-35767 -MOODLE_23_STABLE' of git://git.luns.net.uk/moodle into MOODLE_23_STABLE git bisect bad 5e6f2cda64df1b26998337a5bc4e501308d4290e bad: [c366bea3cfc5229717d9fff59197d336306d758b] weekly release 2.3.2+ git bisect bad c366bea3cfc5229717d9fff59197d336306d758b good: [bdd6847fc2a9d1989b6738ef8a29dafe8171a4f5] Merge branch ' MDL-30829 -23' of git://github.com/FMCorz/moodle into MOODLE_23_STABLE git bisect good bdd6847fc2a9d1989b6738ef8a29dafe8171a4f5 good: [1530136c2086c3d90cce63f8ca43e3ddeb871fb9] MDL-35344 Ignore available updates info with invalid format git bisect good 1530136c2086c3d90cce63f8ca43e3ddeb871fb9 good: [85aa469960fecc7d595cf58e9527944b8c21728c] Merge branch ' MDL-30909 -23' of git://github.com/FMCorz/moodle into MOODLE_23_STABLE git bisect good 85aa469960fecc7d595cf58e9527944b8c21728c bad: [e6084683c8b7ef6fe215a3950c9b618b071a67ad] Merge branch 'wip-mdl-33166-m23' of git://github.com/rajeshtaneja/moodle into MOODLE_23_STABLE git bisect bad e6084683c8b7ef6fe215a3950c9b618b071a67ad good: [631aedabb4f1e656ac401a5fa1f8bc45deb3a297] Merge branch 'w38_ MDL-32572 _m23_authdbduplicates' of git://github.com/skodak/moodle into MOODLE_23_STABLE git bisect good 631aedabb4f1e656ac401a5fa1f8bc45deb3a297 good: [ec5c45c4edc550825e63fb648b11426881f9bc05] MDL-33198 book: Adding h tags to book title to increase accessibility git bisect good ec5c45c4edc550825e63fb648b11426881f9bc05 bad: [fd7255ace0d0b07c33ef169170a51fe8c639d559] MDL-33166 Forum: Adding capability mod/forum:allowforcesubscribe git bisect bad fd7255ace0d0b07c33ef169170a51fe8c639d559
          Hide
          Rex Lorenzo added a comment -

          Jun, do a capability report and look at what roles have the "mod/forum:allowforcesubscribe" capability. You might need to set "Authenticated user" or something like that.

          Show
          Rex Lorenzo added a comment - Jun, do a capability report and look at what roles have the "mod/forum:allowforcesubscribe" capability. You might need to set "Authenticated user" or something like that.
          Hide
          Jun Nakamura added a comment - - edited

          Thank you,

          I changed its subscription mode forced by the site administrator.

          I did the steps on site administrator role, but digest emails were not sent.

          Here is the capability report of "mod/forum:allowforcesubscribe" .
          Report for capability 'Allow force subscribe'

          System

          manager Not set
          coursecreater Not set
          editingteacher Allow
          teacher Allow
          student Allow
          guest Not set
          user Not set
          frontpage Not set

          Show
          Jun Nakamura added a comment - - edited Thank you, I changed its subscription mode forced by the site administrator. I did the steps on site administrator role, but digest emails were not sent. Here is the capability report of "mod/forum:allowforcesubscribe" . Report for capability 'Allow force subscribe' System manager Not set coursecreater Not set editingteacher Allow teacher Allow student Allow guest Not set user Not set frontpage Not set
          Hide
          Jun Nakamura added a comment -

          When I change the default role of the front page, "frontpage", to "student", then digest email were sent to all users.

          Is the behavior CORRECT??

          I think the setting might be no need.

          Show
          Jun Nakamura added a comment - When I change the default role of the front page, "frontpage", to "student", then digest email were sent to all users. Is the behavior CORRECT?? I think the setting might be no need.
          Hide
          Rex Lorenzo added a comment -

          Adding Rajesh Taneja as a watcher for this ticket, because I believe this is a regression caused by the changes in MDL-33166.

          I don't believe this use case was tested for.

          Show
          Rex Lorenzo added a comment - Adding Rajesh Taneja as a watcher for this ticket, because I believe this is a regression caused by the changes in MDL-33166 . I don't believe this use case was tested for.
          Hide
          Rajesh Taneja added a comment -

          Thanks for reporting this Jun,

          It seems frontpage role should have "mod/forum:allowforcesubscribe" capability by default and it was missed in MDL-33166.

          Jun Nakamura: Attached patch should solve this problem, or you can set "mod/forum:allowforcesubscribe" capability to frontpage role and it should work.

          Just wondering is "Authenticated user" (user role), should also be given this capability by default.

          Show
          Rajesh Taneja added a comment - Thanks for reporting this Jun, It seems frontpage role should have "mod/forum:allowforcesubscribe" capability by default and it was missed in MDL-33166 . Jun Nakamura : Attached patch should solve this problem, or you can set "mod/forum:allowforcesubscribe" capability to frontpage role and it should work. Just wondering is "Authenticated user" (user role), should also be given this capability by default.
          Hide
          Rajesh Taneja added a comment -

          After talking to Dan and others, it doesn't make sense to have this capability to user role. But for sure this should be default for frontpage role.

          Pushing it for peer-review.

          Show
          Rajesh Taneja added a comment - After talking to Dan and others, it doesn't make sense to have this capability to user role. But for sure this should be default for frontpage role. Pushing it for peer-review.
          Hide
          Jun Nakamura added a comment -

          Thanks Rajesh!

          I confirmed the expected behavior, it works!

          I agree you plan.

          Show
          Jun Nakamura added a comment - Thanks Rajesh! I confirmed the expected behavior, it works! I agree you plan.
          Hide
          Frédéric Massart added a comment - - edited

          Looks good Raj, pushing for integration. Cheers!

          (Could you just rephrase a bit the testing instructions? Also is there a specific setting to set on the forum or in permissions for the auto subscription to work?)

          [Y] Syntax
          [-] Output
          [Y] Whitespace
          [-] Language
          [-] Databases
          [?] Testing
          [Y] Security
          [-] Documentation
          [Y] Git
          [Y] Sanity check

          Show
          Frédéric Massart added a comment - - edited Looks good Raj, pushing for integration. Cheers! (Could you just rephrase a bit the testing instructions? Also is there a specific setting to set on the forum or in permissions for the auto subscription to work?) [Y] Syntax [-] Output [Y] Whitespace [-] Language [-] Databases [?] Testing [Y] Security [-] Documentation [Y] Git [Y] Sanity check
          Hide
          Damyon Wiese added a comment -

          Hi Raj,

          Thanks for the fix. It does solve the issue - but there are some extra things that need fixing:

          It does not apply the fix for current versions. In this situation - where there is broken functionality if the capability is missing from the role - it makes sense to add upgrade code to add this capability to all roles with the frontpage archetype (and mention this in an upgrade.txt). It does not get automatically applied during an upgrade without manual upgrade code.

          Also - the version number for the stable versions should only increment the last 2 digits - not the entire date. This required is so that any 2.3 version of the plugin will always be < any 2.4 version of the plugin and we will never accidentally miss any upgrade steps.

          Cheers, Damyon

          Show
          Damyon Wiese added a comment - Hi Raj, Thanks for the fix. It does solve the issue - but there are some extra things that need fixing: It does not apply the fix for current versions. In this situation - where there is broken functionality if the capability is missing from the role - it makes sense to add upgrade code to add this capability to all roles with the frontpage archetype (and mention this in an upgrade.txt). It does not get automatically applied during an upgrade without manual upgrade code. Also - the version number for the stable versions should only increment the last 2 digits - not the entire date. This required is so that any 2.3 version of the plugin will always be < any 2.4 version of the plugin and we will never accidentally miss any upgrade steps. Cheers, Damyon
          Hide
          CiBoT added a comment -

          Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.

          Show
          CiBoT added a comment - Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.
          Hide
          Rajesh Taneja added a comment -

          Thanks Damyon,

          I have added upgrade code.

          Pushing for peer-review again.

          Show
          Rajesh Taneja added a comment - Thanks Damyon, I have added upgrade code. Pushing for peer-review again.
          Hide
          Rajesh Taneja added a comment -

          Just had a word with Damyon,

          If user with this patch upgrades again, then it's fine to run this upgrade again.
          As this is mentioned in upgrade.txt, it is fine to keep it that way.

          Show
          Rajesh Taneja added a comment - Just had a word with Damyon, If user with this patch upgrades again, then it's fine to run this upgrade again. As this is mentioned in upgrade.txt, it is fine to keep it that way.
          Hide
          Frédéric Massart added a comment -

          Hi Raj, I know you've discussed it before but I'm not convinced that this code should run multiple times. Though it's not of me to decide whether this has to be integrated or not, but we could revert a previously set permission and I'm not sure it's the correct way.

          Feel free to push for integration whenever you like.

          Fred

          Show
          Frédéric Massart added a comment - Hi Raj, I know you've discussed it before but I'm not convinced that this code should run multiple times. Though it's not of me to decide whether this has to be integrated or not, but we could revert a previously set permission and I'm not sure it's the correct way. Feel free to push for integration whenever you like. Fred
          Hide
          Rajesh Taneja added a comment -

          Thanks for the review Fred,

          I am not sure if there is any good way to get around this. Although this is highly unlikely as user with this patch in 2.3 will upgrade to 2.4 above this patch (hopefully).

          Anyway I am not so sure, have discussed with Damyon and he suggested this is fine and as it's mentioned in upgrade.txt it should be fine.

          Show
          Rajesh Taneja added a comment - Thanks for the review Fred, I am not sure if there is any good way to get around this. Although this is highly unlikely as user with this patch in 2.3 will upgrade to 2.4 above this patch (hopefully). Anyway I am not so sure, have discussed with Damyon and he suggested this is fine and as it's mentioned in upgrade.txt it should be fine.
          Hide
          Damyon Wiese added a comment -

          The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

          Cheers!

          Show
          Damyon Wiese added a comment - The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week. Cheers!
          Hide
          Dan Poltawski added a comment -

          Hi Raj,

          Two small things to address:

          • The function assign_legacy_capabilities is the correct function to use to assign the capabilities (i.e. its the one used by update_capabilities(), which is used by upgrade). The name is misleading I know, that is because of history before we had archetypes, but better to use that than implementing it yourself.
          • The upgrade.txt and code comments are not clear enough. By default capabilities are given to roles - this normal behaviour. The point you need to get across and make clear to admins is that we are forcefully adding it because it was forgotten initially. In normal circumstances, we will set the default permissions on newly created capabilities, but with this change we'll change existing behaviour. So any modifications to front page archetype are changed by your code. I sugest for the upgrade.txt: 'Roles with frontpage archetype will forcefully be given mod/forum:allowforcesubscribe capability as it was mistakenly missed off when the capability was initially created.' (don't need to copy that, i'm just trying to make clear what i'm saying).
          Show
          Dan Poltawski added a comment - Hi Raj, Two small things to address: The function assign_legacy_capabilities is the correct function to use to assign the capabilities (i.e. its the one used by update_capabilities(), which is used by upgrade). The name is misleading I know, that is because of history before we had archetypes, but better to use that than implementing it yourself. The upgrade.txt and code comments are not clear enough. By default capabilities are given to roles - this normal behaviour. The point you need to get across and make clear to admins is that we are forcefully adding it because it was forgotten initially. In normal circumstances, we will set the default permissions on newly created capabilities, but with this change we'll change existing behaviour. So any modifications to front page archetype are changed by your code. I sugest for the upgrade.txt: 'Roles with frontpage archetype will forcefully be given mod/forum:allowforcesubscribe capability as it was mistakenly missed off when the capability was initially created.' (don't need to copy that, i'm just trying to make clear what i'm saying).
          Hide
          Rajesh Taneja added a comment -

          Thanks Dan,

          Can you confirm if following text is fine?

          mod/forum:allowforcesubscribe capability will be forcefully assigned to frontpage role, as it was mistakenly missed off
          when the capability was initially created. If you don't want users with frontpage role to get forum (with forcesubscribe) emails,
          then please remove this capability for frontpage role.

          Show
          Rajesh Taneja added a comment - Thanks Dan, Can you confirm if following text is fine? mod/forum:allowforcesubscribe capability will be forcefully assigned to frontpage role, as it was mistakenly missed off when the capability was initially created. If you don't want users with frontpage role to get forum (with forcesubscribe) emails, then please remove this capability for frontpage role.
          Hide
          CiBoT added a comment -

          Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.

          Show
          CiBoT added a comment - Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.
          Hide
          Dan Poltawski added a comment -

          Seems ok to me Raj.

          Show
          Dan Poltawski added a comment - Seems ok to me Raj.
          Hide
          Rajesh Taneja added a comment -

          Thanks Dan,

          pushing it back for your review.

          Show
          Rajesh Taneja added a comment - Thanks Dan, pushing it back for your review.
          Hide
          Dan Poltawski added a comment -

          Raj - the point of using assign_legacy_capabilities is that you could also get rid of get_archetype_roles().

          As I said, please can you also make clear in the comments of the upgrade function what is going on there. We are forcefully applying the default because it was missed.

          Show
          Dan Poltawski added a comment - Raj - the point of using assign_legacy_capabilities is that you could also get rid of get_archetype_roles(). As I said, please can you also make clear in the comments of the upgrade function what is going on there. We are forcefully applying the default because it was missed.
          Hide
          Rajesh Taneja added a comment -

          Hi! Dan,

          I kept get_archetype_roles(), to avoid print_error. In case site doesn't have frontpage role, assign_legacy_capabilities will throw error.
          Not sure if that is acceptable.

          Show
          Rajesh Taneja added a comment - Hi! Dan, I kept get_archetype_roles(), to avoid print_error. In case site doesn't have frontpage role, assign_legacy_capabilities will throw error. Not sure if that is acceptable.
          Hide
          Dan Poltawski added a comment -

          As discussed in the office get_role_archetypes() returns a static array which can't be modified. If frontpage archetype didn't exist, it'd be throwing errors in upgrade (as thats exactly what happens with lib/db/access.php array)

          Show
          Dan Poltawski added a comment - As discussed in the office get_role_archetypes() returns a static array which can't be modified. If frontpage archetype didn't exist, it'd be throwing errors in upgrade (as thats exactly what happens with lib/db/access.php array)
          Hide
          Rajesh Taneja added a comment -

          Thanks for clearing that Dan,

          I have fixed this, hope it's all good now.

          Show
          Rajesh Taneja added a comment - Thanks for clearing that Dan, I have fixed this, hope it's all good now.
          Hide
          Dan Poltawski added a comment -

          Thanks Raj, we got there in the end.

          Integrated to master, 24 and 23.

          Please can you keep a special eye ont he release notes for these versions to ensure it gets in there the notes (I added api_change here to try and ensure that).

          Show
          Dan Poltawski added a comment - Thanks Raj, we got there in the end. Integrated to master, 24 and 23. Please can you keep a special eye ont he release notes for these versions to ensure it gets in there the notes (I added api_change here to try and ensure that).
          Hide
          Rajesh Taneja added a comment -

          Thanks Dan,
          I have noted this, will make sure this gets in release notes.

          Show
          Rajesh Taneja added a comment - Thanks Dan, I have noted this, will make sure this gets in release notes.
          Hide
          David Monllaó added a comment -

          It passes, after upgrading to the latests versions of integration all the "Authenticated user on front-page" have an "Allow" in mod/forum:allowforcesubscribe capability

          Show
          David Monllaó added a comment - It passes, after upgrading to the latests versions of integration all the "Authenticated user on front-page" have an "Allow" in mod/forum:allowforcesubscribe capability
          Hide
          Damyon Wiese added a comment -

          Congratulations this fix has been added to Moodle!

          You may want to dedicate this issue to someone special on this Valentines day.

          Thanks!

          Show
          Damyon Wiese added a comment - Congratulations this fix has been added to Moodle! You may want to dedicate this issue to someone special on this Valentines day. Thanks!

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: