File/program/modules/crew/crew_admin.php

Description

/program/modules/crew/crew_admin.php - management interface for crew-module

This file defines the administrative interface to this module. The interface consists of the following four functions.

    crew_disconnect(&$output,$area_id,$node_id,$module) crew_connect(&$output,$area_id,$node_id,$module) crew_show_edit(&$output,$area_id,$node_id,$module,$viewonly,$edit_again,$href,$option) crew_save(&$output,$area_id,$node_id,$module,$viewonly,&$edit_again,$option)

These functions are called from pagemanagerlib.php whenever necessary.

Constants
CREW_ACL_ROLE_READONLY = CREW_PERMISSION_READ (line 41)
CREW_ACL_ROLE_READWRITE = CREW_PERMISSION_READ|CREW_PERMISSION_WRITE (line 42)
CREW_PERMISSION_READ = 1 (line 39)
CREW_PERMISSION_WRITE = 2 (line 40)
Functions
crew_connect (line 89)

connect this module to a node

this makes the link between the node $node_id in area $area_id and this module. In this case we simply link a single workshops record to node $node_id in a 1-to-1 relation. Any permissions (ACL) can be stored in the acls_modules_node table later but by default we start afresh with just a bare workshops record.

Note that we set the parameter 'visibility' to 0. This implies a workshop that is only visible for the individual accounts that are explicitly allowed to view and/or edit. It is up to the user to configure the workshop in a different way, e.g allow all accounts to view the workshop results (visibility=1) or allow the world to see the results (visibility=2).

  • return: TRUE on success, FALSE otherwise
bool crew_connect (object &$output, int $area_id, int $node_id, array $module)
  • object &$output: collects the html output (if any)
  • int $area_id: the area in which $node_id resides
  • int $node_id: the node to which we need to connect
  • array $module: the module record straight from the database
crew_disconnect (line 58)

disconnect this module from a node

this breaks the link between the node $node_id in area $area_id and this module. For now we simply delete the relevant record from the workshops table. Also we remove any record which might exist in the ACL table acls_modules_nodes for this particular node.

  • return: TRUE on success, FALSE otherwise
bool crew_disconnect (object &$output, int $area_id, int $node_id, array $module)
  • object &$output: collects the html output (if any)
  • int $area_id: the area in which $node_id resides
  • int $node_id: the node from which we need to disconnect
  • array $module: the module record straight from the database
crew_get_dialogdef (line 350)

construct a dialog definition for the workshop configuration

this generates an array which defines the dialog for workshop configuration. There are a few plain fields that simply go into the appropriate workshops record and the save and cancel button. However, there may also be items related to ACLs. These fields are used to define the user's roles and the should be presented in a table. We abuse the field names for this purpose: if the first 3 characters are 'acl' we put the widgets in an HTML-table, otherwise it is just an ordinary widget.

Note that in the case of a single simple user without any aquaintances (ie. a user that is not member of any group) the user is not able to add herself to the list of authorised users. What is the point of having a _collaborative_ workshop when you are the only one to collaborate with? (However, it would be fairly easy to force/add an entry for this user if the tmp table would turn out empty. Maybe later....?)

  • return: dialog definition
array crew_get_dialogdef (object &$output, int $viewonly, int $module_id, int $area_id, int $node_id, int $user_id)
  • object &$output: collects the html output (if any)
  • int $viewonly: if TRUE the Save button is not displayed and values cannot be changed
  • int $module_id: indicates the id of the crew module in the database (needed for ACL)
  • int $area_id: indicates the area where node_id lives (needed for ACL)
  • int $node_id: indicates which page we are loooking at (needed for ACL)
  • int $user_id: indicates the current user (needed for ACL)
crew_save (line 248)

save the modified content data of this module linked to node $node_id

this validates and saves the data that was submitted by the user. If validation fails, or storing the data doesn't work, the flag $edit_again is set to TRUE and the return value is FALSE.

If the user has cancelled the operation, the flag $edit_again is set to FALSE and the return value is also FALSE.

If the modified data is stored successfully, the return value is TRUE and the value of $edit_again is based on the button used to save ([Save] or [Done]).

Here is a summary of return values.

$retval | $edit_again | Action
------- | ----------- | ------
FALSE   | FALSE       | [Cancel] Stop editing, unlock & return to tree view
FALSE   | TRUE        | [Save] or [Done] failed: redo the dialog and let user correct mistakes
TRUE    | FALSE       | [Done] pressed, everything saved succesfully, we're done
TRUE    | TRUE        | [Save] pressed, everything saved succesfully but continue editing

The parameter $option is not used in this module.

  • return: TRUE on success + output stored via $output, FALSE otherwise
bool crew_save (object &$output, int $area_id, int $node_id, array $module, bool $viewonly, bool &$edit_again, string $option)
  • object &$output: collects the html output (if any)
  • int $area_id: the area in which $node_id resides
  • int $node_id: the node to which the content is connected
  • array $module: the module record straight from the database
  • bool $viewonly: if TRUE, editing and hence saving is not allowed
  • bool &$edit_again: set to TRUE if we need to edit the content again, FALSE otherwise
  • string $option: indicates which submenu-option was selected (NULL for none)
crew_show_edit (line 143)

present the user with a dialog to modify the workshop that is connected to node $node_id

this prepares a dialog for the user filled with existing data (if any), possibly allowing the user to modify the content. If the flag $viewonly is TRUE, this routine should only display the content rather than let the user edit it. If the flag $edit_again is TRUE, the routine should use the data available in the $_POST array, otherwise it should read the data from the database (or wherever the data comes from). The parameter $href is the place where the form should be POST'ed.

The dialog should be added to the $output object. Useful routines are:

    $output->add_content($content): add $content to the content area $output->add_message($message): add $message to the message area (feedback to the user) $output->add_popup_bottom($message): popup $message in browser after loading the page (uses JS) $output->add_popup_top($message): popup $message in browser before loading the page (uses JS)

The parameter $option is not used in this module.

  • return: TRUE on success + output stored via $output, FALSE otherwise
bool crew_show_edit (object &$output, int $area_id, int $node_id, array $module, bool $viewonly, bool $edit_again, string $href, string $option)
  • object &$output: collects the html output (if any)
  • int $area_id: the area in which $node_id resides
  • int $node_id: the node to which this module is connected
  • array $module: the module record straight from the database
  • bool $viewonly: if TRUE, editing is not allowed (but simply showing the content is allowed)
  • bool $edit_again: if TRUE start with data from $_POST, else use data from database
  • string $href: the action property of the HTML-form, the place where data will be POST'ed
  • string $option: indicates which submenu-option was selected (NULL for none)

Documentation generated on Tue, 28 Jun 2016 19:08:59 +0200 by phpDocumentor 1.4.0