Adjustments to student/user data

Hi Ross,

As you know every school has its own particularities in regard to demographics of their students. Therefore I wish to make a few changes to the application form and student/user data.

Examples:

  • Changes to terminology, e.g. “Last name” instead of “Surname”
  • Remove fields, e.g. “Preferred Name”, “Official Name”, “Name in Characters”, “Citizenship”, etc.
  • Add fields, e.g. “Other names”, “Church”, etc.

How is this best achieved? Are there things I must be aware and particularly careful?

Kind regards,
Roman

Roman,

v12 has a new feature under Admin > System Admin where you can substitute interface strings, as they are displayed to users. So, for example, you can change “Surname” to “Last name”. v11 supports custom fields for users and the application form (under Admin > User Admin in the main menu, then Manage User Custom Fields in the module menu.

In terms of disabling fields, this is currently not possible.

Thanks,

Ross

Hi Ross,

Thanks for the info!

The simplification of the application form is rather important to me. There are too many fields we don’t need.

I know it’s far from being ideal, but what do you think if for the mean time I hack the code and hide those fields not needed. Do you have a better idea?

Kind regards,
Roman

Roman, you can do that, but some of them are required fields in the Manage Users, and so you may end up with records you cannot save due to insufficient information. That, and the next update will remove the changes. Feel free to play (it’s open source after all : ) but be cautious, as we will be less able to help you with knock on issues you create for yourself (due to a lack of time on our end).

We may look to simplify the form in a future version.

Ross

Hi Ross,

Thanks for the advice!

I’m not happy about hacking code but the bulkiness of the form is an issue here. Hopefully I can eliminate these hacks in the future.

I can submit a list with the minimal content to you. You may be able to use it in the simplification process. Please let me know.

Kind regards,
Roman

Roman,

Yes, please post the list here, and we will see what we can do to implement it in v13. No promises, but will put it on the todo list, which gives it a 60-80% chance of getting done.

Ross

Hi Ross,

I have reworked the student application form trying to reduce bulkiness. What do you think?

Student Personal Data

  • Surname
  • First Name
  • Gender
  • Date of Birth

Student Background

  • First Language
  • Second Language

Student Address

  • Residential Address
  • Postal Address

Student Contact

  • Email
  • Phone 1
  • Phone 2

Student Education

  • Anticipated Year of Entry
  • Intended Start Date
  • Grade Level at Entry
  • Previous Schools

Guardian Personal Data

  • Title
  • Surname
  • First Name
  • Gender
  • Relationship

Guardian Background

  • First Language
  • Second Language

Guardian Address

  • Residential Address
  • Postal Address

Guardian Contact

  • Email
  • Phone 1
  • Phone 2

Guardian Employment

  • Profession
  • Employer

Roman,

I am travelling for the next 4 weeks, and so not able to really get into this right now. I agree that the form could do to be reduced, but this must be done in a way that is optional, as some schools (such as my own) really do need these fields. Are you hoping to code some of this up yourself?

Thanks,

Ross

Hi Ross,

In my opinion, the table gibbonperson is rather congested. A step forward may be to make most of these fields so called custom fields leaving only the core attributes.

Kind regards,
Roman

Roman, this is a question that there is most likely no one right answer to. In terms of database optimisation, I feel that having these fields as real SQL fields, as opposed to the non-SQL-field storage used for custom fields. In terms of interface, perhaps the option to disable certain fields would be better. In what way exactly is this causing problems for you?

Ross

Hi Ross,

I have studied other school solutions as well, e.g. school tool and centre sis. They also allow custom fields but use a different technique to store data. Both use real SQL fields instead of a serialized string, which may cause performance issues.

I wish Gibbon’s database structure could be lighter and more flexible.

Kind regards,
Roman

Roman,

So, in those systems, when you create a field, it uses SQL to set that field up as a real database field? Are the fields stored in a separate table, or in the same table as the inbuilt fields?

Thanks,

Ross

Hi Ross,

I’m not sure how it is done. The fields are definitely stored in the same table.

Kind regards,
Roman

Roman,

I’ll let this germinate, and it might happen one day. But no promises for now.

Ross

@admin @meierrom This seems to be the only post dealing with this. But it is old, is it now possible to change the terminology like as mentioned below in v19?

Hi Ross,

As you know every school has its own particularities in regard to demographics of their students. Therefore I wish to make a few changes to the application form and student/user data.

Examples:

  • Changes to terminology, e.g. “Last name” instead of “Surname”
  • Remove fields, e.g. “Preferred Name”, “Official Name”, “Name in Characters”, “Citizenship”, etc.
  • Add fields, e.g. “Other names”, “Church”, etc.

How is this best achieved? Are there things I must be aware and particularly careful?

Kind regards,
Roman

Sorry to bother ! Got it from this post:

https://ask.gibbonedu.org/discussion/2303/string-replacement-code-meaning