Did you mean "should *not*"? The problem is that Studio believes these
fields are settable directly on sequentials and that sequential owns these.
It uses the very naive save_item method to set them (that method accepts
all categories and a dict of metadata k:v to set/delete).

Other approaches I thought of:

   - send back metadata dict as {'lms': {'due': .., 'start':..}} thus
   exposing namespaces to the client
   - change save_item to look in the xblock's fields for the field, if it
   doesn't find it, then look in the xblock's namespaces' fields (I had coded
   this but thought that making ownership direct was the more obvious approach)

I changed save_item to introspect the xblock for the field type to use it's
from_json method to encode (thus catching bad data v the old directly
manipulate the _model_data which would allow bad data through until it
tried to write it to the db)


On Wed, Jul 17, 2013 at 4:17 PM, Calen Pennington
<notifications@github.com>wrote:

> In common/lib/xmodule/xmodule/seq_module.py:
>
> > @@ -20,6 +23,12 @@
> >
> >  class SequenceFields(object):
> >      has_children = True
> > +    start = Date(
> > +        help="Start time when this module is visible",
> > +        default=datetime.fromtimestamp(0, UTC),
> > +        scope=Scope.settings
> > +    )
> > +    due = Date(help="Date that this section is due by", scope=Scope.settings)
>
> The sequence module is ignorant of these fields, so it should define them.
> Whoever is setting them should be using .lms.start and .lms.due.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/edx/edx-platform/pull/421/files#r5252835>
> .
>