zii/MRCI
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
8a06b5a186
MRCI/docs/intern_commands/set_member_level.md
Maurice ONeal 72d57a0b10 Major upgrade and module interface changes 
Made some major changes to the project to facilitate a lighter code base and the
must flexible module interface possible.

-the mutli-process architecture now operate at the command object level so each
 command now operate in it's own process instead of a single process handling
 multiple command objects.

-each module is now an independent application that will now tell the session
 object all of the commands it can run via named pipe. during command execution,
 it will run the requested command object also running io with the session object
 via named pipe.

 with this change, it is now possible for modules to be developed in different
 versions or QT or entirely different languages. the only requirement is the need
 to support named pipes. shared memory segments is also a nice to have but not
 needed.

-clients can now run multiple instances of the same command via changes to the
 protocol. mrci frames will now include a branch id along with the command id.
 the branch id can be used by clients to differentiate the io between instances
 of the same command.

-the command states are longer controlled by a single object. it will now be up
 to the command object (internal/exterenal) to send an IDLE frame to the client
 to notify it that the command has finished. the session object will still track
 if the command is in idle state or not but not directly control it.

-must async commands now use binary formatted data instead of TEXT as a way to
 reduce overhead.

-all command objects can now send async commands. it is no longer limited to just
 internal commands, however; the data of these async commands are verified by
 session in some way to prevent host crashing due to malformed data.

-changed up the database structure to rely more on user ids, channel ids and
 removed all foreign keys pointing to user names, channel names and sub-channel
 names. also removed the groups table altogether. instead, the host rank is now
 directly attached to the user data in the users table.

-changed the query object to now support the INNER JOIN SQL clause. this change
 was needed to support the new database structure.

-version negotiation is now one-way via tcp connection or module interface.
 the host will make it's own verion numner known to the client connected via
 tcp or the module connected via named pipe. it will now be entirely up to the
 client or module to decide if they support the host. another change in this
 regard is the removal of the import rev for the modules. compatibility for
 modules shall now use just the host verion.

-removed ls_cmds and cmd_info. the NEW_CMD frame now carries all information
 about the command (cmd_id, cmd_name, summery, io and full_description) so it
 is now possible for the clients to display the command documentation instead
 of the host.

Documentation for the internal commands were updated to reflect the changes but
all other documentation will need to be updated in the near future.
2019-11-08 22:06:09 -05:00

2.1 KiB
Raw Blame History

Summary

set the user privilege levels of a channel member.

IO

[-ch_name (text) -user (text) -level (int)]/[text]

Description

set the privilege level of the channel member given in -user for the channel given in -ch_name to the level given in -level. a valid privilege level is an integer between 1-4 representing owner-level(1), admin-level(2), officer-level(3) and regular-level(4). the channel owner-level(1) is reserved for just 1 member in the channel and only that member can assign another member in the channel that privilege level. when the owner privilege is assigned to another member, the current owner will step down to a admin. this command is restricted based on your current level so you cannot assign a level higher that you own. below is a description of what each of these levels can do within the channel:

owner-level(1):

  1. delete or rename the channel.
  2. delete, create or rename sub-channels within the channel.
  3. invite new users to the channel or cancel invites.
  4. remove any member of the channel except your self.
  5. set sub-channels' level of access.
  6. add/remove read only flags to/from sub-channels.
  7. update the privilege level of any member in the channel.
  8. open/close sub-channels for casting.

admin-level(2):

  1. delete, create or rename sub-channels within the channel.
  2. invite new users to the channel or cancel invites.
  3. remove any member of channel except the owner and other admins.
  4. set sub-channels' level of access.
  5. add/remove read only flags to/from sub-channels.
  6. update the privilege level of members up to your own level but not above.
  7. open/close sub-channels for casting.

officer-level(3):

  1. invite new users to the channel or cancel invites.
  2. can only remove regular members of the channel.
  3. update the privilege level of members up to your own level but not above.
  4. open/close sub-channels for casting.

regular-level(4):

  1. open/close sub-channels for casting.

note: this command causes all sessions that are loggined in as this user to close all related sub-channels. it will be up to the client to re-open the sub-channels if the user still have access to them.