schooltool-developers team mailing list archive

[Alan Elkner <aelkner@xxxxxxxxx>]

Hey Justsus,

I merged your branch and resolved the conflicts.  There were only a
few, and the tests passed, so I pushed it.

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?

Thanks,
Alan