When I was debugging the code, the key for a field with Scope.preferences was just the block type (in my case, “mit6004”).  This makes sense to me, since a field with preference scope should care about scenario name.  

So more rationally, scenario should be None and tag should be from the key.  But in either case, I’d expect the scope_id field in the database to be just the block type for a Scope.preferences field.

Sorry about the sloppy pull request.  I’m just learning the ropes...

- Chris

On Apr 30, 2014, at 4:59 PM, David Ormsbee <notifications@github.com> wrote:

> In workbench/models.py:
> 
> > @@ -79,7 +79,12 @@ def get_for_key(cls, key):
> >          scope_id = key.block_scope_id
> >  
> >          # Ask our ID Manager for how this scope_id maps to scenario and XML tag
> > -        scenario, tag, _ = scope_id.split(".", 2)
> > +        # The following line throws an error for fields with Scope.preferences
> > +        #scenario, tag, _ = scope_id.split(".", 2)
> > +        scope_id = split('.')
> > +        scenario = scope_id[0]
> > +        tag = scope_id[1] if len(scope_id) > 1 else None
> 
> Does that mean that tag is null when something is in Scope.preferences? What does key.block_scope_id look like when something is preferences?
> 
> —
> Reply to this email directly or view it on GitHub.
>