schooltool-developers team mailing list archive

[Alan Elkner <aelkner@xxxxxxxxx>]

Ok, clearly we don't have a clear agreement on Plans B and C, but
perhaps we can draw it up at the sprint.  In the meantime, I went with
Plan A, adding the call to filter_keys in generateExtraFields.  In the
case of the context being the person container, the add view, the list
will be empty causing the non-limited demos to appear.  After adding
the persoin to one of the key groups, the demos limited to those
groups will appear.  I added unit and functional tests for this.

Can we get this merged and address the Add Student, Teacher, etc. case
in another branch (perhaps post-sprint)?

Thanks,
Alan

On Thu, Jan 13, 2011 at 11:15 AM, Justas <justas@xxxxxx> wrote:
> On 01/13/2011 09:50 AM, Alan Elkner wrote:
>>
>> Hey Justsus,
>>
>> I merged your branch and resolved the conflicts.  There were only a
>> few, and the tests passed, so I pushed it.
>
>  Great :)
>>
>> I then created the filter_keys method that you wanted and set out to
>> use it in the generateExtraFields method of the PersonForm class.
>> Only problem is, when adding a new person, what would be the keys to
>> pass?  The person in question doesn't exist, so they don't belong to
>> any groups, and what's more, the context is the person container, so
>> I'm not sure what you would want there.
>>
>> Please look at the custom person views I created in schooltool.niepa
>> because the whole reason for the limit_keys is to allow us to only
>> show the demos for the type of person we are adding, student, teacher
>> of administrator.  Core schooltool doesn't have such a group-aware add
>> view, so it currently has no use for the filter_key method.  I could
>> see in the case of the display and edit views, where the person object
>> is the context, then I could put a call to filter_keys, but what to do
>> in the add case?   This is the discussion I was going to bring up in
>> schooltool dev, so I guess I'm doing it now.
>>
>> The question is: do we want to bring the niepa person add views into
>> schooltool core?  They depend on the presence of links that where
>> added to the niepa custom action link manager, as does
>> schooltool.cambodia, so that opens up discussion on what we want to do
>> there and when.
>> Another way of dealing with schooltool core's current group-unaware
>> add view is to leave it be and just not include any demos that have no
>> limit keys.  Then, after the user has successfully added the person,
>> the edit view of that person could have the demos that apply to the
>> groups the user belongs to.  That's clunky for the user, but without
>> group-aware add views, there's no other way.
>> Tom,
>>
>> Do you want the group-aware views and the necessary special action
>> links and filtered container vews in schooltool core while we are
>> merging the demos fields branch?  Or should we stick with the clunky,
>> add first, edit demos later approach for now, and deal with the more
>> complex group-aware views at the sprint?
>>
>
>  To summarize the options...
>
>  Plan A (just remove the demo fields in add forms):
>  1. Users fills in person form without the demo fields.
>  2. Clicks "Add".
>  3. Figures out that he should click the "Edit" action button, and fills in
> the demo fields.
>  4. Clicks "Done"
>
>  Plan B:
>  Show "Add teacher", "Add student", etc. action links *only* when there is a
> relevant group in the active school year.  Those forms would have the
> person's group pre-selected and non changeable, like in schooltool.niepa.
>
>  Plan C (update add person and add multiple persons views):
>  1. Users fills in person form without the demo fields
>  2. Clicks "Add".   If no group was selected, that's the end of operation.
>  3. User fills in the (filtered) demo fields for the newly added person.
>  4. Clicks "Done"
>
>  Drawbacks:
>  Plan A - very, very unintuitive
>  Plan B - users must create a schoolyear first to see them;  it will clutter
> the action bar somewhat:   "Add person", "Add teacher", "Add student", "Add
> administrator".
>  Plan C - most expensive.
>
>  Personally, I'd go with plan C.  It would be nice to put strong emphasis on
> group's dropdown.   Put it on the top of the form, or maybe even in a
> separate fieldset.  So it looked like you are selecting a type of the person
> to add:
>
> --=--Add person--=--=--=--=--=--=--=--
>  Group:  [ Teachers  V]
>
>  Fist Name ________
>  Last Name ________
>  username ________
>  etc.
>
>  [Add] [Cancel]
> --=--=--=--=--=--=--=--=--=--=--=--=--
>
>  Oh and as extra sugar, we could enhance the group select widget to display
> something along the lines "You need a school year to add teachers and
> students" instead of the dropdown when there is no school year.
>
>  Well, that's my two cents.
>
> Justas
>
> _______________________________________________
> Mailing list: https://launchpad.net/~schooltool-developers
> Post to     : schooltool-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~schooltool-developers
> More help   : https://help.launchpad.net/ListHelp
>