TOMUSS Technical Reference

Table of content:

TOMUSS file organisation

The first part describes the hierarchy created by the default installation script and the second part describes the hierarchy of the running servers.

You may skip the first part is you only want to test TOMUSS

The over top file organisation

The hierarchy created by the installation tree insure that a running server can be stopped and an older version of the server can be quickly started without data loss.

The installation script needs 2 directories, one for the server and one for the backup server. They store exactly the same things (except temporary and log files). The database stay synchronized in the two directories.

• SERVEUR_NOTES The last server version.
• LOGS The log files.
• TMP The temporary files.
• Trash The deleted tables.
• TOMUSS_DB The tables.
• TOMUSS.YYYY-MM-DD_HH:MM:SS Older versions of the server

Running server file organisation

If the installation script is used, the following directories are symbolic links to the version independant directories.

• DBtest (DB in production): Where the data are stored.
• LOGS: The logs and statistics of the servers
• TMP: Data files generated by program, but costly to create.
• Trash: Where are moved the deleted tables

The top level directories

• DBtest (DB in production): Where the data are stored.
  BACKUP_DBtest (BACKUP_DB in production): Where the backup is stored.
  • One directory per year named Y9999
  • One directory named Y0 for year independent data.
  • CLOSED/???/---UE CODE--- stores the semester for which the UE seems to be close
  • RSSLOGINS/???/---RSS_KEY--- contains the login associated to the key.
  • LOGINS/???/login: Directory with user data.
    • favstu Favorite student list
    • master_of The user is the master of theses UEs
    • pages Favorites UE
    • charte_9999_semester Exists if the charte was accepted
    • rsskey Key used to read RSS stream without login
    • old_referent The last referent of the student
• FILES: The static files sended by the server. They are automaticaly reloaded when they are modified.
• SCRIPTS: Some scripts mostly local and obsolete except 'install' and 'crontab_run.py'
• TEMPLATES: Defines classes of table.
• REGTEST_CLIENT: An aborted experiment to do regressions tests on any web browser (the browsers do not react deterministicaly).
• REGTEST_SERVER: A working set of regression tests on the server.
• DOCUMENTATION: You are seeing it :-)
  • Makefile The default goal create documentation.
  • ChangeLog All the modifications done.
  • TODO The things that need to be done
  • Welcome.orig.xml The documentation source.
• PLUGINS: They define how the servers react to an URL
• COLUMN_TYPES: They define define the possible column types.
• ATTRIBUTES: They define the possible column and table attributes.
• LOCAL: All the customization code and data must be inside.
  • __init__.py: Your real configuration
  • LOCAL.TEMPLATES: Your local TEMPLATES directory

The core of the code

• Makefile: The goals are
  • start: Starts all the servers.
  • stop: Stops all the servers.
  • stopsuivi: Stops TOMUSS 'suivi' server.
  • stoptomuss: Stops TOMUSS server.
  • install: Put development version in production.
  • stat: Display some sources stats
  • clean: Delete garbages.
  • diff: Difference between development and production source version.
  • regtest: Run server regression tests.
  • regtest1: Run server regression tests only once
  • release : Package a release.
• configuration.py: configurations variables. Read carefully, but do not modify this file.
• tomuss.py: Server managing the tables. Possible parameters are:
  • regtest: server in regtest mode, ticket are in the form '=invited.teacher' or '=super.user'
  • xxx_toutes_les_ues: Extract the UE list from database and store them in a Python module. Then the process stops.
  • all_ues.js: Translate the UE list in a JavaScript module. Then the process stops.
• suivi.py: Server allowing the 'suivi'.
• abj.py: All the code needed to manage ABJ, DA, TT.
• authentication.py: The authentication core.
• cell.py: The Cell object
• column.py: The Column, Columns objects
• data.py: Contains the functions used by data files
• document.py: Define the Table and manages the tables.
• files.py: Manage the static files. If a file is modified, it is automaticaly updated in the server (but they may stay in client cache one hour)
• inscrits.py: LDAP connector to retrieve students lists
• plugin.py: Plugin management and URL parsing.
• plugins.py: Load plugins used by the servers.
• referent.py: Manage the 'referent' table.
• tablestat.py: Utility to compute statistics on tables. It manages the list of table used to do the 'suivi'
• teacher.py: Interface to UE (courses) informations.
• ticket.py: Ticket management.
• regtestpatch.py: Loaded if TOMUSS is in regression test mode. It patches the module in order to have no random in server answer.
• objgraph.py: GPL utility to navigate in object graph.
• servers.py: Define the class describing a 'suivi' server.
• utilities.py: Many utilities low level.

