MSColab - A Flight Path Collaboration Platform

Mscolab has been developed to make MSS workable in a collaborative environment, with additional features such as chat-messages, keeping track of the made changes, permissions of the collaborators.

Configuring Your MSColab Server

The mscolab server comes with a default configuration, built on top of sqlite3. One can override these settings by making a copy of the following file in a location in $PYTHONPATH.

Description of the variables can be found in comments.

mscolab_settings.py

# -*- coding: utf-8 -*-
"""

    mslib.mscolab.conf.py.example
    ~~~~~~~~~~~~~~~~~~~~

    config for mscolab.

    This file is part of mss.

    :copyright: Copyright 2019 Shivashis Padhi
    :copyright: Copyright 2019-2022 by the mss team, see AUTHORS.
    :license: APACHE-2.0, see LICENSE for details.

    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
    You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.
"""
import os
import logging

class mscolab_settings:
    # Set which origins are allowed to communicate with your server
    CORS_ORIGINS = ["*"]

    # Set base directory where you want to save Mscolab data
    BASE_DIR = os.path.abspath(os.path.dirname(__file__))

    # Directory in which all data related to Mscolab is stored
    DATA_DIR = os.path.join(BASE_DIR, "colabdata")

    # Where mscolab project files are stored on the server
    MSCOLAB_DATA_DIR = os.path.join(DATA_DIR, 'filedata')

    # Directory where uploaded images and documents in the chat are stored
    UPLOAD_FOLDER = os.path.join(DATA_DIR, 'uploads')

    # Max image/document upload size in mscolab chat (default 2MB)
    MAX_UPLOAD_SIZE = 2 * 1024 * 1024

    # Set your secret key for token generation
    SECRET_KEY = 'MySecretKey'

    # Set the database connection string:
    # Examples for different DBMS:
    # MySQL: "mysql+pymysql://<username>:<password>@<host>/<db_name>?charset=utf8mb4"
    # PostgreSQL: "postgresql://<username>:<password>@<host>/<db_name>"
    # SQLite: "sqlite:///<path_to_db>"
    SQLALCHEMY_DB_URI = 'sqlite:///' + os.path.join(DATA_DIR, 'mscolab.db')

    enable_basic_http_authentication = False

    # text to be written in new mscolab based ftml files.
    STUB_CODE = """<?xml version="1.0" encoding="utf-8"?>
    <FlightTrack version="1.7.6">
      <ListOfWaypoints>
        <Waypoint flightlevel="250" lat="67.821" location="Kiruna" lon="20.336">
          <Comments></Comments>
        </Waypoint>
        <Waypoint flightlevel="250" lat="78.928" location="Ny-Alesund" lon="11.986">
          <Comments></Comments>
        </Waypoint>
      </ListOfWaypoints>
    </FlightTrack>
    """

Protecting Login

The login to the MSColab server can be protected by an additional auth method.

class mscolab_auth(object):
     password = "please use the methods to save only the encrypted value"
     allowed_users = [("user", hashlib.md5(password.encode('utf-8')).hexdigest())]

Make a copy of the above file, rename it to mscolab_auth.py, make the necessary changes in the file and add it to your $PYTHONPATH.

Steps to Run MSColab Server

  • The MSColab server comes included in the MSS python package.

  • Once MSS is installed, if you’re running the mscolab server for the first time, run the command mscolab db --init to initialise your database.

  • To start the server run mscolab start.

  • If you ever want to reset or add dummy data to your database you can use the commands mscolab db --reset and mscolab db --seed respectively.

Steps to Open the MSColab Application Window

To open the mscolab window in the application select the Operation option from the menu bar of Mission Support System’s main window.

User based features

  • A user can register and login.

  • A user can also delete his/her account.

Operation based features

  • In MSColab, each flight track is referred to as an operation.

  • An operation can be created by a user, once he/she has logged in.

  • The users can either select a starting FTML file while creating the operation or can later import a FTML file to the operation.

  • All the operations the user has created or has been added to can be found in Mscolab’s main window along with the user’s access level.

  • To start working on an operation the user needs to select it which enables all the operation related buttons.

  • Any change made to an operation by a user will be shared with everyone in real-time unless Work Locally is turned on.(More on this later)

