Re: [iola-conversion-tool] Bug when Adding a document to the tracker

[Robert Sparks <[e-mail]>]

That's really surprising, and I want to double-check that we haven't 
accidentally lost something.

Your search was on the production code?

I'm seeing idinternal.area_acronym get used in trunk at
idindex/views.py: def all_id2_entry(id):
  ....
./idindex/views.py-    if id.idinternal:
./idindex/views.py-        try:
./idindex/views.py:            area = id.idinternal.area_acronym


and in the search form
/idrfc/views_search.py:            
q_objs.append(Q(area_acronym=query['area']))

What are those replaced with in the new code?

RjS

On 2/22/12 11:18 AM, Ole Laursen wrote:
> 2012/2/21 Robert Sparks <[e-mail] 
> <mailto:[e-mail]>>
>
>     The biggest is that the form didn't ask for the area the document
>     should be associated with.
>     It occasionally happens that an AD from outside the area takes the
>     shepherd role for a document, so
>     you can't infer this from which AD is assigned.
>
>
> Right. At the moment, we don't store an area at all. Grepping for it, 
> the only place I managed to find using the attribute apart from the 
> edit form is the agenda document template where the proxy wrapper will 
> infer the area from the WG (if there's a WG) or else from the 
> shepherding AD.
>
> The search page looks for the area of the WG in the old schema if you 
> do a search for area, not the area attribute which is perhaps not 
> surprising if it's only set for documents in the IESG process.
>
> So do you think this is a problem still?
>
>     Less important, (but important none the less), the fields are
>     initially populated very badly.
>
>
> That's odd. Or rather, it's odd that how it worked before because 
> AFAICT from the documentation to Django, it shouldn't have. :) It 
> could possibly be because of the new Django version. In any case, I 
> think I managed to fix this now.
>
> Ole