Moodle

It is very surprising that Moodle does not support a state/province field out of the box considering all of the largest countries of the world are composed of states or provinces.

In fact ALL of the following countries are composed of states or provinces or regions:

The United States of America, the United Mexican States (yes, that is the legal name of Mexico), Canada, Russian Federation, Federal Republic of Germany, Italy, India, Federative Republic of Brazil, China, Colombia, Afghanistan, Albania, Algeria, Argentina, Armenia, Australia, Austria, Azerbaijan, The Bahamas, Bahrain, Bangladesh, Barbados, Belarus, Belgium, Belize, Bermuda, Bolivia, Bosnia and Herzegovina, Bulgaria, Cambodia, Chad, Chili, Congo, Costa Rica, Croatia, Cuba, Democratic Republic of Congo, Denmark, Dominican Republic, Ecuador, Egypt, El Salvador, Finland, France, Greece, Guatemala, Honduras, Hungary, Iceland, Indonesia, Iraq, Ireland, Jamaica, Japan, Kenya, Kuwait, Madagascar, Malaysia, Morocco, Myanmar, Netherlands, New Zealand, Nicaragua, Niger, Nigeria, North Korea, Norway, Pakistan, Panama, Paraguay, Peru, Philippines, Poland, Portugal, Romania, Saudi Arabia, Senegal, Sierra Leone, Somalia, South Africa, South Korea, Spain, Sweden, Syria, Taiwan, Tajikistan, Tanzania, Thailand, Tunisia, Turkey, Turkmenistan, Ukraine, United Kingdom, Uruguay, Uzbekistan, Venezuela, Vietnam, Zambia and Zimbabwe.

http://www.atlasquest.com/help/supportedplaces.html

And some countries REQUIRE a state or provinces for a valid address, such as the United States or Canada, where the states or provinces determine the city/town names, not the federal government. (The largest countries like the United States, Canada, Mexico, Russia, China, etc.. are all unions, and the states have broad domestic powers, which often includes naming towns, building & operating roads & schools, and have their own police force.) This means that while there can only be one Springfield in a state, there can be many Springfield's in the United States (in fact, there are 15 of them).

I would suggest that the state/ province field be made a standard field considering that over 100 countries in the world have either states, provinces or regions within them.

I'll see if I have some time next week to look at this and see how difficult it might be to come up with a patch. Peace - Anthony

Yes, I would like to see this as well!!!

I have a State/Province field and a Zip/Postal Code field and I need to Address fields, all of which are down at the bottom in the Custom Fields area... not very "data entry friendly"!

And also to avoid clutter, I like to use the Hide Advanced button which hides the Address and Phone fields in the Optional section, so I had to create two new Address fields and two new Phone fields in the Custom section.

A quick look at the code seems to show that the order is pretty much hard coded (as well as which fields are 'Advanced'). It would be nice if there were a setup page or form that did ALL of the following on the one page:
(1) you could just move fields up or down (re-order them) with those little up/down/re-order arrows,
(2) you could choose whether the fields are part of the Hide Advanced button or not,
(3) you could choose whether the fields are locked, unlocked or unlocked if empty, and
(4) you could choose whether the fields are visible or hidden to the student themselves when they edit their own profile.

Thanks

I've sent a message to Jamie to get some input. Looking more closely at this, I'm not sure how it would be best to implement it. It will require some creativity and designing of some type of user interface to handle the option to sort. My instincts tell me that the easiest way is simply to re-arrange the /user/editadvanced_form.php file to one's liking but I realize when it comes to the profile fields this may not be intuitive. I like the suggestions but it will take a little thought to figure out the best way to implement this. Peace - Anthony

I think it would be a wonderful addition to formslib to have a way for users with the correct privileges to be able to create and / or edit full forms. We could have some code that can read form definitions from the db, to have a UI to edit them and to be able to display the form for the user and process forms that have been submitted in the normal way. This would be useful throughout Moodle.

Jamie - Thanks for your feedback. I like the idea of allowing forms to be customized and see that it could be quite useful for a variety of customizations throughout the site. In terms of implementation, what are your thoughts? I imagine having a table that contains a list of the various moodle pages (for example /user/view.php) so the table mdl_form would have an id field and the URL. For each form, there would be a 1->M table for the elements on the page such that the table mdl_form_element would have the fields id, formid, elementname, sortorder. The logic in opening a form would be if a custom form definition exists in mdl_form then use the sortorder field to determine the order to print the elements. What I don't know is how we would handle some of the process that takes place as the page is generated. Would there be instances or exceptions that we would not want the page to be reordered? I just through these ideas out to help encourage working out the best way to implement this. I'm going to leave this in your capable hands but am happy to be of whatever help I can. Peace - Anthony

hi,

Unfortunately I don't see myself as having time to tackle this. But in case anyone else has...

I was thinking that only a few forms would be user editable. I think this would be best done as a class extending moodle_form.

Then the typical definition method would be overridden in the sub class to load the definition from the db. The db structure would be pretty much as you outline above I think with possibly some more fields. Groups would probably need to be supported even in the most basic implementation as radio and checkbox elements probably need to be in groups.

One caveat is that Petr Skoda was talking about the need to rewrite the core of formslib at some point because of difficulties with use of defintion after data but it is likely that the api for defining forms and thus code to load form definitions from the db would still work with new internals.

Jamie

Jamie - Based on the number of votes, I think we should probably then reassign this to someone who might be able to pick it up and give it further direction. I was thinking of the challenges that this would present. Perhaps we can convince someone to adopt this issue. Peace - Anthony

Why don't we have a 'User profiles' component here? Anyway, reassigning away from Jamie. It is not really a formslib issue anyway.

