User roles

The meetü installation profile defines several custom user roles with varying permissions, to allow each game organizer to be responsible for a different part of the workflow. The custom user roles are described as follows:

meetü workflow

The typical workflow of a meetü game instance is as follows:

  1. Game organizers write-up missions on the meetü website that encourage participants to connect with one another.
  2. Game organizers export missions from the website to a third-party application to create mission cards.
  3. Game organizers use the meetü website to generate and print QR-code sticker sheets for participants to use to identify themselves uniquely on the mission cards they use during the game.
  4. At the kick-off event, participants stop by a designated game pick-up location to pick up their QR-code sticker sheet and set of starter mission cards.
  5. When a participant receives his or her sticker sheet, he or she peels off the top-left sticker of the sheet and places it on a keeper card, which he or she will use during registration after the game.
  6. When a participant obtains a mission card, he or she peels off one of the QR-code stickers from his or her sticker sheet and places it onto a designated spot on the mission card to uniquely identify who is completing the mission.
  7. Participants follow the instructions printed on each mission card, exchanging QR-code stickers with other participants as necessary.

meetü: The Social Networking Game from the OPL @ RIT

meetü is a Drupal-based platform for running games that encourages people to connect with one another, either for an event or as part of a group’s ongoing effort to get to know itself. The main way that the platform does this is by providing game organizers with the ability to create missions – miniature quests that participants must complete that involve interacting with other participants or with exhibits.

User terms: taxonomy terms on users

The User terms module allows you to apply any number of your taxonomy vocabularies to users.


Configure the module at admin/user/user_terms:

ModSecurity Considerations

ModSecurity is an Apache module that applies a set of rules to the activities of software run on Apache. It is used by some hosting environments to assure security, but some rules can interfere with the normal operation of Drupal. Because each ModSecurity administrator can write their own rules it is impossible to be certain that Drupal does not get caught up in these rules.

It is possible for Drupal to get caught correctly. Before implementing the solutions below to turn off part or all of ModSecurity, be sure that Drupal is being caught improperly. Be certain that the activity being stopped is not due to some malicious or potentially dangerous activity and that the security of your site will not be compromised.

It is possible, given the right permission or cooperation from your hosting company, to either turn off specific rules for your site or turn ModSecurity off entirely for your VirtualHost.

Reporting Bad Rules to ModSecurity

Sometimes, ModSecurity rules that catch Drupal doing valid things are simply unneeded or over-reaching. You can help ModSecurity consider stronger and more precise rules that will benefit the whole ModSecurity community by submitting them as bugs upstream and encouraging them to fix the rules. In the mean time, you'll probably want to turn the rule off as described below.

CCK Blocks

With CCK Blocks, each cck field is you can select cck fields to be available as a block. These blocks can be added to whatever can handle blocks (sidebar, panel, etc.).

When the block for one field is enabled on the blocks configuration page, this block shows up for every node that's content type contains the field for the corresponding block. That means: the block doesn't show up when displaying any other node or page that doesn't contain the field the block belongs to!


Subscribe with RSS Subscribe to RSS - Site administrators