Hi Colin, I agree that you've run into a bug, and that the LMS should support your use case.
DAG support in edx-platform has always been kinda spotty. They're not often used, they can't be created in Studio, and they add complexity around navigation, inheritance, access checks, and performance. Even for little things, like being able to assume that you can derive a container div id from the usage_key. I think one of the original goals was to have a stronger distinction between usages and definitions, which might have made this more straightforward -- but that's not where we are today. There's a short writeup here: https://openedx.atlassian.net/wiki/spaces/EDUCATOR/pages/34734086/Why+is+the+Course+Structure+a+DAG I'm not on the team that would field that ticket, but I'd appreciate it if you could please tag me on the bug you file. Thank you. Dave On Fri, Dec 8, 2017 at 12:44 PM, Colin Fredericks < [email protected]> wrote: > Back from pretending to be a whiner on video to being an actual whiner in > real life. > > After a quick dive into the codebase, I found this: > > # TODO (vshnayder): if the tag is a pointer tag, this will > # break the content because we won't have the right link. > # That's also a legitimate attempt to reuse the same content > # from multiple places. Once we actually allow that, we'll > # need to update this to complain about non-unique names for > # definitions, but allow multiple uses. > > The current implementation feels glitched, and it's clear from the notes > that the original intent was to allow multiple uses of the same component. > I'm going to file a bug report. > > > On Fri, Dec 8, 2017 at 10:40 AM, Colin Fredericks < > [email protected]> wrote: > >> Good news: got Devstack up and running in about half an hour, which is a >> new record for me! Also found the source of the problem; see below. >> >> Bad news: Man, that's a lot of warnings. Like, even before I try to >> import the course, just piles and piles of them. Then, once I *do* >> import the course, I end up with an import log that's 3.7 MB of *just >> straight text*. Luckily the issue was related to one of the most common >> warnings: a non-unique filename. The line looks like this: >> >> 2017-12-08 10:25:04,888 WARNING 14647 [xmodule.modulestore.xml] >> xml.py:170 - Non-unique url_name in xml. This may break state tracking for >> content. url_name=45f8da6114d14701a46d176ea8e38de1. Content=<problem >> url_name="45f8da6114d14701a46d176ea8e38de1"/> >> >> I tested by making a tiny new course with two sections, one subsection >> each, one unit each. One of them had a problem component. Then I exported, >> copied the XML for that problem into the other unit, and re-imported. The >> second occurrence of the component did not appear. I checked switching the >> order of the sections to make sure that it was the second one in the course >> outline (which it is) and not just the second one that I added >> chronologically (no). The problem is even stripped from the XML as the >> course is rebuilt (I checked by re-exporting). >> >> It may also be useful to know that *no component* in a unit with a >> duplicate will show up. The presence of the duplicate makes it so that none >> of the others appear. This is particularly bizarre for me, because the >> duplicate does not appear in the XML export. If you make your XML edit, >> import, export, and *reimport*, you get a unit where the remaining >> components appear. If you just edit and import, no luck. >> >> Yes, I know, there's not much of a use case for duplicate components, *but >> there is one*. I did what I did intentionally. It should break nothing. >> Nevertheless, *only the first appearance of a particular component >> counts*, and the rest of them are thrown out. >> >> I'm gonna see what I can do to work around this, but I need to go be >> voice talent for a video now. >> >> >> >> On Fri, Dec 8, 2017 at 8:16 AM, Peter Pinch <[email protected]> wrote: >> >>> Hi Colin. >>> >>> Error reporting on course imports is definitely lacking. If you're up >>> for it, I'd recommending running a devstack locally and doing a test >>> import. You can watch the logs while the course is imported and you might >>> see some helpful hints. >>> >>> If you have an installation of open edX set up with the sysadmin feature >>> turned on, you can see more logging by importing via git. This is >>> equivalent to using the import management command, but the log output is >>> stored in mongo and there's a "git logs" page in the sysadmin panel for >>> viewing them. >>> >>> Even then, some errors don't show up in the logs and I've sometimes had >>> to resort to a bisect and import strategy to identify the part of the >>> course causing issues. >>> >>> - Peter >>> >>> >>> >>> >>> On Dec 7, 2017, at 9:16 PM, Colin Fredericks <[email protected]> >>> wrote: >>> >>> If you write your course via directly handling XML instead of in Studio, >>> I've got a question that you might be able to help with. >>> >>> Recently I wrote a script to create some extra course structure. (We >>> have thousands of problems and I'm making places for them to sit.) I copied >>> the resulting XML files into the course's folders in the appropriate >>> places, rezipped and uploaded, and it doesn't quite show up right. >>> >>> All the "structural" items show up fine. The chapter file appears >>> appropriately as a section in Studio. I have subsections (sequentials) >>> within it, and units (verticals) within those. However, at the component >>> level, something fails. Neither Studio nor the live view of the course show >>> the problems that should be sitting in those units. Studio loads for a few >>> seconds and then shows an empty unit. >>> >>> I've compared the XML output from my script to the XML generated and >>> exported by Studio, and they look equivalent to me. I know the problem >>> files are there and working properly, because I can get to them via XBlock >>> URL. At this point I'm wondering if Studio has some secret list of which >>> problems it has ok'd and which ones it hasn't. I'm stumped. >>> >>> If anyone from edX is reading and wants to see this in action, the >>> course in question is QMBio: >>> https://studio.edx.org/course/course-v1:HarvardX+QMB1+2T2017 >>> Check out the bottom section on the list, named "Adaptive Problems". >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "General Open edX discussion" group. >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/edx-code/fc209309-006a-4675-9441-f4ea96704471%40googlegroups.com >>> <https://groups.google.com/d/msgid/edx-code/fc209309-006a-4675-9441-f4ea96704471%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "General Open edX discussion" group. >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/edx-code/C26DA522-A951-4B05-8460-6A42BBF1A507%40gmail.com >>> <https://groups.google.com/d/msgid/edx-code/C26DA522-A951-4B05-8460-6A42BBF1A507%40gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> > -- > You received this message because you are subscribed to the Google Groups > "General Open edX discussion" group. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/edx-code/CABmE_WLH6eqWz-0skh_kP%3DR06WRHBcxdnHdzWm% > 2BdQFHt24AgKw%40mail.gmail.com > <https://groups.google.com/d/msgid/edx-code/CABmE_WLH6eqWz-0skh_kP%3DR06WRHBcxdnHdzWm%2BdQFHt24AgKw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "General Open edX discussion" group. To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/CAO_oFPx9pqkT7WpmKDhemXAJ_XidcUT8pXhSVPcYEAJm_nrbEw%40mail.gmail.com.