To resolve the State/Province issue, do the following:

1. Alter your user table (i.e. mdl_user) to include a province field of type text.

2. Add the following 2 lines of PHP in your lang/en_utf8/moodle.php:
$string['missingprovince'] = 'Missing state/province';
$string['province'] = 'State/Province';

3. Add the following 3 lines of PHP in your login/signup_form.php:
$mform->addElement('text', 'province', get_string('province'), 'maxlength="20" size="20"');
$mform->setType('province', PARAM_TEXT);
$mform->addRule('province', get_string('missingprovince'), 'required', null, 'server');

4. Add the following 3 lines of PHP in your user/editlib.php (line 200):
$mform->addElement('text', 'province', get_string('province'), 'maxlength="20" size="21"');
$mform->setType('province', PARAM_MULTILANG);
$mform->addRule('province', $strrequired, 'required', null, 'client');

Hi everyone, I'm a new user in the US trying to configure my Moodle site.

I'm shocked that this is considered a "minor" issue and has been sitting around for two years.

Most people I know would have no way of modifying PHP code. I would love to have someone decide to fix this.

Current development efforts are focused on Moodle 2.0. I am hoping to see 1.9 get some much deserved attention at the Moodle Hackfest in Prague. With limited resources it is always a challenge to keep up with demand. I know that some of the work on Moodle 2.0 is aimed at providing more flexibility for theming and navigation. I am not sure how some of that work may facilitate things here. I know that it may seem like a fairly simple issue to tackle, the way that Moodle handles forms and creating a good user interface so that this can be done efficiently and provide the flexibility requested will require some thought. In terms of actual functionality this has been minor because there is a workaround if folks want to manually re-arrange things. I have done this for some production sites and while it does require an investment of resources and some time it is not that difficult. I have added my vote to the issue and hope to see it get addressed soon. I suspect that it will be something to be considered for 2.0 as I would not envision this feature being added to 1.9. If you have a specific need, feel free to contact me and I will do what I can to help you out. Peace - Anthony

This patch will apply the en_utf8 lang changes, province field in signup, edit user, view profile and bulk upload users process.

Database change :-

alter table mdl_user add province text not null;

Adding 2.0 as affected version. It does make sense to me to have a city and state or province. The language string can be customized as desired but currently we just have city and I think state and postal code would make sense to cover a majority of addresses. Beyond adding those two fields to the mdl_user table, it would be nice to have a sortorder for the profile fields. Ideally, I think this should be stored in $CFG. I would think that it should allow for sections and then order the items. This would be the default ordering for viewing and editing user profiles. Doing so would allow custom user profile fields to be included in the natural place where a particular site needs it. Peace - Anthony

p.s. I am just thinking out loud and not sure how this might be incorporated with some of the work being done on themes 2.0, but I wonder if it would be possible for a page to be reconstructed in a particular order whereby the page could be identified and for that page, there could be an array of columns, blocks, sections, etc. that contain particular pieces of data. In essence, I'm raising the question if there would be a clever way of extending this to be useful for any page that needs special re-formatting or display in a slightly different way.

That's an interesting thought... give each field on the page it's own DIV tag with a custom ID and then use CSS to position each field anywhere you want, in any order you want!

Jeff - I am not sure it is that simple. I know there have been some discussions about this and I am just now coming back into the discussion after having been immersed in theology studies. I need to catch up and see where things are and what might be possible - I was just dreaming what might be ideal, now to see what is possible or what is likely to be. Peace - Anthony

It's relatively easy to re-order the displayed fields, (I have some code now that does this) - the hard part of this issue is setting up the gui to allow the fields to be re-ordered and set a config var. I'm thinking the best way would be to have a new capability that allowed an editing view of a form - (assigned to admins by default) - so that on the edit profile page, if editing is turned on, each field on the form would have some editing icons for move/hide, set as advanced etc. Not sure if I'll have time to finish a gui and get it into Core, but I should be able to get the re-ordering stuff into core and let people add an entry to the config themselves to set the order until a gui is finished.

although the "best" way for usability would probably be as mentioned above - allowing the fields to be re-ordered directly on the page - it doesn't look like this will be possible without extensive work on the mforms/quickforms lib - I'm reluctant to do this as it seems likely that quickforms will be replaced by something else in the future (at the very least because it has been superseded by quickforms2)

I'm thinking a separate page that displays the list of form fields and allows them to be re-ordered/hidden/advanced option enabled or disabled would be more appropriate at this stage - the page will be pretty specific to the user edit form, but I'll try to structure it so it can be re-used by other forms if needed. Obviously when/if quickforms is upgraded or replaced, this Gui page could be replaced by something better! - keen for feedback on this plan - any comments?

Since 2.0 is very close and since the ajaxy idea (although very desirable, sure!) is probably going to be a headache with unexpected issues (expect the unexpected!) my vote is for a simple separate page that works 100% and doesn't need JS.

This interface will hardly be used anyway.

I like the idea of a separate page to choose re-order/hidden/advanced ... this page will also hopefully include custom fields as well!?!

Hi Jeff - definitely - that's what I need it for. I'm not sure how I will handle the custom field Header at the bottom of the page yet - I'm thinking either hiding the header if it detects no elements are underneath it or adding a "hide" option beside each element in the ordering screen (probably just the text elements in the initial version)

haven't had a chance to create a UI for this unfortunately, but here's a patch (for review) which adds a new function to the formslib to allow re-ordering and a couple of calls to the function from within the user edit pages.

use an Entry in config_plugins like this to display lastname and firstname before all other elements
Plugin Name Value
forms userprofileorder moodle,lastname,firstname

"moodle" is included as an element as it is the header element on the page.