← Back to team overview

schooltool-developers team mailing list archive

Re: Custom person views

 

Hi,

On 01/17/2011 08:33 AM, Alan Elkner wrote:
Hey Justas,

Ok, I implemented plan B as well and created the Add Teacher, Student
and Administrator views.  I coded them to fail safe when there is no
active schoolyear, just leaving the groups list empty, although I can
see your point about not showing the links in that case.  Would it
take much to add a custom action links manager for the PersonContainer
context only?
Umm, why do you need a custom action links manager? If for disable-if-no-schoolyear, viewlets should do that themselves...
I don't want to hold up this branch from getting merged
any more than necessary.
  Thanks, Alan, I'm ok with merging it :)

A small note - you don't need to i18n:translate content that you are always replacing (with tal:replace or tal:content).

I agree with Tom, this should be a great improvement for the users. Just to put some minor quirks on the table...


Say we have two demo fields Ethnicity (students only, optional) and Teacher ID (teachers only, required).

[no schoolyear]

  "Add Person", "Add Multiple Persons" works fine.

"Add Teacher" and "Add Student" allows filling the special fields, but don't add to the persons to respective groups. Hence you actually add simple persons there. And fields will not be displayed and can't be edited until user remembers to manually add the persons to respective groups, after the school year is created.

We could either disable the links if no schoolyear, or just move them to schoolyear page. 2010->"Add Teacher" (apologies for suggesting more work for you, Alan...)

[with schoolyear]

  "Add Teacher", "Add Student" work fine.

"Add Person" and "Add Multiple Persons" have a little quirk. You don't see the special fields, even though you *can* select the desired group. The result is that you have a teacher with required field that is not filled in. If you want to fix a typo in his name, you'll be forced to also enter Teacher ID.

This glitch is not new, same happens if we add required fields to existing demographics setup, or add persons to groups later on (a teacher added to administrators for example).

Cheers,
Justas


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





References