CiviCRM Community Forums (archive)

Could you give a little more detail about your requirements?

My immediate reaction is that you should use a contact sub-type of 'student' for the students and then use groups for their grades, but that is based on the assumption that by 'grades' you mean the groups they are taught in, not the marks they receive.

If you want to keep any history about the grades (ie which grade they were in last year or the year before) then you would need to use groups/sub-groups rather than tags.

You are right, extra detail is often helpful.

Whether you set these up as groups or tags (or custom data just to get your eyes spinning more) there is no reason why changing plan would require you to change 350 records one at a time.

Make the call about Groups v tags v fields (and yes contact sub types and relationships could also work for you) is more art than science (or good luck v good planning) - and I say that because often the advantages / disadvantages don't show up for a while.

But the good news is switching from one to another might involve doing it 13 rounds, not 350 (but i realise you may have twigged that already)

So some questions. Do kids ever need to redo a year, or do they ever skip a year (both are possible in our eduction system)

Do you want to be able to see eg John did Grade 4 in 2013 and did Grade 5 in 2014 - or don't the years matter?

Here is what I hope is a useful synopsis of a few of the gains/losses

Tags - show on the Contact Summary screen but heavy usage can outweigh this advantage as it clutters up the screen, v easy to search
Groups - show history and are required for Mailing but not on Summary screen, very easy to search
Relationships (as in make each Grade a 'contact' and have the student have a relationship to it for the relevant year) - shows history including start/end dates and can easily be set to show on Summary Contact screen with a minor tpl tweak, a bit more effort to search

Also note of course that both Tags and Relationships can still be used and then have Smart Groups built off them if that helps with workflow.

Has that helped you, I doubt it. I remember writing a long piece years ago to try and distil the essential benefits etc between groups-tags-fields and since then multiple record fields and relationships (and Activities) have all proven to be able to be contenders for being the 'right way' in other situations.

I think there is also a tendency for us to keep using what we get most familiar with. For example we hardly use Tags in most of our projects, but other developers use them extensively.

You might want to look as well at civischool, I don't know much about the project beside the name sounding quite relevant, and that the author knows civi pretty well

You can probably do most of the operations by batch (classes). So you don't have to do, say, changing from one grade to another one by one, but can do that for all the students of the class in one go. Now you have an incentive to put as many students as you can per class

The "cleaner" model might be to use multiple custom fields
# custom set year
- year (number, eg 2013
- grade (1-13) select
- result/score/whatever you want to store about each year

each student can have several of these items (one per year)

To make it more practical to use, you create a group for all the students in the current year and a grade, or whatever groups make sense for you. You might use smart groups, but re doing the 13 groups once a year might not be such a big deal

But whatever you feel more comfortable with is fine, it's not that much of a PITA to change from one system to the other.
X+

it is not a published extension, primarily since it requires some amount of mysql tweaking manually.

the code is here:

http://svn.civicrm.org/sfschool/trunk/

if you have the funds, you might want to get in touch with web access to install and configure it for you. will help them take the next step and automate a few more parts of it and towards a step of making it usable by the larger school crowd

lobo