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 Master Branch:
      wip-mdl-37633

      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.

        Gliffy Diagrams

          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: