(WIP) Collab

[Kelketek]

This Pull request is the feature branch for comparison of Collab. Collab is an in-progress feature of Evennia that will allow public building. The default Evennia building commands assume builders are trusted. Collab assumes they are untrusted, and that anyone may build. Instructions for adding Collab to one's game are present in collab_settings.py.

Collab comes with its own permissions checking model that piggybacks on the existing locks and tags systems to create a concept of object ownership. Objects can have both a 'true owner', the player that created them, and a 'display owner'-- the character object that created them. This allows a layer of hiding between characters and players so that alts are not immediately revealed, a feature often important in games like these.

Collab provides a set of base collaborative typeclasses, as well as a 'collab mixin' that performs the meat of what these typeclasses do. The Collab typeclasses expose an interface of attribute handlers that are scoped to permission. For example, .usr is a version of 'db' that has a few indicative lock functions you can check against in the collab settings module. For an example of how this works, and what conventions should be presented to the user for setting attributes via these handlers, see the @set command.

Collab comes with its own implementation of the build commands. These are the meat of the PR at current, and a few are left to be implemented.

This PR MUST be highly tested. Several tests are already written, and tests need to be written for every feature. Full coverage, or as close as possible, must be maintained, as this feature is designed to take abuse.

Workflow notes: This PR is frequently rebased against master, and often commits are squashed. If anyone other than @Kelketek contributes a PR against this one, their commits may be reorganized in rebase slightly. At the moment, the current five commits keep getting squashed into by new code, but in order to give credit, outside commits won't be squashed into his existing commits (without permission).

This feature is a long work in progress, and notes are welcome on architecture, bugs, documentation, or anything that may help it mature and be ready for inclusion in the master branch.

[Griatch]

If wanting to stick to the layout used by the default cmdsets, then the docstring should look like this:

Create an object. 

Usage:
  @create object name;object alias 1;alias2

Eventual further details here.

[Griatch]

@Kelketek
So what is the progress on this, which aspects are left to do, apart from unittest suites?
.
Griatch

[Kelketek]

@Griatch Sorry it's taken me so long to answer here. A handful of building commands still need to be made and a few decisions on how to make scripts accessible need to also be made. There is also the open question of how to have some sort of functionality similar to 'parent rooms' on other servers. Parent rooms make their commands available to rooms that are contained within them. Presumably, there should be some elegant solution with commandsets that doesn't end up ruining the abstraction they give you.

[Griatch]

@Kelketek

As for "parent rooms", I'm not convinced this is something needed unless one wants to try to mimic a full prototype kind of inheritance. If desired, it shouldn't be too hard to have a typeclass use super() to get the same cmdsets added by its parent.

[Griatch]

@Kelketek

There has been no code activity on this PR for more than a year now. Do you expect to ever proceed with this? I propose we close this PR and pick it up again when you have time to continue with it, what do you say?

[Kelketek]

@Griatch I'm alright with that. It'll be a while yet. Business is going well but still bootstrapping. So long as I'm coding directly for work, coding won't be a displacement activity for me.