On Thu, Jun 30, 2016 at 3:04 PM, Braden MacDonald <[email protected]> wrote: > > What I think would be much better would be if the LTI XBlock could just > declare a course-scoped field called "lti_providers" which contains a list > of LTI providers (name, URL, credentials). Then authors configure that > once, and it gets applied to all LTI Consumer XBlocks in the course, with > no duplication of data and no need to authors to enter things like the > "URL" or "lti_id" every time they want to add another instance of an LTI > tool in the course. >
Huge +1 for a course scope. The CourseModule is a dumping ground of all kinds of settings info for different block types, just because there is no other place to store that kind of information today. I also completely agree with your points about favoring a course view for the data migration aspect. I think it would also be important to allow the default value of a normal > usage-scope field to be inherited (default is the same for all blocks of > that type in a course), but still overridable per usage. This would allow > instructors to do things like say "All problems in this course should allow > 5 attempts", but change that on a per-block basis as necessary. Currently, > AFAIK, there is no way for instructors to change some setting like that for > all blocks in a course. > I'd shy away from having content and usage scoped fields arbitrarily inherit from course scoped ones. While it's a powerful idea, I think that there's potential for confusion there, particularly when interacting with fields that are inherited from parent to child already. Right now, if you set "max_attempts" to 5 on the root course module by editing the XML, it will inherit down into all of the leaves. Allowing arbitrary overrides might mean that a Capa problem gets a max_attempts attribute set on it because it was inherited down from a sequence that had a course-scoped field of the same name. It also adds complexity because for the first time, we'd have the same field name mapping to multiple scopes. I think that we can get much of the same effect in a simpler way by using the course scope for explicit default values stored under a different field name or names (e.g. a course scoped field named "defaults"). That way, we don't have to worry about weird inheritance interactions at all, or wondering where the value of a certain field really came from. All that being said, I really feel like grading policy stuff should be in its own API (say a runtime service), just because it would help us with more dynamic content. But that's another big discussion, and probably not something we're going to get around to for a while. As a side note, one thing I want to be careful of in this discussion is the "Tab" naming convention. Tabs are a UI implementation detail, and they don't necessarily carry over to things like Mobile. When we talk about tabs, we're talking about a number of logically different things: the root of the courseware DAG, things that are still course content but aren't necessarily under the root, course level block views that don't directly tie to def/usage scoped fields, admin functionality like the instructor dashboard, etc. It would be good if we could refine our vocabulary for these concepts, and not constrain ourselves to a UX decision made during the prototype days of 2012. Take care. Dave -- 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_oFPyeCRUCjL%2BjC3AcjUaD_sMR245TcDt%2Bjot0eDyBsTgy0w%40mail.gmail.com.