Operation Permissions

There are 4 different access levels of user:

  • Creator

    Creator is the user who creates the operation, they have all the rights which ‘admins’ have. Additionally, they can delete the operation, make administrators and revoke administrators’ status.

  • Admins

    Admins can add users to the operation and can update their access levels. They can also view the version history of the operation and revert to a previous version if need arises. They have all the capabilities of a collaborator.

  • Collaborators

    Collaborators can make changes to the operation and have access to the chat room. Additionally, they can view the version history of the operation.

  • Viewer

    Viewers can only view the flight track and have the least amount of access.

All the changes to users’ permission are in real-time.

Adding Users To Your Operation

To add users to a operation, you need to be the admin or creator of that operation. Select the desired operation and click on the Manage Users button in Mscolab’s main window. An admin window will open where you can manage the permission of all the users in bulk by selecting multiple users at once and add, updating or deleting their access to the operation. If you have another operation and want to have the same users as on that operation you can use the Clone Permissions option in the admin window to quickly add all the users of a operation to your selected one.

Chatting With Operation Members

If a user has the permission of collaborator or above, they can use the chat window in Mscolab. You can send normal text messages or use markdown to format them. The currently supported markdown syntax is:

  • # : Headings

  • **text** : Bold text

  • *text* : Italicise Text

  • [text](link) : Add hyper-link to text

You can use the Preview button to see how your text is formatted before sending it.

There is also support for image/document upload. You can set the upload size limit in the mscolab_settings.py file. The default limit is 2 MBs.

Right-clicking on a message would open a context-menu giving you options to copy, edit, delete or reply to a message.

Managing Operation Versions

If you have the access level of collaborator or higher to a operation you can view all the change history of the operation by clicking on the Version History button in Mscolab’s main window. A new version history window will be opened where you can view all the changes made to the operation and compare them with the current flight track by selecting a previous version. You can also set names to important versions to keep track of all the important milestones.

Working Locally on an Operation

If you want to try out your changes on a operation without disturbing the common shared file. You can use the Work Locally toggle in the Mscolab main window. You can turn that toggle on at any time which would send you into local work mode. In this mode you will have a copy of the operation on your system and all your changes will be made to this file. Once you’re done with all your local work and think you’re ready to push your changes to everyone, you can use the Save to Server button. This would prompt you with a dialog where you can compare your local flight track and the common flight track on the server and select what you would like to keep. You can also fetch the common flight track to your local file at any time using the Fetch from Server button which prompts you with a similar dialog. You can turn the Work Locally toggle off at any points and work on the common shared file on the server. All your local changes are saved and you can return to them at any point by toggling the checkbox back on.

Notes for server administrators

If you’re configuring mscolab server, there is a manage users GUI to add or manage users to a operation. There is a command line tool available with the installation of mss, mscolab. It can import users to the database and can handle joins to operations.

Make a text file with the following format to import many users to the mscolab database

suggested_username name <email>
suggested_username2 name2 <email2>
$ mscolab db --users_by_file /path/to/file

After executed you get informations to exchange with users.

Are you sure you want to add users to the database? (y/[n]):
y
Userdata: email suggested_username 30736d0350c9b886

"MSCOLAB_mailid": "email",
"MSCOLAB_password": "30736d0350c9b886",


Userdata: email2 suggested_username2 342434de34904303

"MSCOLAB_mailid": "email2",
"MSCOLAB_password": "342434de34904303",

Further options can be listed by mscolab db -h

user verification by email

With setting of USER_VERIFICATION = True you have to set further options in the mscolab_settings.py. These are parameters of flask-mail

# enable verification by Mail
USER_VERIFICATION = True

# mail settings
MAIL_SERVER = 'localhost'
MAIL_PORT = 25
MAIL_USE_TLS = False
MAIL_USE_SSL = True

mail authentication
MAIL_USERNAME = os.environ.get('APP_MAIL_USERNAME')
MAIL_PASSWORD = os.environ.get('APP_MAIL_PASSWORD')

# mail accounts
MAIL_DEFAULT_SENDER = 'MSS@localhost'

