On 09/17/14, g00r00 said the following...
there is that, too... but should mystic allow for an address to be entered more than once to start with? ;)
Why not? If the Sysop thinks that they need to create 10 address
entries with the same address then whos to say they should be denied of their dreams?!?! ;)
:LOL:
i don't see a problem at all with areas being listed in more than
one
group if they are actually configured to be in more than one
group...
seems to me to be expected otherwise the area would be listed in
only
one group, right? ;)
It can get a bit messy this way. If someone has 450 bases, 10 are
local, 440 are networked and they are split across 3 networks. They have the following groups:
i've been thinking about this for several days now and the first thing that i see is the blurring of the line between tosser message groups and bbs message groups... they are not the same thing and they really shouldn't be... tosser message groups are for limiting access to other systems linked to the message areas... bbs message groups are for limiting access to individual users on the local system...
IIRC, the index reader is based on the functionality of golded which is an external to the bbs sysop reader... like most other external sysop readers, they generally use the tosser's message group definitions and don't know anything about the bbs' message group definitions...
i agree with your assessment about the problems of areas being in multiple groups but that's with them being in multiple bbs message groups... areas in the tosser are only ever in one tosser message group and i don't know of any tossers that allow an area to be in more than one group...
with that said, i would base the index reader on the tosser's message groups (not addresses!) kinda like you have now but i would separate the tosser's message groups from the bbs' message groups... additionally, linked systems can
be a member of several of the tosser's message groups so that they will have access to only those areas they are allowed... there may also be a need to have
read and write levels for linked systems as a system may be placed on read-only
status for a message area... basically the linked systems in the tosser are like the users in the bbs... each has similar options as far as groups they
can access and read/write premissions but that's as far as it goes...
consider that many operators just import or set up their areas with some sort of "backbone" areas file (eg: backbone.na)... those areas are all the ones carried on that distribution system but there's no distinction made in that list for (eg:) sysop only areas... in the tosser, this distinction is not needed because systems should be able to link to those areas... in the bbs, however, users may not be allowed to even read certain sysop only areas and in many cases, they aren't allowed to write in them...
we see the same thing when it comes to "backbone" distributed regional and zonal areas... folks in other regions or zones may not be allowed access to read and/or write in those areas... in this case, the tosser groups may be
used to split them from the general areas while both are pulled/fed to the
same upstream distribution system(s)... in the bbs, the groups may be similar or not but defining the segregation in the bbs on a user level is more detailed...
files areas are in the same prediciment, too... file tosser groups are not
the same as bbs files areas groups... there are zonal, regional and network level file areas as well as private ones that only certain systems can even know about... on the bbs level, users may or may not be allowed access...
individual area definitions would likely end up with a second group
definition field... the first being used as now with the security format (ACS) and the second being for the tosser group the areas belong in... so i guess
one might consider a secondary system based ACS but i don't know...
FWIW: every time my FE or ALLFIX add new areas to my main BBS system, i have
to go look them over and ensure that i get the permissions set properly for them for other systems' access as well as my bbs users' access... i gotta
find my flags fields definitions sheet again, too... that's how i was limiting access to some areas in my RA...
eg: security 25, no flags set - general user
security 25, A1 - visiting sysop
security 25, A2 - Z1 user
security 25, A1,A2 - visiting Z1 sysop
security 25, A1,A2,A3 - visiting Z1R18 sysop
security 25, A1,A2,A3,A4 - visiting Z1R18N3634 sysop
so to read a general sysop area, the user would have to have flag A1 turned on.
to read a Z1-Only area open to all Z1 folks, flag A2 has to be on. to read a Z1-Only Sysops-Only area flags A1 and A2 have to both be on. yeah, it can get pretty deep and demented awfully damned quick without a cheatsheet... security levels alone are not sufficient expecially when one has visiting sysops from other regions, zones and even networks... i used to try to use security levels for that but couldn't... the flags help and the combination is somewhat
easier but there can still be holes left...
RA has four sets of flags.... each with 8 bits... A1-A8, B1-B8, C1-C8 and D1-D8
and even they may not be enough in some cases but RA does also allow for a area
definition's access to require that a flag is off... i haven't even tried to start figuring out how to use the flags offered by mystic and systems like synchronet which seem to have only 26 flags with several of those being pre-dedicated to certain tasks or options (eg: QWK network account)...
anyway, sorry for the rambling in the FWIW section... the main parts of this message are before that and i hope i got them written decently enough to express the problem as i see it and a possible solution...
--- Mystic BBS v1.10 A52 (Windows)
* Origin: (46:1/132)