TOMUSS plugins

When a TOMUSS process is started it loads its plugins. The received requests are dispatched to the fittest plugin. The most important attributes of a plugin are.

Do not modify plugins.py source to add plugins, use a redefine to add plugins

Do modify global state with plugins because it may cause problems if the plugin is reloaded while the server is running.

URL template

It defines the pattern of the request. For example: {Y}/{S}/{U}/resume

Here are the components of the URLs and where they are stored in the request objet in the server side.

Plugin attributes

The possible values of the decision attributes are None to indicate that it is not important, True to indicate that session must match the attribute, False to indicate that session must not match the attribute.

• Authenticated: The client authenticated itself
• Teacher: The user is a teacher
• Administrative: The user is an administrative as a secretary.
• Referent Master: The user manage the referent teachers
• Root: The user is a super user
• Password OK: The user has a not stupid password

The action attributes are:

• Background: a subprocess must be launched.
• Keep Open: the client socket should not be closed.
• Cached: the answer must not be cached by client/proxies.
• Link: defines if and how the link to the plugin is diplayed on the home page. It is an object with many attributes : text, url, help text, safety, where it is display, authorization test...
• Mime type and Response: Defines the HTTP header answer.

Plugin documentation

Some of the plugins are used both in TOMUSS and 'suivi' servers.

The ``link and position´´ defines the function generating the HTML content to insert in an home page. The position specify the name of the box where to insert the code.

TOMUSS protocols

The client perform action on the server by inserting image objects in the HTML code. The returned image give the user feedback (green: ok, orange: waiting server, red: unauthorized, violet: bug...)

The client does not poll server to retrieve changes, but the server send javascript fragment when there is an update to send.

TOMUSS client/server protocol

The client load the documents as usual. But if the document is a table:

• The socket is not closed, so the client will receive live table update as javascript commands.
• an unique page identifier is created, all the modification and identifiers will be associated with this unique identifier so there is no possible naming conflict.
• a request identifier is initied. It will be used to sort the requests by time.
• Subsequent requests from the client to modifiy the table are images load, the image URL contains all the transaction information and the returned image itself is the feedback.

TOMUSS suivi client/server protocol

TOMUSS storage

The table data is stored as a Python module, the module source is only modified by doing an append to prevent any data loss. File size is checked before and after append to insure that the data was really saved.

All the TOMUSS data are stored in two files, so two identical hierarchies are managed.

Table storage

The columns and lines are identified by a key usualy created as: page_id + '_' + number. With this scheme, two identical keys are not possible.

The functions to modify the table are:

table_attr(attr, page_id, value, page): None

column_attr(attr, page_id, col_id, value, col, page): None

column_empty_is(page_id, col, empty_is): Change the column empty_is value.

comment_change(page_id, col, lin, value): Change the comment on a cell.

column_change(page_id, col, title, ttype, test, weight, freezed, hidden, width): Change some attributes of the column.

end(): Stop the importation of a table (release lock)

column_comment(page_id, col, comment): Change the column comment.

table_comment(page_id, comment): Change the table comment.

column_visibility_date(page_id, col, date): Specify the date of visibility

begin(table): Start the importation of a table (set lock)

new_page(ticket, user_name, user_ip, user_browser, date): Create a new page in the table, the identifier of page (page_id) is an integer starting from 0.

private_toggle(page_id): Change the privacy state of the table.

default_nr_columns(nr): Specify the default number of columns displayed on screen.

add_master(name, page_id): Add or remove a master on the page.

date_change(page_id, dates): Change the table dates.

column_delete(page_id, col): Delete the column if it is empty.

