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.