help > w > workspaces
WORKSPACE HALP WHO? Misery WHEN? November 2011 WHAT? 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. WHY? 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.) WHERE? 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 bug_d 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.) HOW? 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. NOTES: 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.