THE GREAT RENAMING! All that was "SIG" should now be "community," except for

the database and the URLs (for backward compatibility).  Do a full rebuild
after browsing this one!
This commit is contained in:
Eric J. Bowersox
2001-11-07 08:43:09 +00:00
parent fe352efbd1
commit dde12bdf2e
131 changed files with 2573 additions and 2503 deletions

View File

@@ -109,7 +109,7 @@
"high band" security level refers to someone who exercises administrative control over that scope
(and therefore all scopes greater than or "inside" it). Objects which are logically "enclosed" by
other objects have a higher scope value; for instance, a conference would have a higher scope value
than a SIG, which in turn would have a higher scope value than 0 (the "global" scope).<P>
than a community, which in turn would have a higher scope value than 0 (the "global" scope).<P>
The values 65000-65535 are not used, except that the value 65500 is defined as "no access" (something
not even the global system administrator can touch). Neither are the values 32000-32999, except that
the value 32500 is defined as "unrestricted user" (lying above the low bands of all scopes but below
@@ -122,34 +122,34 @@
<LI>64000 - Assistant administrator accounts ("PFY" level)</LI>
<LI>64999 - Global system administrator ("BOFH" level)</LI>
</UL><P>
SIGs use the scope level 3; the following values are defined within that scope:
Communities use the scope level 3; the following values are defined within that scope:
<UL>
<LI>6500 - SIG member</LI>
<LI>58000 - SIG co-host</LI>
<LI>58500 - SIG host</LI>
<LI>6500 - Community member</LI>
<LI>58000 - Community co-host</LI>
<LI>58500 - Community host</LI>
</UL><P>
Within SIGs, conferences use scope 6; the following values are defined within that scope:
Within communities, conferences use scope 6; the following values are defined within that scope:
<UL>
<LI>12500 - Conference member (for private conferences)</LI>
<LI>52500 - Conference host</LI>
</UL><P>
Each user has a "base access" level, within scope 0, that is stored in the "users" table. Each SIG
Each user has a "base access" level, within scope 0, that is stored in the "users" table. Each community
has four defined access levels associated with it:
<UL>
<LI><B>Read level</B> - minimum access level required to read the SIG's data. This is commonly 6500
(must be a member) but may be lower for special cases.</LI>
<LI><B>Write level</B> - minimum access level required to write the SIG's data. Since this refers to
the SIG itself, this is commonly 58000 (hosts/co-hosts only)</LI>
<LI><B>Create level</B> - minimum access level required to create new objects in the SIG. Typically
58000 (hosts/co-hosts only).</LI>
<LI><B>Delete level</B> - minimum access level required to delete the SIG. Typically 58500 (host
<LI><B>Read level</B> - minimum access level required to read the community's data. This is commonly
6500 (must be a member) but may be lower for special cases.</LI>
<LI><B>Write level</B> - minimum access level required to write the community's data. Since this
refers to the community itself, this is commonly 58000 (hosts/co-hosts only)</LI>
<LI><B>Create level</B> - minimum access level required to create new objects in the community.
Typically 58000 (hosts/co-hosts only).</LI>
<LI><B>Delete level</B> - minimum access level required to delete the community. Typically 58500 (host
only).</LI>
</UL><P>
The "sigmember" table maps UIDs to SIGIDs, adding a "granted level" field that specifies a given user's
access level within the SIG itself. (If a user already has a higher access level than the "granted"
access level, as in the case of the global sysadmin, the higher level takes precedence.) Note that
this level grant is within the context of <EM>that SIG only,</EM> and does not affect access privileges
to any other SIG.<P>
The "sigmember" table maps UIDs to community IDs, adding a "granted level" field that specifies a given
user's access level within the community itself. (If a user already has a higher access level than the
"granted" access level, as in the case of the global sysadmin, the higher level takes precedence.) Note
that this level grant is within the context of <EM>that community only,</EM> and does not affect access
privileges to any other community.<P>
Each conference has seven defined access levels associated with it:
<UL>
<LI><B>Read level</B> - minimum access level required to read the posts. Commonly 6500 (member of
@@ -165,15 +165,16 @@
<LI><B>Change level</B> - minimum access level required to change the conference's profile or
membership list. Commonly 52500 (conference hosts only).</LI>
<LI><B>Delete level</B> - minimum access level required to delete the conference. Commonly 58000
(hosts/cohosts of the enclosing SIG only).</LI>
(hosts/cohosts of the enclosing community only).</LI>
</UL><P>
As with SIGs, there is a "confmember" table that maps UIDs to CONFIDs, adding a "granted level" field
that grants additional access privileges. (There is also a field in the table that maps conferences
into SIGs that allows a SIG to grant its users additional privileges within a conference. Normally,
this field is 0, and so it "drops out" of the calculation of access levels.) Note that, if a user has
no membership entry for a conference, the entry for the conference's enclosing SIG takes precedence,
or the base level if there is no entry in any enclosing SIG. Also note that a grant of level for a
conference or SIG only applies with respect to <EM>that</EM> conference or SIG, not any other.<P>
As with communities, there is a "confmember" table that maps UIDs to CONFIDs, adding a "granted level"
field that grants additional access privileges. (There is also a field in the table that maps
conferences into communities that allows a community to grant its users additional privileges within a
conference. Normally, this field is 0, and so it "drops out" of the calculation of access levels.) Note
that, if a user has no membership entry for a conference, the entry for the conference's enclosing
community takes precedence, or the base level if there is no entry in any enclosing community. Also
note that a grant of level for a conference or community only applies with respect to <EM>that</EM>
conference or community, not any other.<P>
Additional scopes and levels will be defined for additional objects as they are added to Venice.<P>
</BODY>
</HTML>