column_position(page_id, col, position): Define the column position (the columns are sorted by position.

cell_change(page_id, col, lin, value, date): Change the value of a cell.

ABJ + DA storage

As table data, informations about ABJ and DA are stored in a Python module. The parameters are:

• 'login' The student identifier
• 'from', 'to' Start and end date of the justification (DD/MM/YYYY[MA]) M=Morning A=Afternoon
• 'date' (DD/MM/YYYY) Start of the dispense of assiduity.
• 'user_name', 'action_date' The user that modified the information and when.

The functions to modify the data are:

add   (login, from, to  , user_name, action_date)
rem   (login, from, to  , user_name, action_date)
add_da(login, ue  , date, user_name, action_date)
rem_da(login, ue        , user_name, action_date)

TT storage

The information about 'Tiers Temps' are stored in a normal table, the columns order must not be modified. There is a line per student.

Referent storage

The information about referents teacher are stored in a normal table named 'orientation_rp'. Each line contains the teacher login, its portals.

The list of students per referent is stored in 'referents_students' table

TOMUSS objects server side

Cell

Define a cell with the given attributes. It also manage the cell history and a cache to minimize CPU time to generate the minimal JavaScript code for the cell. Attributes of the cell should not be modified directly.

• '__init__': Create a new cell with some attributes in the list: 'value', 'author', 'date' and 'comment'. The date is formatted as YYYYMMDDHHMMSS.
• 'copy'
• 'js': Generate the Cell JavaScript object with the minimal code, in order to minimize file size.
• 'js_student'
• 'set_comment': change the comment on the cell.
• 'set_value': change the value of the cell.

CellEmpty

Define an empty cell. It is only to use less memory than a Cell

• 'copy'
• 'empty': Returns True
• 'js': Create the javascript code for an empty cell.
• 'js_student': Create the javascript code for an empty cell.
• 'set_comment': Create a non empty cell with the comment and returns it.
• 'set_value': Create a non empty cell with the value and returns it.

CellValue

Define a cell without history nor comment It is the most used cell content

• '__init__'
• 'copy'
• 'empty': Returns True if the cell is empty
• 'js': Generate the Cell JavaScript object with the minimal code, in order to minimize file size.
• 'js_student': Generate the Cell JavaScript object with the minimal code, in order to minimize file size.
• 'set_comment': change the comment on the cell.
• 'set_value'

CellVirtual

The set_ methods in cells returns a new object if needed. It is because an CellEmpty can become a Cell.

Column

The Column object contains all the informations about the column. Once the Column is integrated in a table, it memorizes the table pointer.

• '__init__': Create the column with the same defaults than in the column object in the javascript side.
• 'cell': Format a cell value in order to display it. It uses the formatter defined by the column type.
• 'cell_indicator': Compute if the cell value is a good or bad one. Returns the HTML class name associated and a value between 0 and 1
• 'cell_values': Compute the list of cells FLOAT values with the given Grp and Seq
• 'copy_on_browser': Returns True if the column is needed to compute a visible result
• 'depends_on': Return the list of columns used to compute this one
• 'dump': 'print' all the column information for debugging
• 'empty': Returns True if all the cells in the column are empty.
• 'is_modifiable'
• 'js': Returns the JavaScript describing the column.
• 'min_max': From the Note 'test' value stored as [min;red;green;max] returns the min and the max as float numbers.
• 'nr_cells_not_empty_and_empty': Compute the total number of cells and the number of empty cell in the column.
• 'visible': Returns true if the column is visible for the student

Columns

A set of Column associated to a table. The columns are stored in a list, so they have an index. They also have an unique 'id' used to communicate with the client because the columns are not in the same order in all the clients.

• '__getitem__': Get the column at the given index.
• '__init__': Create an empty set associated to the table.
• '__iter__': Iterate over the columns.
• '__len__': Returns the number of columns.
• '__setitem__': Set the column at the given index and update some information in order to have faster access.
• 'append': Add a new column.
• 'data_col_from_title': Retrieve the column from its 'title'.
• 'from_id': Retrieve the column from its 'id'.
• 'from_title': Retrieve the column from its 'title'.
• 'get_grp': Get the data_col of the column named 'Grp'
• 'get_seq': Get the data_col of the column named 'Seq'
• 'js': Returns the javaScript code describing all NEEDED columns.
• 'pop': Remove the column at the given index.
• 'use': Columns using this one.

Line

The Line object is usable as a Python list.

• '__getitem__': Take a Cell in the line.
• '__init__': Create the Line from a Cell list.
• '__len__': The the number of cell in the line.
• '__setitem__': Replace a Cell in the line.
• 'append': Add a new cell in the line.
• 'js': Translate the line in JavaScript
• 'pop': Remove the selected cell from the line.

Lines

The Lines object is usable as a Python list of Line. But as it knows the columns it performs some high level functions. It is a dictionnary of lines, the key is the line_id.

• '__contains__': Returns True if the line_id is known.
• '__getitem__': Access to a non existent Line create a new line with the good number of empty cells.
• '__init__': Create an empty set of lines for the given columns
• '__iter__': Iterate over all the lines.
• '__len__': Returns the number of lines.
• 'get_grp': Get the 'Grp' value for the student
• 'get_seq': Get the 'Seq' value for the student
• 'items': Iterate on the line to get the pair: (line_id, line).
• 'js': Create JavaScript generating all the lines data.
• 'keys': Iterate on the line to get the line keys: line_id.
• 'line_compute_js': Create the JavaScript program that initalizes 'line' with all the informations for the student. The value computing is done in javascript.
• 'line_html': Returns an HTML string displaying all the information in the line. This function is used to display the 'suivi'. The content is not the same for teacher and students because teacher have access to table links and boolean toggle to directly modify the tables. This function is expensive because the student rank is computed for all 'Note' columns.
• 'line_indicator': Returns a list of (date, cell_indicator) for the column type given. It is used to compute icons.
• 'values': Iterate on the line to get the line values.

UE

Contains all the information about the UE (Unity of Evaluation).

• '__cmp__'
• '__init__': This object may retrieve information from other data sources
• '__str__': Returns the Python code creating this object.
• 'code': Returns a database code to access this UE.
• 'intitule': Returns the title of the UE.
• 'js': Returns the code to create the JavaScript object for this one. If read_tt is a list, then TT students are stored in the list.
• 'mails': Returns all the mails of the managers of this UE.
• 'parcours': Return the list of diploma using this UE.
• 'responsables': Returns the NAME list of the manager of the UE.
• 'responsables_login': Returns the LOGIN list of the manager of the UE.
• 'short_parcours': Returns the UFR managing this UE.

Types of columns

They are defined in COLUMN_TYPES directory. To add a new column type, the only thing to do is to add 2 new files in COLUMN_TYPES. There is a Python and a JavaScript file per type. Types are defined by a class tree.

The table of types display for each types how to manage the column and the cell. More explanations are in the text.py file.

Attributes of table columns

Attributes of tables

TOMUSS server side threads

The server need informations from other servers, in order to be responsive, the requests must be performed in threads. To simplify the program, there is a single thread per data type to be updated.

• authentication_thread: It verifies the user identity and redirect the browser if it is not known.
• check_send_queue: In order to not block the server if a client is slow to receive the data, the send action is performed in a thread. The thread read a FIFO to get its job.
• check_new_students: The thread read a FIFO to get its job. It launches the 'check' function of the UE template in order to update the student list and informations.
• check_students_in_tables: periodicaly push job to the 'check_new_students' thread. The push interval is configuration.students_check_interval
• check_requests: The thread read a FIFO to get its job. It's this thread that perform all actions on a table. The requests stays in the FIFO if there is a missing request. It may happen because image loading in the browser is not sequential.

Some external processes launched by crontab compute some files periodicaly. TOMUSS reread the file is they appear to be modified.

TOMUSS client side

A maximum of work is done by the client, for exemple, average and other computation are not done by the server.

The home page

The page is generated by the 'home2' plugin. The client side knows the full UE list and the UFR of the user, so it can automaticaly filter the interestings UE.

Most of the URL are computed with a small javascript function who take the current semester/year from the user selection and append the current ticket.

The page template is stored in 'top2.html' file.

The ABJ/DA editing page

The page stay open in order to receive server information. The client load image to ask things to the server. the server answer is a JavaScript program updating the screen data.

The clients files are abj.html and abj.js

The table editing page

The client load the page that stay open in order to receive updates as JavaScript codes. The client actions are done by inserting image, the image is inserted where the user interaction took place and under the table. It is done so because, an image must stay visible when the user change of page or filter the table. The image is at the same time the server feedback indicating if the action performed well.

The server, indicate that the action was performed with a javascript code. When the client receive this code, it removes the matching images from under the table. In the normal case, there is no image under the table.

If an image is not loaded after some time, the image URL is modified in order to retry the aborted load because navigator do not retry failed loads.

If image loads fails and the server is active, then we assume that communication fails because the ticket is no more valid (IP change for example). In this case, the user is asked to authenticate once more.

Client side objects

As TOMUSS started as a trivial program, it was not developed with JavaScript objects. The only objects are:

• 'UE': matches the informations from the Python UE object.
• 'Cell': The table cell.
• 'Current': The management of the current cell in the screen.
• 'Stats': An object allowing to compute statistics.
• 'Request': Allow fiable communication with the server.
• 'types[]': Defines all the columns types.
• 'columns[]': Defines the columns, needs methods to be really an object.

A Table object should be added in order to clean the code.

Virtual tables

These tables are not stored into files. They can be :

• Server side : See 'PLUGIN/resume.py' as a template.
• Client side : See 'FILES/lib.js/statistics_per_group' as a template.

TOMUSS Administration

Semesters

TOMUSS retrieves the current student list without knowing to which semester it apply.

The procedure to change of semester is the following:

Table templates

Table templates are stored in 'TEMPLATES' directory. When loading a page, if the file match a template it is applied, if the semester match a template it is applied. Only one template can be applied. The templates may defines :

• 'create': How the table is initialized on creation.
• 'init': A hook called before table is loaded.
• 'onload': A hook called after table is loaded.
• 'content': A function returning the content to be appended to web page. It is mostly JavaScript redefinition and content update.
• 'check': A function updating the student list in the table.
• 'cell_change', column_change: A function called on cell content change or column_change. It must not use external services because it must return quickly. If this function raise an exception, the value will not be stored in the table.

Semester templates defined are:

• 'Printemps', 'Automne','Test' are standard table to enter data about students.
• 'Preferences' is the standard table to enter user preferences.
• 'Referents' is the definition of the referent teacher notepad.
• 'Favoris' is the definition of the favoris notepad.
• 'Dossiers' is the definition of an empty table modifiable only by the user that created it.
• 'Test' this semester contains real students but it is a sandbox allowing to try anything.

Table templates defined are:

• 'config_table' the TOMUSS configuration.
• 'config_plugin' the TOMUSS plugin access list.
• 'ticket' store the live tickets.
• 'FAQ', 'wishlist' are stored in year 0 and allow a user/developper interaction.
• 'tt' create the table used to enter TT.
• 'average' create a test table about averages.

The table template must be created in order to match the teaching organisation.

Do not store information in the module itself because it will be lost when the TEMPLATE is reloaded (it is triggered by a file change).

The recommended way to define columns in a template is the table method update_columns. It will create and update columns definitions.

Authentication process

The URLs start by a ticket. If there is no ticket, the navigator is redirected to a service in order to get a ticket. If CAS is not used, then a random ticket number is generated.

The tickets are ``exchanged´´ between the TOMUSS processes as a python module containing all the valid tickets.

To be valid, a ticket must be used with the same navigator and the same IP than the first time.

'ticket.py' define the ticket object that store tickets and parse URLs. It is a generic and not configuration dependant.

A new ticket can be used to revalidate an old ticket, it is useful if the client IP changed.

'authentication.py' can be redefined by a local plugin in order to have the good code for the functions 'ticket_login_name' and 'ticket_ask'. If CAS is not used, then these functions assume that the authentication is done with Apache/.htaccess/.htpasswd with the Basic authentication method (the clear password is checked with su)

In regtest mode, the URLs accept =username as a valid ticket for the user.

Apache/NGINX configuration

TOMUSS urls are for example:

• http://tomuss1.fr:8888/ The main process
• http://tomuss2.fr:8889/ 'Suivi' for Automne 2008
• http://tomuss3.fr:8890/ 'Suivi' for Printemps 2009

To have TOMUSS working with nicer URLs we can configure Apache as:

<VirtualHost tomuss.fr:80>
ServerName tomuss.univ-lyon1.fr
RewriteEngine On
RewriteRule ^(.*) http://tomuss1.fr:8888$1 [P]
</VirtualHost>

<VirtualHost tomusss.fr:80>
ServerName tomusss.univ-lyon1.fr
RewriteEngine On
RewriteRule ^(.*/2009/Printemps/.*) http://tomuss3.fr:8890$1 [P]
RewriteRule ^(.*/2008/Automne/.*)   http://tomuss2.fr:8889$1 [P]
# 'Suivi' on the current semester
RewriteRule ^(.*)                   http://tomuss2.fr:8889$1 [P]
</VirtualHost>

We can configure NGINX with:

proxy_buffering off;         # To be really interactive
proxy_read_timeout 1000000;  # To keep connection open

server {
    listen   80;
    server_name  tomuss.fr;
    location    /                       { proxy_pass http://tomuss1.fr:8888; }
}

server {
  listen   80;
  server_name  tomusss.fr;
  location    /         { proxy_pass http://tomuss3.fr:8890/2009/Printemps/; }
  location ~ ^/(=[^/]*/)?2009/Printemps { proxy_pass http://tomuss3.fr:8890; }
  location ~ ^/(=[^/]*/)?2008/Automne   { proxy_pass http://tomuss2.fr:8889; }
}

With this, the URLs become:

• http://tomuss.fr/ The main process
• http://tomusss.fr/2008/Automne/ 'Suivi' for Automne 2008
• http://tomusss.fr/2009/Printemps/ 'Suivi' for Printemps 2009

TOMUSS configuration

The initial TOMUSS configuration is stored in configuration.py. To avoid mistakes, DB is the production database name and DBtest is the development database. configuration.py tests the host name in order to to setup a production or a development environment.

configuration.py must not be modified because it will be overwrited by each TOMUSS release. The file LOCAL/__init__.py must be edited to customize and configure TOMUSS.

This customization is done by replacing default functions by yours. For the UCBL university there is:

# The login and the student ID are not the same at the UCBL
# login_to_student_id, the_login, login_to_id (JavaScript)
import LOCAL.student_id

# get_ue_dict: Retrieve all the informations about all the UE
import LOCAL.spiral

if not regtest:
    # ticket_login_name: Get login name from ticket
    # ticket_ask: redirect the browser to ask a ticket
    import LOCAL.auth

    # stupid_password: Returns True if the password is stupid
    import LOCAL.checkpassword

    # students: Iterator on all the students of an UE, returns :
    # (student_id, firstname, surname, mail, group, sequence)
    import LOCAL.students_of_ue

Most of the configuration values are modifiable while TOMUSS is running by editing as 'root' the table named 'http://......../0/Dossiers/config_table' The values in this table have precedence over values stored in the configuration source files. Nevertheless the first time, this table is created using the configuration source files

TOMUSS Regressions Tests

The makefile goal regtest run an infinite loop on some server tests. The loop is broken if there is a problem.

The URL http://SERVER/2009/Test/javascript_regtest_ue run some javascripts tests on the user interface. These tests works on FireFox and Opera but not on IE.

TOMUSS starting and stopping

The makefile goals start and stop allow to manage the TOMUSS services. There is one database modification service and one 'suivi' service per semester in order to not have huge processes. The 'suivi' processes are huge because they load the full semester in memory.

TOMUSS install on production server

The goal install of the Makefile runs the script install that do all the work to replace a running TOMUSS by the new release.

• The script contains the two directories where TOMUSS programs and databases must be copied.
• At any time, the current version can be stopped and an older restarted because all versions are kept.
• When running, the two databases are perfectly synchronized.
• When installing a new version, the synchronisation is verified.
• If the active directory is no more accessible, the backup directory is usable without modification.
• The installation process configure crontab in order to:
  • restart automaticaly stopped programs,
  • make daily backup,
  • create statistics charts,
  • update 'xxx_toute_les_ues.py', 'all_ues.js'.

Two symbolic links (DB and BACKUP_DB) points on directory where the database is stored.

Required packages : python-ldap, python-imaging, gzip

Recommended packages : gnuplot, graphviz, rsync (distant mirroring), catdoc (csv extract from xls)

TOMUSS managing

The TOMUSS root can use the following features:

• Interactively browse the python server object memory.
• Compute the favorite list for the semester once there is some data.
• Remove tables without any user generated content.
• See the live log of server actions.
• See the time statistics about the servers functions.
• See the tickets alive.

Some non automatic work to do: see LOCAL/Makefile

TOMUSS Pitfall

When loading a Python module, never store the 'configuration' values in local variables because the configuration module may not be fully loaded.

Use the function 'unload_module' to unload a Python module in order to not have a memory leak.

Never modify the database files if the table is loaded in the TOMUSS server.

Functions to redefine in order to customize TOMUSS

If you want your TOMUSS customization to not be destroyed by a version change you must follow the procedure. The functions listed are the ones that you need to modify, but you can modify any function you want.

import files

files.files['lib.js'].append("a_key", """
function the_function_to_be_redefined()
{
}
"""

import a_module

old_one = a_module.to_be_redefined

def to_be_redefined():
   old_one()

a_module.to_be_redefined = to_be_redefined