Vote for Our Mud on TMC!

help > w > workspaces


November 2011

Workspaces provide wizards with a default private workspace with the
same functionality as bug_d, and with the ability to create new public
or private workspaces for specific projects. Each workspace also comes
with a bulletin board for project-related discussion.

Workspaces allow you to organize and collaborate on large projects
without the difficulties that come through using the bug_d for these
purposes (these being primarily polluting the bug_d with a number of
reports only you or a small number of people need access to, and the
difficulty of tracking down these reports in a busy bug bin.)

There's a new command, 'workspace', which enables the creation and
modification of existing workspaces. I suggest you use the '@' global
alias for this command, however, as the syntax is simpler. Type
'@ help' to get a syntax list.

You can use '@' to see any open public workspaces. and '@ private' to
see any private workspace you may have access to (either by level, or
because you have been invited to it). You can also can also use the
'@ deleted', '@ mothballed' and '@ completed' options to view closed
workspaces of the varying types. Using '@<workspace>' will give you
more information on a given (open) workspace. I'll break down the other
options in the '@ help' syntax list here:

		complete - marks the project as completed and removes it from
		           the list of open workspaces

        create - creates a new workspace

        delete - delete an existing workspace (non-permanent)

      describe - add a description about the workspace's purpose

          link - indicate a "parent" report in bug_d, which suggests
                 the workspace exists to resolve that report

        secure - makes the workspace private, keeping wizards under
                 the set level from seeing it

      undelete - restores a deleted workspace

      unsecure - removes security from a workspace

        unlink - removes the "parent" report from a workspace

       include - adds a reference to a report in the main bug_d; it
                 will now appear in the report list for this project,
                 and any commands pointed at that bug in your workspace
                 will modify the bug_d copy

        import - re-creates a local copy of the bug indicated. Commands
                 pointed at the copy will not change the original in

     uninclude - deletes a reference to a report in bug_d

        invite - add a wizard to your workspace (may use keyword "all"
                 to allow any wizard to modify your space).

      uninvite - remove a wizard from your workspace (note, this is
                 not a block list; if you add "all" you can't then
                 uninvite a single wizard.)
You can work with an established workspace by starting with the @tag,
for example, '@misery' for my personal workspace, followed by any of
the commands supported by the bugs system. So '@misery bugs' lists
the bugs in my personal workspace; '@misery bugs deleted' lists
deleted bugs and so on. You can also use '@me' as a shortcut to your
personal workspace.

I could add a new todo item to my workspace with '@me todo finish
documenting workspaces already, you bum!' which will create a new
report with number #1 (if it's the first in my space.) If I use
'@me include #' a new report will appear with the number and
qualities it has in bug_d. If I used import, however, it would come
in with the next incremental bug id. To make this more clear:
  - '@me import 9500' would create a local copy; if I commented on
    this copy, my comments would stay in my local workspace.
  - '@me include 9500' would just create a pointer to the bug_d
    copy, and if I commented on it, the comment would be applied
    to the bug_d copy.

1.) It's useful for me to explain some terms in regard to security.
    The workspaces perform a variety of security checks. A "public"
    (unsecured) workspace may be viewed by all wizards, but it may
    only be modified by wizards explicitly added to the participant
    list, or above a given level (currently 2k and up).
    A private workspace may be listed if you are above the privacy
    level, but follows the same rules in regard to modification.
    Personal (wizard) workspaces are a good example of this in action.
    if you type 'workspace list private' you'll only see workspaces
    for wizards of lower rank than yourself. You can't set a privacy
    level above your own.
2.) The workspace stores local bugs in the same format as bug_d,
    and you interact with them the same way. You can delete them
    like you would a normal bug. The workspace stores "global" bugs
    as a reference to the report in bug_d and keeps no local info
    beyond the reference. You may simply 'uninclude' these bugs and
    they will no longer appear in the workspace's bug list.

FUTURE PLANS (feel free to offer help :):
1.) I'd like to provide some file-management functionality that allows
    for some automagical implementation of a project. If a project was
    an area, for example, I'd like to provide a workspace command for
    moving the area live that a wizard of sufficient level could use.
2.) I'd like to upgrade the file-management functionality down the
    road so it can also do some more complicated file operations
    to modify existing files. BugHelper is an example of how this
    might work, though it's only set up to work on a single file at a
    time, and doesn't work all that well for modifying multiple files.