AMS Design Info

Owned by Daan Janssens
Last updated: Sept 16, 2013

A brief introduction to the design of the AMS

We will take a look at the design decisions we took at the beginning of the project, the current db design, the directory structure, the way page loading in the WWW version works and the way the classes are designed.

We won't go into implementation details or explain what every class exactly does, for that you can find a doxygen generate website that covers all our code documentation at code/ryzom/tools/server/ryzom_ams_docs/html/index.html

Content

 

Decisions made at the beginning

  • Technologies used

  • How to handle the ingame browser?

    • Smarty comes in handy here: The ingame browser loads a different template set as the outgame version (The ingame templates are located in the 'ams_lib' itself). Why can't it load the same templates you might think? The ingame browser uses LibWWW, which supports only a small set of html tags and no css. You can see the allowed set of html tags on the Ingame browser page.

  • How to handle #languages?

    • In the lib itself there's a Languages directory with multiple .ini files, one for each supported language. The content of these .ini files will be parsed just before loading the template and the part that's needed for the page being loaded will be passed.

  • Admins/Mods/Users

    • Our current permission system supports those 3 kinds of users, the permission level for this is stored in the db (ticket_user table).
      After installing the system there's an initial admin namely "admin". You can login to that user and assign other users as moderator/admin.

  • Syncing cron job

    • It's perfectly possible that the website is still up even though the shard is offline (crashed, or migrating or what so ever), here 'Synchronizing' comes in play. All new created users or changes to the password/email will be stored in a querycache (db). A sync cron job will run on the server and from the moment the server is back up, the changes will be pushed to the server!

  • Mailing cron job

    • A mailing cron job is needed to pull new emails sent to the inboxes of our support groups, we use the IMAP protocol to talk with the inboxes. New emails will be processed and actions will be taken (eg: if a new email comes in from a user's email address with no ticket related, then it will create a new ticket for it.). The cron job will also take care of sending outgoing emails, which are temporary stored in the db.

The database structure

Next we started with the design of our database. I had to think about the advanced AMS features in advance. This is the reason why there are still a few unused DB tables in the design, the plan however is to use those as soon as possible by implementing the extra features.

The tables that are unused are the following:

  • ticket_group
  • in_group
  • tag
  • tagged

The idea for the ticket_groups was to provide the ability to bundle multiple tickets together in groups, this could be used for tickets that are alike or are in a weird way related. The idea for the tagging was to provide an extra system that allows to query tickets based on their tags (data mining). These features can be easily added in the future!

Let's take a look at the 'used' tables. The database structure is shown in the image below. For each table I made a matching class that handles the info of that table.

Quite central you can see the ticket table. As you can see, a ticket has a ticket_category field and author field, these hold the id of the related row in the ticket_category and ticket_user table. There's also the relation between a ticket and it's log entries, this is done by the ticket foreign key in the ticket_log table. The same counts for most other tables that are related to the ticket, they all got a ticket column used as foreign key.

Another thing that you might notice is the separation between ticket_reply and ticket_content, this is a 1-to-1 relation and this makes it easier to search between the replies if we only need their general information without having to take care of the content. The ticket_user is another quite important table that's being foreigned keyed by the others. It holds the permission of a user and the externID links to an ID given by the CMS(or our own www version)

Most things are pretty clear and straight forward, you can find the MYSQL Workbench file in the ryzom_ams/www/html/sql folder, which might give a better overview and can be used to update the DB easily when adding/modifying features in the future.

Information regarding the directory structure

As you might have noticed, the ryzom_ams directory contains 3 directories: the ams_lib dir, the www dir and a drupal_module dir.

  • the ams_lib contains the following important dirs/files:
    • autoload dir holds all classes of the lib
    • cron dir holds the cron functions regarding email and the ams_querycache
    • ingame_templates dir holds the templates that are being used while ingame
    • smarty dir the smarty files (http://www.smarty.net/)
    • translations dir multiple .ini files, one for each language that's being supported.
    • libinclude.php php file that holds the __autoload function
  • the www contains the following important dirs/files:
    • autoload dir holds the webusers.php file (which extends the Users.php file in the lib)
    • func dir holds php files that contain a function that is being executed after filling in a form.
    • inc dir holds php files that contain a function that is being executed before loading a specific file.
    • templates dir holds the templates being used outgame.
    • config.php php file that holds configuration settings
  • the drupal_module contains the following important dirs/files:
    • autoload dir holds the webusers.php file that uses drupal functions (which extends the Users.php file in the lib)
    • func dir holds php files that contain a function that is being executed after filling in a form.
    • inc dir holds php files that contain a function that is being executed before loading a specific file.
    • templates dir holds the templates being used outgame.
    • config.php php file that holds configuration settings
    • ryzommanage.info drupal file that holds information being used by drupal
    • ryzommanage.install drupal file thats being used for installing the module
    • ryzommanage.module drupal file that holds all functionality that's being needed to handle the AMS in drupal.

Important: the func dir and inc dir in the drupal_module are almost empty, that's because the inc/func directories of the WWW version can be copied to the drupal version, they are exactly the same. However, because the drupal_module isn't completely up to date, the settings page doesn't has the extra fields (like gender,country,..) therefore the ingame template file, inc files related to that are still in the module.


How does the page loading work?

How are the classes being used?

Like I mentioned above, each DB table has a class related that handles the data linked to that table and has functions working with that data.

The private attributes of each class are similar to the fields in the DB table. Every class also has the following functions:

  • function __construct()
  • function set($values)
  • function create()
  • function delete()
  • function load( $id) or named similar
  • some also have: update ()

These methods are being used by the public static functions of that class, which represent the 'real' AMS-functions, the ones being used by the inc/func files.

You can reference for example the Support_Group class's information, which shows this setup!