[TC_AUTHOR_53] Text Xblocks do not render Xblock Title in LMS

[yuliiazubak]

Release

Redwood

Expected behavior

The title of each XBlock should be visible to students in the LMS.

Actual behavior

The title of the XBlock is visible in the CMS but does not render in the LMS. Students cannot see the title of the XBlock. This issue affects the following XBlocks:

• Text
• Announcement
• Anonymous User ID
• iFrame
• Raw HTML

Xblocks title visible in CMS

Blank titles in LMS

Steps to reproduce

1. In CMS, add any of the following XBlocks to the unit: Text, Announcement, Anonymous User ID, iFrame, or Raw HTML.
2. Add content to the XBlock and save the changes.
3. Publish the unit.
4. Switch to the LMS view as a student.

Additional information

Zooming Image tool and Problem Xblocks have no problems with rendering the title in the LMS

[yuliiazubak]

label: release testing

[mariajgrimaldi]

For problems, the display_name is displayed by adding it automatically to the block fragment itself:

But for text blocks, that doesn't happen.

I tested in redwood and quince; @DonatoBD, can you help me test in older versions to make sure this was always the case? Thanks!

[sarina]

For Text components, at least, this is not a regression. I don't ever recall seeing the text component Studio title rendering in the LMS.

I don't know what release the eduNEXT site is on, but it's not newer than Palm iirc. You can see here https://training.openedx.org/courses/course-v1:Axim+DemoX+Demo_Course/courseware/30b3fbb840024953b2d4b2e700a53002/4e1de5e13fc3422997fe246b40a43aa1/?activate_block_id=block-v1%3AAxim%2BDemoX%2BDemo_Course%2Btype%40sequential%2Bblock%404e1de5e13fc3422997fe246b40a43aa1 a bunch of text components, who have titles in the Studio:

but no titles in the LMS.

[sarina]

I said this to @crathbun428 already, but, I would say if this is a regression it's med to hi priority but I wouldn't consider it a blocker. if it's not a regression, i actually think it should be a product conversation for each component as to whether or not to make a behavior change - and I might argue against it. In the course I made, my text components often have default, shitty, or shorthand names I wouldn't want exposed, specifically because I knew they wouldn't render in the LMS and it was useful to have notes to myself.

[DonatoBD]

Hi @mariajgrimaldi and @sarina, indeed this seems to be the normal behaviour of these components, I tested it on old versions (nutmeg, olive palm) and the same thing happens. Should we leave a note in the tests so that it is not marked as failed again?

[sarina]

This is a good question, and not one for us to figure out right now. @jmakowski1123 @crathbun428 - as we refine the tests for Sumac, let's look at this test and any others to figure out what the behavior should be, and whether or not to:

• Keep this test as-is and file bugs to fix behavior;
• Keep this test but modify so it captures current behavior;
• Deprioritise this test entirely, removing it from the test sheet

For now, what's a good way of marking this test as "do not test for Redwood but revisit for Sumac"?

[jmakowski1123]

One of the core product projects is to reassess all of the text block types anyway, and I'd like to do that before Sumac. That will then impact what and how we test here.

[mariajgrimaldi]

For now, what's a good way of marking this test as "do not test for Redwood but revisit for Sumac"?

@sarina: We can mark this as complete and leave a revisit warning in the instructions column. Or, if we already have a list of these kinds of tests, we can add them to the suggestions tab, which we should revisit for sumac.

[sarina]

Added to suggestions list, and marked the test as passing.