Player/Character creation via web [$35]

[Griatch]

Player creation via the web admin works but it is not feasible to create a full Player-Character pairing via the admin at this point. This issue concerns the full pipeline of creating Player and Character in the admin and then log in and play normally under any MULTISESSION_MODE.

• Player cannot get permissions. Permissions are Tags with the db_tagtype = "permission", and there is currently no way to create new Tags to go with the Player permission. One can select an existing tag (which has to be pre-created in-game at the moment), but the Tag display does not currently show the different tag types so one could accidentally pick a non-permission Tag here if it happens to be named the same as a permission level. resolved in TagAdmin tweaks #1115
• Attributes should be fully modifiable from the admin. resolved in TagAdmin tweaks #1115
• Aliases are Tags with db_tagtype="alias", there should be a way to set this (nicks are not needed though). resolved in TagAdmin tweaks #1115
• The superuser flag sits in the "web only" section. This is the only setting that does matter in-game in the same way as on the web, so it should probably be described somehow in that header (this is just a documentation issue). -Fixed in develop
• For MULTISESSION_MODE=0,1, one should be able to tie a Character to the Player by setting the Object's db_player foreignfield. In MULTISESSION_MODE=2, one might instead want to assign the character to the _playable_characters Attribute on the Player. A custom form is probably needed for this linking. -Added with button in develop
• Possibly there should be some sort of list of suggested Object cmdsets so one doesn't need to remember and write the path every time. This could be a help text or if possible some selector based on settings.CMDSET_*. Maybe one could consider some sort of clickable buttons that fill in some standard presets ...? Added with dynamic help entry in develop
• When setting a cmdset on a Character in the admin, the cmdset seems to be set to be visible outside the character. The result is that you get multi-command errors when executing commands in the same room as the new Character. Fixed a long time ago
• Tags-Permissions for Characters are needed in the same way as for Players. resolved in TagAdmin tweaks #1115
• There should probably be some help info or preset for how to set the puppet: lock to allow a Player to puppet a given Character, such as puppet:id(<player id>). Handled with button and info-text in develop
• There should probably be a way to connect a Player to a Character in the admin, for MULTISESSION_MODE=0,1 to not need to use @ic to connect. Fixed in develop.

---

There is a $35 open bounty on this issue. Add to the bounty at Bountysource.

[zero9k]

It would be really cool if Player account and Character can be created and logged in via web( not with django admin but the website for normal users). Looking forward to it!
For the character creation, the character attributes should be dynamic. I mean we could write an django app to handle all the attributes. Admins can add/del/edit attributes' key(name), cname(Chinese name .e.g. or for other non-english language), type( int, string, text, list, tuple, dict etc.), desc...(working on it now....)
Normal users can create/view/login player/character via web, when logged in, they can directly enter the game via web client without relogin.
=)

[Griatch]

It's probably time to start looking into just how much Django has improved since last this was attempted. Maybe it's possible to make something powerful enough to be generally useful. Otherwise one may have to consider making one's own admin interface fully under our control (maybe by using something like the external API suggested in #788).

[Griatch]

PR #1115 meant lots of progress towards this issue!

[Griatch]

This has been sitting for a good while, so marking as help wanted in case some django dev is interested in using this to learn Evennia.

[strikaco]

I've done all of the work of multisession_mode=2 account/chargen/management views via the web interface (not the admin though) and would happily submit my implementation via PR, but there are a lot of native inconsistencies between the methods for account creation via client, API and web interface (on the master branch, at least) that led to me making some changes with some of the core classes-- for example, I moved some repeated code blocks found within the create commands to a classmethod on the Account object itself, so the same set of procedures gets called on account creation regardless of whether it's done on the web or the client. (The API is untouched for those who want lower-level control.)

When I first started digging into this on the master branch, the same password validation code blocks were copied multiple times across the create command functions, ban handling was not comprehensively applied, CmdPassword does not enforce the same complexity requirements as are imposed at creation and the useful post-creation functionality that does things like add users to the default channels was locked up within Command objects not easily accessible from the web side of things, which led to reinvention of many wheels. It looks like the current build of the dev branch addresses some but not all of these issues.

Again, I'm happy to contribute and would decline the bounty, but given my ineptitude with git, before I go to the trouble of preparing a PR kindly let me know if my proposed solution would be too sweeping for addressing this issue.

[trhr]

@Griatch Is this about users (players) being able to create their own account and their own character, or is this for a server admin/developer to create isolated characters and associate them with a player account?

[Griatch]

@trhr It's about staff being able to use the django admin to create an account-character pair efficiently and easily in all multisession modes. Whereas there have been progress on many fronts (including adding better templates on the front- end, the admin needs write a lot of custom refactoring to make this intuitive.

[j3b4]

I'm not 100% this belongs here rather than a new issue. But I discovered the following today:
On a server running MULTISESSION_MODE = 0 I was able to use the web admin to delete my only character associated with the account (which had the same name as the account) but the account persisted and I stayed logged in. I was then able to use the web admin to create a new character with a non-matching name. Not the same name as the account. Back in the online client I was able to use 'ic newname' and connect to the new character. So now I had non-matching account and character name in a MULTISESSION = 0 environment. This might not be what a server admin would want players to be able to do on such a server.

[Griatch]

@j3b4 Belatedly, but there is nothing actually stopping you from puppeting another character if you have pupper: access to it. The MULTISESSION_MODE=0 only defines that you can only puppet one Object at a time, and from one client. If you played as superuser you'd be able to puppet anything, really.

[Griatch]

@strikaco This is now ready to close after the last batch of fixes. In light of your extensive additions to this over time, I'd be happy to see you claim the bounty. To do that I think you need to go to BountySource and 'claim' the bounty though. Not sure what happens if I just close the ticket now. 😅

[strikaco]

@Griatch Cool, thanks. I put in a claim...the economy is not what it was back in 2018 ;P

[Griatch]

Thanks! Closing now that the bounty is claimed. For backers that need to approve it, @strikaco should be getting the bounty of this one, for their contributions to it over a long time.