Missing some common fields in contact info model and form

Issue #1410 open
NM Realname
created an issue

In many countries middlename (patronymic) is necessary part of person's name. Maybe it should be added in core model and forms? Field adding is backward-compatible, isn't it? We even must not make this field visible by default.

And satchmo has good model for contact's phones. Maybe it's good idea to add secondary phone field to default contact info form. It must not be even visible by default too and it's very common thing.

Of course, all such things maybe done via custom models/forms/views/urls, but they are so common and simple and changes in core will even more cost-effective (tons of custom stuff to make simple things for just every project sucks).

I can provide patches for these things, if proposal will be approoved.

Comments (7)

  1. Hynek Cernoch

    Matimatik, remember also issue #1361 that requires supported reverse order "last_name first_name". Please can you do both good? Think about configuration and implementation of _get_full_name . Do you want two spaces between first and last name if middle name is empty? Good function and easy configuration are a little contradictory. Maybe add "combined_first_name" for web services that does not support middle name or you do not know how exactly they support it. (worldwide payment gateways)

    Is it very general in database systems in your country? I used adding middlename to firstname. In our country we use "First_name Last_name" but in an alphabetically sorted list of users (in admin) we prefer "Last_name First_name". Dare you?

    I am counting "first_name" 81x in python and 20x in templates. (Some are not relevant tests, old migrations, unique_id) Javascript in #1372 are also related.

  2. NM Realname reporter
    Matimatik, remember also issue #1361 that requires supported reverse order "last_name first_name". Please can you  do both good? Think about configuration and implementation of _get_full_name . Do you want two spaces between first  and last name if middle name is empty?
    

    I think it can be if'ed, like this:

    if middlename:
        return FORMAT_STRING.format(last=lastname, first=firstname, middle=" " + middlename)
    else:
        return FORMAT_STRING.format(last=lastname,  first=firstname, middle="")
    

    (or something like with % operation, if old python support is necessary). It wiil most flexible solution for all locales, i think.

    Is it very general in database systems in your country?
    

    Absolutely general. All IDs (internal passport, driver licenses), all other papers and most databases contains middlename.

    I used adding middlename to firstname.
    

    This is possible way, but it increases uneasiness for customers. If it is posible, it is very preferable to add additional field.

    In our country we use "First_name Last_name" but in an alphabetically sorted list of users (in admin) we prefer "Last_name First_name". Dare you?
    

    In Russia, "Last_name First_name Middle_name" is more usual. Maybe it can be done by implementing two methods like "get_full_name" and "get_full_name_reverse"?..

  3. Hynek Cernoch
    • changed status to open

    The name "get_full_name_reverse" is not exact for countries where only the reverse form is used (both will be the same), but it is probably the most clear name. Did you think about good clear practical settings? Two formats and one boolean for midlename? Where to place them, texts..

    Very hard will be to implement input forms templates with possible reversed order for east Asia and leave it well arranged. What you mean?

  4. NM Realname reporter

    Maybe something like "get_full_name_sort" (for alphabet sorting by lastname)…

    Yes, two formats and one boolean is probably good implementation. Names may be FULL_NAME_FORMAT for main representation in locale-specific order, FULL_NAME_REVERSE_FORMAT (or FULL_NAME_SORT_FORMAT) for representation for database (alphabetically sorted by lastname), and USE_MIDDLE_NAME.

    But even with USE_MIDDLE_NAME setting we should check if middlename is empty in get_full_name, otherwise (if middlename is used, but not reqired) we could get ugly double spacing.

    Probably should be another boolean LASTNAME_IS_ALWAYS_FIRST (or something like) for representing that reverse format is the default (it can set default FULL_NAME_FORMAT to default FULL_NAME_REVERSE_FORMAT or _get_full_name method can call _get_full_name_reverse if it is True).

    Input forms isn't a big deal, i mean. Because of their representation is implemented by templates we can just put

      {% if LAST_NAME_IS_ALWAYS_FIRST %}
        {# lastname field #}
        {# firstname field #}
        {% if USE_MIDDLE_NAME %}
            {# middlename field#}
        {% endif %}
      {% else %}
        {# firstname field #}
        {% if USE_MIDDLE_NAME %}
            {# middlename field #}
        {% endif %}
        {# lastname field #}
      {% endif %}
    

    in template code. This requires two settings variable, however.

  5. Hynek Cernoch

    I agree with averything before the input form example, but the input is what I was afraid that will be unclear. You wrote example for your country and you wrote "last middle first" but before you wrote

    In Russia, "Last_name First_name Middle_name" is more usual.

    Imagine complexity that your {# ***name field #} is usually code of two lines by 150 characters with <td>, label, translate field name, if createform.first_name.errors formating join errors an finally input field.

    Middle name is even so easy like field street2. I am sure that it will be completely supported ouf of box. Boolean can be added to livesettings - "Required billing data" where can be disabled firstname, lastname etc. Middle name is used more time than street, e.g. in registration form. It would be strange to modify registration form by billing address settings. It is not also clear.

    For the reverse order I can write a new template tag swapif, it is like "if", only it outputs both parts (but not now - the most important support is for things not modifiable by user):

      {% swapif LAST_NAME_IS_ALWAYS_FIRST %}
        {# firstname field #}
        {% if USE_MIDDLE_NAME %}
            {# middlename field #}
        {% endif %}
      {% elseswapif %}
        {# lastname field #}
      {% endswapif %}
    
  6. NM Realname reporter

    It was a mistake in that example, of course.

    Imagine complexity that your {# ***name field #} is usually code of two lines by 150 characters with <td>, label, translate field name, if createform.first_name.errors formating join errors an finally input field.
    

    Yes, i've hacked this templates for one of my projects (using twitter bootstrap layout) and complexity of this forms is clear in my mind. Btw, i think that style of generating forms may be very much optimized (if not some standard method like form.as_table, then with custom funtions/method -- for bootstrap layout, e.g. there is a django-bootstrap-forms and some other solutions), but this is a separate issue.

    It would be strange to modify registration form by billing address settings. It is not also clear.
    

    Yes, it is a small problem. And i think that lack of simple mechanism to hide some fields is a problem too. Maybe some "more declarative" form generator can enhance the situation.

    For the reverse order I can write a new template tag swapif
    

    Yes, it will be good temporary solution.

  7. Log in to comment