Having this non-functional link will not just be confusing for non-Studio
users; it will cause content team members to believe they can edit the
content in Studio.  In reality, however, all changes made in Studio will be
lost, since the content source will be in a repository (e.g. github).  This
will create significant headaches for the MITx course production teams.

We're glad to hear that Studio will have version-tracking.  However, it
still has no ability to allow:

1. Global changes / replace

2. Global search

3. Visibility of efforts to others in the course authoring team (no social
coding)

4. Loading of python code into /python_lib or /code

5. Ability to compile multiple modules from high-level source code, like
latex

In fact, the majority of MITx courses on campus are authored with
latex2edx.  And several of our EECS courses have written their own custom
compilers which generate XML from their own high-level problem description
languages.  These courses are all expecting to be able to use the edX
platform (and may someday come to edx.org), but will not be using Studio.


On Thu, Mar 20, 2014 at 7:57 AM, Victor Shnayder
<notifications@github.com>wrote:

> In lms/djangoapps/courseware/courses.py:
>
> > +
> > +def get_cms_block_link(block, page):
> > +    """
> > +    Returns a link to block_index for editing the course in cms,
> > +    assuming that the block is actually cms-backed.
> > +    """
> > +    locator = loc_mapper().translate_location(
> > +        block.location.course_id, block.location, False, True
> > +    )
> > +    return "//" + settings.CMS_BASE + locator.url_reverse(page, '')
> > +
> > +def get_studio_url(course_id, page):
> > +    """
> > +    Get the Studio URL of the page that is passed in.
> > +    """
> > +    is_studio_course = (modulestore().get_modulestore_type(course_id) == MONGO_MODULESTORE_TYPE)
>
> I want to understand the consequences here: if merged as is, it would show
> an edit in studio link in courses where people are actually using an
> store-in-github -> import-into-studio workflow, right? The link won't be
> useful in those cases, but it doesn't seem to be problematic either, so I'd
> rather not add yet another config setting just to turn it off. As an aside,
> we're actively working on making all the different types of XBlocks work in
> Studio, and on changing to the version-tracking Studio backend, so
> hopefully many of the reasons why it doesn't work for some MITx courses
> today will go away in the next few months.
>
> --
> Reply to this email directly or view it on GitHub<https://github.com/edx/edx-platform/pull/2552/files#r10791494>
> .
>