Add first name and last name to signup and profile

[peregrineshahin]

not tested yet, needs adding the fields to the user collection (converting db), but still optional for those who prefer to be anonymous.

[peregrineshahin]

I wonder if this union is redundant, btw I didn't include any regex, only length limit, because from experience no matter how smart you would be about a regex for names, you will either allow everything or miss the most obscure legal name ever.

[vdbergh]

Yes it is redundant since “” is a string.

The union means that the object should either be equal to “” or else be of type string. This is equivalent to being of type string.

[vdbergh]

I wonder if this union is redundant, btw I didn't include any regex, only length limit, because from experience no matter how smart you would be about a regex for names, you will either allow everything or miss the most obscure legal name ever.

If you want to include a length limit (say 20) in the schema you can do it as

"firstname": intersect(str, size(0, 20))

The size(lb, ub) schema matches objects that satisfy lb <= len(object) <= ub.

[peregrineshahin]

Well the limit is more to avoid spam rather than an intrinsic property of the names.. but noted for the future.. I guess this schema is possible because of vtjson, thanks for the package!

[ppigazzini]

DEV updated.

[ppigazzini]

Jul 04 23:30:22 dfts-0 pserve[102834]: Traceback (most recent call last):
Jul 04 23:30:22 dfts-0 pserve[102834]:   File "/home/usr00/fishtest/server/env/lib/python3.12/site-packages/pyramid_mako/__init__.py", line 148, in __call__
Jul 04 23:30:22 dfts-0 pserve[102834]:     result = template.render_unicode(**system)
Jul 04 23:30:22 dfts-0 pserve[102834]:   File "/home/usr00/fishtest/server/env/lib/python3.12/site-packages/mako/template.py", line 443, in render_unicode
Jul 04 23:30:22 dfts-0 pserve[102834]:     return runtime._render(
Jul 04 23:30:22 dfts-0 pserve[102834]:   File "/home/usr00/fishtest/server/env/lib/python3.12/site-packages/mako/runtime.py", line 874, in _render
Jul 04 23:30:22 dfts-0 pserve[102834]:     _render_context(
Jul 04 23:30:22 dfts-0 pserve[102834]:   File "/home/usr00/fishtest/server/env/lib/python3.12/site-packages/mako/runtime.py", line 916, in _render_context
Jul 04 23:30:22 dfts-0 pserve[102834]:     _exec_template(inherit, lclcontext, args=args, kwargs=kwargs)
Jul 04 23:30:22 dfts-0 pserve[102834]:   File "/home/usr00/fishtest/server/env/lib/python3.12/site-packages/mako/runtime.py", line 943, in _exec_template
Jul 04 23:30:22 dfts-0 pserve[102834]:     callable_(context, *args, **kwargs)
Jul 04 23:30:22 dfts-0 pserve[102834]:   File "/home/usr00/fishtest/server/fishtest/templates/base.mak", line 561, in render_body
Jul 04 23:30:22 dfts-0 pserve[102834]:     <div>${self.body()}</div>
Jul 04 23:30:22 dfts-0 pserve[102834]:   File "/home/usr00/fishtest/server/fishtest/templates/user.mak", line 90, in render_body
Jul 04 23:30:22 dfts-0 pserve[102834]:     value="${user['firstname']}"
Jul 04 23:30:22 dfts-0 pserve[102834]: KeyError: 'firstname'

[peregrineshahin]

I think I mentioned above that we need to add such keys to every old user before this can be tested.. now while the current way of perfectly making the schema predictable in the mako rendering side, I agree that it might feel shaky that thereis one point of failure. But at the same time not using run.get("firstname","") can work as a fallback to catch errors since the tendering errors happen before shipping that to production.. so I'm not entirely sure if when using such a fullstack technology as we do, should convert all code base to accept wrong schema in the renderer.

[maximmasiutin]

Please consider using this version which I updated to fulfill this request: https://github.com/maximmasiutin/fishtest-contributors/blob/main/fishtest_contributors.py

You may copy this file to your own repository, be it a separate repository for this script that you may create, or just add it to an existing repository such as the main Stockfish repository, so that you would not need to maintain this file separately.

[MinetaS]

I prefer one single display name field to two first/last name fields because 1) middle name does exist and 2) some people in Indonesia have only one name afaik.

[Disservin]

I like the idea of a display name as well.