A new user gets an email with an url including a token to become verified on the mscolab server. After the verification she can login.

Instructions to use mscolab wsgi

make a file called server.py and install

mamba install eventlet>0.30.2 gunicorn

server.py:

from mslib.mscolab.server import _app as app

Then run the following commands.

$ mamba install gunicorn eventlet>0.30.2
$ gunicorn -b 0.0.0.0:8087 server:app

For further options read https://flask.palletsoperations.com/en/1.1.x/deploying/wsgi-standalone/#gunicorn

If you want to use nginx to proxy this gunicorn server have a look on the example mss_proxy.conf.

Tip

update gunicorn

You may need to build gunicorn on your own until the new release > 20.1.0: https://github.com/benoitc/gunicorn/pull/2581#issuecomment-1154008037

Data Base Migration

We did changed the database scheme for 6.0. This is described by the flask-migrate script

def upgrade():
    # ### commands auto generated by Alembic - please adjust! ###
    op.create_table('operations',
    sa.Column('id', sa.Integer(), autoincrement=True, nullable=False),
    sa.Column('path', sa.String(length=255), nullable=True),
    sa.Column('category', sa.String(length=255), nullable=True),
    sa.Column('description', sa.String(length=255), nullable=True),
    sa.PrimaryKeyConstraint('id'),
    sa.UniqueConstraint('path')
    )
    op.drop_table('projects')
    with op.batch_alter_table('changes', schema=None) as batch_op:
        batch_op.add_column(sa.Column('op_id', sa.Integer(), nullable=True))
        batch_op.drop_constraint(None, type_='foreignkey')
        batch_op.create_foreign_key(None, 'operations', ['op_id'], ['id'])
        batch_op.drop_column('p_id')

    with op.batch_alter_table('messages', schema=None) as batch_op:
        batch_op.add_column(sa.Column('op_id', sa.Integer(), nullable=True))
        batch_op.drop_constraint(None, type_='foreignkey')
        batch_op.create_foreign_key(None, 'operations', ['op_id'], ['id'])
        batch_op.drop_column('p_id')

    with op.batch_alter_table('permissions', schema=None) as batch_op:
        batch_op.add_column(sa.Column('op_id', sa.Integer(), nullable=True))
        batch_op.drop_constraint(None, type_='foreignkey')
        batch_op.create_foreign_key(None, 'operations', ['op_id'], ['id'])
        batch_op.drop_column('p_id')

    with op.batch_alter_table('users', schema=None) as batch_op:
        batch_op.add_column(sa.Column('registered_on', sa.DateTime(), nullable=False))
        batch_op.add_column(sa.Column('confirmed', sa.Boolean(), nullable=False))
        batch_op.add_column(sa.Column('confirmed_on', sa.DateTime(), nullable=True))

Because of the renaming of foreign_key this script can’t be used for the update on sqlite and also not on psql. We suggest to dump (pg_dump -d mscolab -f outpu.sql) the database and to change manually. Then drop the existing database and recreate it. The following example snippets were tested on psql.

The tables have to be changed to

--
-- Name: operations; Type: TABLE; Schema: public; Owner: mscolab
--

CREATE TABLE public.operations (
    id integer NOT NULL,
    path character varying(255),
    category character varying(255),
    description character varying(255)
);

--
-- Name: users; Type: TABLE; Schema: public; Owner: mscolab
--

CREATE TABLE public.users (
    id integer NOT NULL,
    username character varying(255),
    emailid character varying(255),
    password character varying(255),
    registered_on timestamp without time zone NOT NULL,
    confirmed boolean NOT NULL,
    confirmed_on timestamp without time zone
);

The changed entries look like (seperator is a TAB Key)

COPY public.operations (id, path, category, description) FROM stdin;
1     FL1     default Plan to ....


COPY public.users (id, username, emailid, password, registered_on, confirmed, confirmed_on) FROM stdin;
1     John    john@gmail.com  $6$rounds=656000$itj3iej034i3ß5Qn..lu345RWER32424Vv/D1  2021-10-04 12:12:29.086493      f       \N

For trying an updated version we suggest to use the command psql -v ON_ERROR_STOP=1 < new_db.sql