Moodle
  1. Moodle
  2. MDL-28199

Lesson answer alignment incorrectly formatted

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.9.11
    • Fix Version/s: 1.9.14
    • Component/s: Lesson
    • Labels:
    • Testing Instructions:
      Hide

      To recreate:

      1. Create a lesson activity and a question page type with either a multiple choice or T/F question type.
      2. Enter questions with possible answers of varying length (it seems the shorter the possible answers the larger the gap between the answer and radio button).
      3. Preview the question pages in any browser.

      Show
      To recreate: 1. Create a lesson activity and a question page type with either a multiple choice or T/F question type. 2. Enter questions with possible answers of varying length (it seems the shorter the possible answers the larger the gap between the answer and radio button). 3. Preview the question pages in any browser.
    • Workaround:
      Hide

      See Moodle.org thread here: http://moodle.org/mod/forum/discuss.php?d=124115

      Offers a workaround which involves editing mod/lesson/view.php as well as a CSS-only solution further down the page.

      Show
      See Moodle.org thread here: http://moodle.org/mod/forum/discuss.php?d=124115 Offers a workaround which involves editing mod/lesson/view.php as well as a CSS-only solution further down the page.
    • Affected Branches:
      MOODLE_19_STABLE
    • Fixed Branches:
      MOODLE_19_STABLE
    • Pull from Repository:
    • Rank:
      17810

      Description

      When creating a multiple choice question in a Lesson, the alignment of text in the question table causes it to be far from the radio button (see screenshot) instead of next to the radio button as it should be. Distance between radio button and text varies depending on length of text. Seems to occur regardless of the theme used.

        Activity

        Hide
        Michael Blake added a comment -

        This issue has been reported as causing problems for a MP client. Please give it priority.

        Show
        Michael Blake added a comment - This issue has been reported as causing problems for a MP client. Please give it priority.
        Hide
        Petr Škoda added a comment -

        Hello, why is this marked as blocker? It seems to be a cosmetic issue that does not cause fatal errors or cause data loss.

        Petr

        Show
        Petr Škoda added a comment - Hello, why is this marked as blocker? It seems to be a cosmetic issue that does not cause fatal errors or cause data loss. Petr
        Hide
        Chris Follin added a comment -

        Hi Petr,

        We reported this as a partner issue and Michael bumped the priority to give the ticket some attention, but you are correct that it is a cosmetic issue.

        Show
        Chris Follin added a comment - Hi Petr, We reported this as a partner issue and Michael bumped the priority to give the ticket some attention, but you are correct that it is a cosmetic issue.
        Hide
        Petr Škoda added a comment -

        Thank you for the explanation.

        Show
        Petr Škoda added a comment - Thank you for the explanation.
        Hide
        Eloy Lafuente (stronk7) added a comment -

        Well, this is not my battle but I only can strongly disagree with this habit.

        The priority of one issue is a matter of how dangerous it is, cause data-loss, security problems and surely other aspects that contribute to pick the correct level.

        But, indeed, being reported by one partner IS NOT anything to consider when setting the priority of one bug. Not at all!

        There are alternative ways to communicate and improve response to partner-related issues:

        • label them
        • have one list somewhere (moodle.com?)
        • encourage the teams to work on, at least XX partner bugs per week
        • double pay to developers working on partner issues (joking).
        • agree with the SCRUM team about to add partner issues to the sprints in a priority way.
        • have some custom fields in case special information is needed.
        • whatever we can use to communicate and be more responsive.

        But, once more, indeed, raising minor, cosmetic, issues by the only cause of being partner-related is 100% wrong. Sorry, I see it crystal-clear, hence my opinion. Let's use that field for / how we have agreed to use it.

        My 2 cents, ciao

        Show
        Eloy Lafuente (stronk7) added a comment - Well, this is not my battle but I only can strongly disagree with this habit. The priority of one issue is a matter of how dangerous it is, cause data-loss, security problems and surely other aspects that contribute to pick the correct level. But, indeed, being reported by one partner IS NOT anything to consider when setting the priority of one bug. Not at all! There are alternative ways to communicate and improve response to partner-related issues: label them have one list somewhere (moodle.com?) encourage the teams to work on, at least XX partner bugs per week double pay to developers working on partner issues (joking). agree with the SCRUM team about to add partner issues to the sprints in a priority way. have some custom fields in case special information is needed. whatever we can use to communicate and be more responsive. But, once more, indeed, raising minor, cosmetic, issues by the only cause of being partner-related is 100% wrong. Sorry, I see it crystal-clear, hence my opinion. Let's use that field for / how we have agreed to use it. My 2 cents, ciao
        Hide
        Martin Dougiamas added a comment -

        Partner-reported issues do have some priority, and that policy must be retained. The priority of issues in STABLE backlog is defined as the "priority for the STABLE team" only (not only if it is dangerous etc). It's meant to make it easy for each scrum cycle to select what to work on.

        However, you are right that we should take care not to have ALL partner issues (even cosmetic ones) beat ALL non-partner issues, and the SCRUM selection process should probably make sure we have a defined mix of both.

        Let's discuss this in the next HQ meeting though.

        Show
        Martin Dougiamas added a comment - Partner-reported issues do have some priority, and that policy must be retained. The priority of issues in STABLE backlog is defined as the "priority for the STABLE team" only (not only if it is dangerous etc). It's meant to make it easy for each scrum cycle to select what to work on. However, you are right that we should take care not to have ALL partner issues (even cosmetic ones) beat ALL non-partner issues, and the SCRUM selection process should probably make sure we have a defined mix of both. Let's discuss this in the next HQ meeting though.
        Show
        Eloy Lafuente (stronk7) added a comment - http://docs.moodle.org/dev/Bug_triage
        Hide
        Rossiani Wijaya added a comment -

        Hi Michael,

        Thank you for reporting the bug.

        I read the forum discussion and would not suggest the css chance to force it to float left. Forcing it to float left, will break the display alignment for right to left language (eg: arabic).

        I fixed the issue by removing the table width, which is set to 100%. This seems to fix the alignment issue for both left to right and right to left languages.

        Please take a look and let me know if this works for you.

        Thanks

        Show
        Rossiani Wijaya added a comment - Hi Michael, Thank you for reporting the bug. I read the forum discussion and would not suggest the css chance to force it to float left. Forcing it to float left, will break the display alignment for right to left language (eg: arabic). I fixed the issue by removing the table width, which is set to 100%. This seems to fix the alignment issue for both left to right and right to left languages. Please take a look and let me know if this works for you. Thanks
        Hide
        Rajesh Taneja added a comment -

        Looks Grt to me Rossie
        +1 for this.

        Show
        Rajesh Taneja added a comment - Looks Grt to me Rossie +1 for this.
        Hide
        Petr Škoda added a comment -

        Setting real priority, otherwise our release notes and filters in Jira would not make any sense at all.

        Either the STABLE team has to find a new field or the rest of the world has to have a "real priority" field created. It is not acceptable for scrum methodology to hijack a field that was used for a different purpose for many years.

        Show
        Petr Škoda added a comment - Setting real priority, otherwise our release notes and filters in Jira would not make any sense at all. Either the STABLE team has to find a new field or the rest of the world has to have a "real priority" field created. It is not acceptable for scrum methodology to hijack a field that was used for a different purpose for many years.
        Hide
        Petr Škoda added a comment -

        Integrated, thanks.

        Show
        Petr Škoda added a comment - Integrated, thanks.
        Hide
        Andrew Davis added a comment -

        looks good

        Show
        Andrew Davis added a comment - looks good

          People

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

            Dates

            • Created:
              Updated:
              Resolved: