IofC Drupal Project Documentation Manual

This manual has been created to provide thorough documentation of the IofC Drupal Project. Our project will, in hindsight, be understood primarily through this document. Please review the table of contents to find your way.

Edward Peters, John Freebury

The Structure of this Book

This book is structured as follows:

Introduction and Background

This first section provides an introduction to this project, and some background information on why IofC has begun working with Drupal. It briefly surveys the history of IofC web development, how we reached a crossroads in thinking about the future, and how we came to the decision to switch to Drupal.

About the IofC family of websites

To understand our project you need to understand a little about the sites which are currently part of the 'family' of IofC sites. At time of writing (October 2007) they consist of 15 or so 'public' websites and one 'private' site for IofC activists, which we call the Extranet. All these sites apart from the Extranet share a backend and run off the same two mysql databases. A unique ID 'webuser' identifies all content so that all content can be shared across all sites.

The public sites are grouped into:

You can see that these sites share branding features, in most cases, though some look quite different.

All major content can be placed onto any of the sites (news stories, etc).

Furthermore the contact data used for these sites (email forms, etc) is taken from one data set which is used for the IofC contact database, integrated into the user info for users of the Extranet.

Our proprietary system (although unfinished) works relatively well. So why have we decided to move into Drupal?

Read on.....!

Why we decided to switch to Open Source

For over five years the IofC web team has been trying to develop an integrated content management system to meet the varied web and internet needs of this global network.

The first iteration (achieved in 2003) was a standalone Extranet (member) website, and several public standalone sites.

The second iteration (achieved in 2005) was the integration of all the public websites into one database infrastructure – with major benefits in content sharing and in speed of new site development.

The third iteration (on which we were working since 2005) involved a migration to a new, more solid architecture to carry the weight of an integrated Extranet (with its more specialised functionality) as well as the public sites, all in one system.

In mid 2007, however, it became apparent that our little team was too small, and not skilled enough by itself, to complete the third iteration in the way we had envisaged. A major factor was the retirement of our brilliant programmer, Vitalie, who had done most of the programming for four years.

After initial dismay at this reality check, we came to see it not as a failure, but as an opportunity to embrace a new vision of how IofC’s web needs are to be met.

After some weeks of research we reached the preliminary recommendation that we should change our approach completely. Having been attempting to build a proprietary system, using our own dedicated personnel, we decided that the way forward involved engaging with an Open Source CMS project and community. Advantages of this approach include:

  1. Access to much completed programming which would save us time.
  2. Access to a worldwide network of technicians who share learning.
  3. Future sustainability more assured.
  4. An opportunity to contribute to this online community, offering to others the benefits of our own experience of the past five years.
  5. A faster way to network with other NGOs which are creating similar systems to meet their needs.
  6. ‘Open Source’ fits well with IofC’s ethos of sharing and community-building.

Drupal was recommended to us as one of the best CMS projects available. Our initial look at it confirmed that it might have most of what we needed. But there were other CMS fameworks to consider....

Assessing and choosing Drupal

August 30, 2007: by Edward Peters

I’ve spent much of the past 2-3 weeks researching Drupal as a possible CMS for IofC. My research has involved a lot of reading, and also the installation of Drupal, adding modules and trying to build IofC functionality in Drupal. I agree with those who say that Drupal has a steep learning curve; I hope it’s true what people also say - that after a time, once one becomes familiar with Drupal, it becomes easy!

Drupal or Joomla?

If IofC is to go the Open Source route, there seem to be only two possible options – Drupal or Joomla. I have not installed and played around with Joomla to any extent. But I have done some reading on it. The conclusion is that Joomla has some advantages, and Drupal has other advantages. It all comes down to what is most important for us – neither product will give us the best of all worlds. A not very recent comparison can be found at http://www.alledia.com/blog/general-cms-issues/joomla-and-drupal-%11-which-one-is-right-for-you?/. This was written before the launch of Drupal 5 (now stable) and Joomla 1.5 (not yet stable, but likely to be a big step forward).

An independent assessment done for the Canadian Union of Public Employees (CUPE) is available at http://openconcept.ca/sites/openconcept.ca/files/OpenConcept%20-%20CUPE%20CMS_0.pdf; it makes a clear recommendation in favour of Drupal, because of Drupal’s better multisite and multilingual functionality.

Joomla is more commercially oriented, and has more of a commercial development community. Drupal is more fully open source, and it can be harder to find commercial developers for it.

What I have read indicates that Drupal is better in ‘architecture’ and Joomla better in most ‘functionality’. One developer writes: “As a developer with the capability to write code, I find myself much more concerned with architectural matters. Functionality can be programmed, but I’m at the mercy of architecture. Put another way, give me the right tools and materials, and I can build anything.”

My view based on what I have so far discovered is that Drupal is a better option for us than Joomla.

Internationalisation

This is a core requirement for IofC. In Drupal release 5 there is no core support for multilingual content (this can be achieved by adding the i18n module, but it is limited). In Drupal 6 much of the i18n functionality is built into the core, and it is being seen as a big advance. See http://www.developmentseed.org/blog/internationalization/comparison_chart for

I have experimented with multilingual content, and it works quite well, including the translation flow. However, I ran into a problem with Views (the module that creates dynamic lists of content) and could not get it to work well with multilingual content. I could save views as blocks and then add them to pages, but the Page View mode did not work properly. I think there may be some compatibility issues between the i18n and Views modules. The Views module is being completely rewritten for Drupal 6, so we may find big improvements - and at the very least no compatibility problems.

Multisites

This is another core requirement for IofC. We have yet to be satisfied that this can be achieved properly. But all I have read about Drupal makes me fairly confident that it can be done. The assessment done for CUPE (referred to above) specifically mentions Drupal’s multisite capability as a core strength for an organisation like CUPE which needs hundreds of small local websites for its members.

There are likely to be more than one way of achieving this, and we will need technical advice on the best way. We have to be sure we can achieve multisite functionality, before we go too much further.

Taxonomy

This system of being able to classify and categories almost all types of data is very powerful and gives us great scope for major functionality.

Themes

These are powerful, but take some work to understand. In a multisite environment, page templates are stored by site. I think we will be able to customise look and feel as we have done in our interim system, though it will work differently. Some aspects may be more powerful than in our system (e.g. you can have templates for different nodes and for different users), while other aspects may be less powerful than ours.

Contacts, virtual databases, users, groups and security

From my limited exploration of CiviCRM, I think that it will handle most of our needs, but I have not gone deeply into this.

Many things are simple in Drupal

As I have gone along I have been impressed by how much Drupal can do without any programming. Some of it is big and some of it is just little but valuable things. A few brief examples (there are many more):

  • Interface translations come all ready for many languages.
  • RTL (right to left) text easily accommodated.
  • Translation flows.
  • Comment/feedback forms can be attached to any node – both as a default setting for a content type, but also overridden for individual nodes.
  • Forums work well with minimal tweaking.
  • Blogs are built in to the system.
  • Creation and placement of dynamic data sets is excellent through the Views module.
  • Excellent user customisation functionality.
  • RSS built in.
  • Logging is very good.
  • Excellent developer/debugging/system tools.
  • Collaborative tools like Book authoring built in.
  • Cross-browser compatibility, and accessibility standards.
  • Good security.

But we will have to make sacrifices if we use Drupal

There is no getting away from the fact that we will not get very close to our ideal CMS functionality if we use Drupal. With our proprietary system we can achieve just about anything we want, but with Drupal we will have to sacrifice some of our ideas. In particular I think we will have to modify our hopes with regard to:

  • Our proprietary system of blocks which can be shared. Drupal works in a different way.
  • Sharing of ‘articles’. This is going to be harder to achieve in Drupal. We may possibly even have to abandon it altogether.
  • Enforcing one occurrence of URLs through a database table. It may not be impossible to programme this but it could be difficult.
  • Multilingual caption system for photos. I am not sure yet, but if we use Gallery2 we may have to settle for one caption with each photo – but then allowing editors to add a dedicated caption when placing a photo.
  • The user/group system is unlikely to be as good as the one we have at present.
  • Document management is not great at present, but new modules may be coming.

Weighing it all up

For most of the past three weeks I have been leaning heavily towards Drupal. But, as I have become more aware of the limitations it will place on us, I have remained open to the idea of continuing our proprietary system. To go that route would see us with a product which would undoubtedly be closer to our ideal in many areas. But it too would involve considerable compromises as we could not expect to develop all the interactive Web 2.0 features we want, nor keep up with the new developments that are unfolding all the time in the world of the web.

Going with Drupal will mean sacrificing some of our ideas, but it will mean embracing many good new ones. It will give us significant advantages in terms of adherence to standards, access to core functionality which is time-consuming to programme, participation in a worldwide community of developers, and the capacity to stay close to the leading edge of web development.

My recommendation

It is clear to me that Drupal is not going to meet all our needs. But rather than focusing on what we will lack, I think we should focus on what we will gain. Let’s embrace Drupal and create an IofC framework and online community which utilises its strengths.

APPENDIX: Websites using Drupal

A full inventory of Drupal powered sites is at http://drupalsites.net/. The following sites are among those which use Drupal and can give us some confidence that we can achieve what we need:

http://www.greenpeace.org.uk/
http://www.theonion.com/content/

http://www.observer.com/

Amnesty International is apparently rebuilding its sites and CMS using Drupal.

Research & Planning

This section contains documentation relating to the research and planning phase of our project. It includes some general documentation giving guidelines on HOW to write requirements and use cases most efficiently.

Good Language Practices

Good Practices

  1. Use simple direct sentences.

    Every requirement should be a single active sentence, as short as possible, but no shorter. Long rambling sentences quickly lead to confusion and error, not to mention boredom for the reader.

    Bad:
    The user must login to the system by entering a password and a username which will be verified by the system against the usernames and password that they have stored in the user information repository in order to ensure that the user is a valid user who has the right to user the solution.
    Good:
    The user will login by way of entering a valid username and password combination.

  2. Make requirements atomic.

    Requirements must be atomic in order to ensure that compliance with the requirement is measured by the single goal of the requirement being achieved. If you can think of a small number of related tests to verify a requirement’s implementation, it’s probably written at the right level of detail. If you envision many different kinds of tests, perhaps several requirements have been lumped together and should be separated.

    Bad:
    The user will be able to create, edit, delete, suspend, open, and replace all files which they have the necessary access to.
    Good:
    The user will be able to create a new file, as long as they have the Add File user right.

  3. Avoid ambiguity

    This is one of the most subtle and difficult issues in writing requirements due to its subjective nature. In order to achieve this goal the requirement must be clear and explicit, but care must be taken not to take this too far as the text can become unreadable and boring and this will defeat the core objective of requirements – in other words they are meant to be read by others.

    Bad:
    In order to delete a task the user must enter some details.
    Good:
    In order to be able to delete a task the user must enter a further password which grants them the rights to delete a task.

  4. Use definable and non-vague terms

    Many words used informally to indicate desired qualities are too vague for use in requirements. Vague terms include “user-friendly”, “versatile”, “flexible”, “Configurable”, “Approximately”, “as possible”, “efficient”, “high performance”, “quickly”, “modern”, “well designed”.

    Bad:
    The searching functions must be as efficient as possible.
    Good:
    The searching functions must return their results in no more than 10 seconds regardless of the size of the results.

  5. A Requirement must not be too high level

    A good Requirement is at a high enough level to be understandable and precise enough to be complete.

    Bad:
    The solution will have security.
    Good:
    In order to protect the data the system shall be subject to security by way of all users being required to enter a valid username and password combination in order to perform any function.

  6. A specification should not contain contradictions

    Care must be taken that requirements do not contradict themselves in their descriptions, nor contradict other requirements

    Bad:
    The system will be a 24x7 solution although it will normally be unavailable on weekends.
    Good:
    The system will be available 5 days per week through out the year.

  7. Requirements must be technically and legally possible

    There is no use in specifying requirements which are technically impossible or beyond the law as they will never be implemented.

    Bad:
    The system will read the mind of the user and determine which colour is their favourite.
    Good:
    The system will establish the favourite colour of the user by asking them pre-defined questions, in order to establish their favourite colour by process of elimination.

  8. Requirements must be necessary

    A good requirement should be a business necessity and not a wishful thought by an individual.

    Bad:
    It would be good for the solution to enable a user to add more than one property to an application, although only one property can be linked to an application.
    Good:
    A user can add only one property to an application.

  9. Focus on stating results

    Every requirement should specify clearly a single desired and achievable result.

    Bad:
    The printout will contain some text, although it is uncertain what this text will contain.
    Good:
    The printout will contain a list of users and their address details.

  10. Define verifiable criteria

    Every requirement must be verifiable. Often it is possible to indicate the method of verification by adding a simple phrase to qualify a basic need. This enables the requirements to be a good base for the acceptance criteria of the solution to be delivered.

    Bad:
    The solution must be designed in order to guarantee that all of “very famos company” staff will enjoy the experience of using the application.
    Good:
    The solution must be designed in accordance with the user interface guidelines specified by standards.

  11. Do not design the system

    Requirements specify the design envelope, and if too much detail is supplied the design of the system will begin prematurely. Sometimes this is unavoidable if a requirement is to design the solution in a certain way, which in effect locks the designers in to designing the system according to the requirement stating the design constraint. Specifying the design rather than the actual need often increases the cost of systems by placing needless constraints on design and development.

    Bad:
    The user entity will be made up of three tables. The user table will be joined to the role table via the user_role table allowing for a user to have multiple roles.
    Good:
    The data model will enable a user to have one or more roles.

  12. Looking at a requirement from developer’s point of view can assist in measuring its quality

    To see if a requirement statement is sufficiently well-defined, read it from the developer’s perspective. Mentally add the phrase, “call me when you’re done” to the end of the requirement and see if that makes you nervous. In other words, would you need additional clarification from the System Requirements Specifications author to understand the requirement well enough to design and implement it? If so, elaborate on that requirement before you proceed.

     

  13. Do not build in let-out clauses

    Requirements which contain let-out clauses significantly increase the risk of the requirement not being fully realised. They look as though they are asking for something definite but at the last moment they back down and allow for other options. Problems arise when the requirements are to be tested and someone has to decide what, if anything could prove the requirement was not met. Dangerous let-out word include “if”, “when”, “except”, “unless”, “although”.

    Bad:
    The login process will never take no longer than 3 seconds unless the system is busy.
    Good:
    The login process must not take longer than 5 seconds to complete at all times.

  14. Avoid wishful thinking

    Engineering is a real-world activity. No system or components is perfect. Wishful thinking means asking for the impossible. Developers will rightly query or reject wishful requirements. Wishful terms include “100% reliable”, “Hand all unexpected failures”, “Satisfy all users needs”, “Run on all platforms”, “Never fail”, “Perfect”, “Upgradeable to all future situations”, “future proof”.

    Bad:
    All web browsers will be supported including any future browsers without the necessity to change any of the code.
    Good:
    Internet Explorer 5 and above, Firefox 2 and above will be supported only on a Microsoft Windows operating system.

  15. Do not mix requirements and plans

    Plans are essential, but they do not belong in the requirements of a solution. Usually they are updated throughout the project life-cycle, where as the requirements should stabilize. Mixing requirements with plans tends to increase the requirements workload through extra revision and review meetings. Danger signs are references to dates, deadlines, project phases and development activities.

    Bad:
    The solution will begin as a desktop application but will be converted into a web application at some time in the near future.
    Good:
    The solution should be written so that a web version can utilise the core code without the necessity to re-write the core code.

  16. Do not speculate

    Requirements are part of a contract between customer and developer, with users as interested third parties. There is no room for “wish lists” – general terms about things that somebody probably wants. Danger signs include use of generalisation words such as “usually”, “generally”, “often”, “normally”, “Typically”.

    Bad:
    The solution will most likely be deployed on five servers.
    Good:
    The solution will be deployed on five servers.

  17. Do not express possibilities

    Possibilities are indicated with terms such as “may”, “might”, “ought”, “could”, “perhaps”, “probably”. If developers do what they have to, they will always ignore things that user might possibly require.

    Bad:
    At some point in the future the solution may need to be able to run on UNIX servers.
    Good:
    The solution must be able to run on servers with both Microsoft Windows and UNIX operating systems installed.

  18. Take care when using the word “Or”

    The word “Or” can often cloud or severely confuse a requirement and render it as un-verifiable due to the conditional nature of the requirement. Where “Or” is used, often this indicates that there are two requirements being joined into one.

    Bad:
    The user can download customer documents to their local machine or they can print the files.
    Good:
    The user can download customer documents to their local machine

  19. Avoid stating requirements redundantly

    While including the same requirement in multiple places may make the document easier to read, it also makes it more difficult to maintain. This results in the necessity to update multiple instances of the requirement at the same time to avoid inconsistency.

     

  20. Avoid jargon, abbreviations and colloquialisms

    Where possible avoid jargon, abbreviations and colloquialisms. Where jargon or abbreviations are used, they must be listed with their meanings in the project glossary.

    Bad:
    If a user enters their SAD, they will in effect be considered as top dogs of the system.
    Good:
    If a user enters their special authentication details, they will be considered as super users, which entitle the users to perform all functions.


Requirements

The scope this section is to present all functional requirements for “IofC Drupal Project”.

Requirements defenition All requirements are grouped into the following top level packages:

Functional Requirements Functional requirements depict the operations that the IofC desires the solution to be able to perform.This is the most important type of requirements as it answers the question “What does the solution have to do?”

Non-Functional Requirements Non-functional requirement are mostly constraints which we have to work with in order to make the solution do, what the functional requirement state it must do.

Packages

Each top level package will have a two letter prefix which identifies the type of requirements which will be within the package or within sub-packages under the package. The high level outline of structure is illustrated below:
Requiremens

  • FR – Functional Requirements
  • NF – Non-Functional Requirements
    • BR – Business Requirements
    • UR – User Interface Requirements
    • HR – Hardware Requirements
    • SR – Software Requirements
    • PR – Performance Requirements
    • XR – Security Requirements

A package represents a group of requirements that have a common theme or are linked to the same area in the solution. All requirements packages under the top level packages and requirements will have a unique prefix which is constructed in the following manner: "AAnn_nn - Package Name/Requirement Short Description" AA refers to the two letter prefix identifying the type of requirement, and nn being a numeric which will be unique under each top level package (i.e. Requirement Type). The underscores (_) represent how many levels under the top level packages the requirement/sub-package resides.

FR - Functional Requirements

This is an early draft.

Functional requirements for IofC Drupal project. Version 2.2







Notes Open issues (19) Phase Priority Difficulty Version
FR01 Multiple Domains/Sites This package relates to the functionality required for providing multiple websites within one integrated system.
1

1
FR01_01 The solution must deliver an integrated system for running many domains/websites initially 20-25, but growing.
1 High High 1
FR01_02 Each domain/website must be able to define a look for its user interface using site specific theme using theme, menu and administration.

1 High High 1

Each domain/website must be able to build its own content.





FR01_03 Nodes, images and users/contact records must be shareable across all domains.

1 High High 1
FR01_04 Solution must use single Drupal's codebase for all websites Having one codebase we can simplify process of installation of security patches and upgrades of Drupal core. There are a lot of tricks how to achieve that. WE should choose one which suites the best for our needs. 1 High High 1
FR01_05 A User must be able to login from any site provided by solution . Users are shared across all sites, so that any authenticated user has access to the ‘private’ part of any website, and is able to move seamlessly between these ‘private’ websites without being required to log in again. How to share user's accounts ? Think about global Directory using OpenLDAP. www.openldap.org Dupal modules: ldapauth, ldapgroups, ldapdata. Seems to be promising for that. 1 High High 1
FR01_06 Each website (an international one, and 20-50 national and programme-oriented ones) needs to have both: A ‘public’ part (for anonymous users) and A ‘private’, community part (for authenticated users)
Notions “public” and “private” site-part are misleading here. It sounds like 2 separate places. Do you agree ? Each Drupal basic building block (node) must have access attribute, that will differentiate a node like public ( for anonymous users) or private ( for authenticated users)











FR02 Groups This package relates to the group system to be implemented.
1

1
FR02_01 Solution must provide dynamic “Group creation” functionality The process of creating a Group must be easy and intuitive and minimise the need for intervention by sitewide administrators. 4 group roles should be created automatically for a group when that group is created: * Member – defines who is part of the Group * Administrator – can administer all parts of the Group's membership except editing of contact records. * Webmasters – administers pages and content for the Group, including for a public website belonging to the Group. * Data Controller – responsible for those contact records assigned to the Group's data controllership (if any). One group may have a website, but another may not. If a group does not requires a dedicated website, then why does it require a Group-webmaster role in place ? 1 High Unknown 1
FR02_02 Solution must provide dynamic “Subgroup creation” functionality A group must be able to contain another group, so that the members of the subgroup are also members of the containing group.
1 High Unknown 1
FR02_03 Group creation operations must be tied to a role. Any Advanced User may create a Group.
1 High Unknown 1
FR02_04 Group administrator must be able to define additional group specific roles Any group member may have as many roles as required.
1 High Unknown 1
FR02_05 Group must be able to create ant type of Content A site may have many groups associated with it -- when a user creates a new site at least one group must be specified -- that group's content (team homepage etc.) will automatically be linked to the new site.
1 High Unknown 1
FR02_06 Each group must have its own calendar Events will be shown in group-calendar. Group administrator can hide events from their group calendar.
1 High Unknown 1
FR02_07 Access to some content on each private website must be able to be limited to a group. Groups need to be able to have their own Group pages/menus, etc within any domain/site.













FR02 Internationalisation This package specifies the multilingual functionality required.
1

1

Each website must be deliverable in two or more languages. where needed
1 High Unknown 1

Solution must provide a possibility to install additional languages. English will be default language for the system. Other languages installed initially will be: French, German, Swedish, Norwegian, Finnish, Dutch, Spanish, Portuguese, Russian, Chinese, Japanese.
1 High Unknown 1

There must be provision for RTL languages. Drupal core provides RTL
1 Low Unknown 1

On a multilingual website, the visitor must be able to choose from available languages. Chosen language must be used for user interface. The user interface must be in the chosen language, where translated strings are available. Strings must be multilingual
1 High Unknown 1




1 High Unknown 1

Content/nodes must allow a translation workflow.

1 Medium Unknown 1

The translation workflow should have an automated notification systems for translators.

1 Low Unknown 1








FR03 Theming This package describes issues related to the look and feel of the website.
1

1
FR030_01 Themes for national and programme websites must be easily cloned and adapted from default template. The default theme must be based on the current template at www.iofc.org
1 Low Low 1
FR030_02 Solution must provide UI template support Visually unrelated themes must also be available for some websites.
1 High Low 1








FR04 Content This package details the main types of content to be used.
1

1
FR04_01 Support for following content types must be provided: Page, Article,(Story), Event, Blog, Book, Forum, Project and Project issues, Images, Feedback, Comments A node must be editable only by its creator and by users of the group which 'owns' it.
1 High High 1
FR04_02 Each content type may have its own required fields, in addition to the default set.
What is the purpose of that “required field” ? 1 Unknown Unknown 1
FR04_03 Each content type must be configurable to allow revisions, comparison of revisions, and reversion.( Except Comments)

1 Low Low 1
FR04_04 Nodes must be shareable across domains and groups unless specified below. Thus a node published on Site X would generate the following possible options: * It could be published by Webmaster X only on Private Site X and/or on Public Site X * It could be shared with the Network (all sites) but not actually published anywhere else by default * Webmaster Y could then decide to publish this node only on Private Site Y and/or on Public Site Y * Only the creator of the node (Webmaster X in this example) is allowed to edit/delete the node * Webmaster X needs to be able to publish the node only to Group Z (a group exclusive to Site X), in which case it would be visible only to members of Group Z on Private Site X and not anywhere else on Site X or in the Network. Webmasters of Sites Y and Z obviously need a method to view all nodes which have been ‘shared’ by other Sites, and decide whether to publish them to their site. The only amendment to the general rules above might be that a node published in Site X (but not restricted to a Group) might automatically also be published to Private Site A (the private/community section of the parent/hub/international site).
1 High Very high 1
FR04_05 Vocabulary of types must be used for content classification.

1 High Low 1
















FR05 Page

1

1
FR05_01 It must be possible to create Pages. Pages may only be added and edited by Webmasters
1 Low Low 1








FR06 Article (Story)

1

1
FR06_01 Articles must be of at least one type defined by an articles vocabulary Articles may be added by any user, but their audience depends on user permissions
1 High Low 1
FR06_02 Articles must be able to be aggregated into 'issues' of a publication, and each issue of a publication must be able to carry identifiers such as volume/issue number and dateline.

1 Unknown Unknown 1
FR06_03 Articles must be able to be linked to an 'author' (not necessarily its creator) and this author must be linked to a contact record.
What does it mean “linked” ? 1 Medium Unknown 1








FR07 Calendar and Event

1

1

Events must be of at least one type defined by an events vocabulary Events may be added by any user, but their audience depends on user permissions
1 High Low 1

Events should automatically be added to the calendar of the group in which the event was created.

1



Events should by default automatically appear on the system wide calendar for the Extranet.
All events ? What about private events ? 1



Group administrator can hide events from their group calendar.
Why is this required ? 1



The event content type needs to be linked to an online system for managing participation in events.
Managing participation of events ... ??? Sounds like a complete set of functionality what none a word was mentioned here about it ! 1



Configurable online registrations forms will be needed for events.
Requires more details 1



Online registration needs to be intergrated with online payment systems.
Requires more details 1



Event administrators will need lists and other tools for managing participants.
Requires more details 1










FR08 Blog

1

1
FR08_01 Any user may have a personal blog, but its audience depends on user permissions

1 Medium Low
FR08_02 User must be able to define visibility scope of each blog

1 Medium High 1








FR09 Book

1


FR09_01 Book pages may only be added and edited by users with appropriate permissions













FR10 Forum

1


FR10_01 Access to Forums must be able to be restricted by group membership Forums will not be shared across domains or groups




FR10_02 Any user who can access a Forum must be able to subscribe to receive notification of new postings to that Forum













FR11 Projects and Project Issues

1


FR11_01 Projects will be accessible to appropriate groups, including one 'IofC web project' for all users to submit bug reports, track issues, and suggest functionality. Projects and Project Issue will not be shared across domains or groups. The Project functionality will build on Drupal's Project module, with comment and notification services, etc., but the functionality provided must offer, in a simple format:
1 Low Low 1
FR11_02 A work management system must be provided enabling allocation of specific tasks to team members, and tracking of these tasks through stages.

1 Low Low 1
FR11_03 To-do/task lists must be provided for groups and individuals.

1 Low Low 1








FR12 Feedback

1


FR12_01 Any visitor or user can contribute feedback on what they experience while visiting any site Feedback will not be shared across domains or groups
1 Low Medium 1
FR12_02 The handling of Feedback will be managed through a workflow Complaints are a type of feedback and will have their own workflow
1 Low Medium 1








FR13 Product
What about product ?



















FR14 Image Requirements relating to images is partly dependent on the image system we decide to implement, and therefore the following requirements may not all be met.
1


FR14_01 Images may be inserted into any other content.

1 High Medium 1
FR14_02 Users must be able to upload images to an image database via a web interface. The maximum image size allowed for upload by ordinary users will be 5MB. Administrators have no limitation. Uploaded images will be stored in three sizes: the size of the original
1 High High 1
FR14_03 Users must be able to upload images to an image database via an offline upload client. Images of only certain formats will be allowed to be uploaded.
2 Low High 1
FR14_04 Each uploaded image requires some data to be saved with it, including photographer name (for photos), a title and description, and the date of taking (if a photo).

1 High Medium 1
FR14_05 A captions system is required for images, allowing one image to have multiple captions in multiple languages.

1 Medium Medium 1
FR14_06 Images must be able to be organized into albums.

1 High High 1
FR14_07 Images must be categorized using keywords, organised into hierarchies.

1 High High 1
FR14_08 Users must be able to search for images by keyword, photographer, creation date, format, description/caption words, and other criteria.

1 High High 1








FR15 Comment (nb: not a node)

1


FR15_01 Each content type may be configured to allow comments to be added Comments will not be shared across domains or groups












FR16 Help

1


FR16_01 Help text and pages may be provided anywhere on the site. If help exists in a particular context it will appear in one of two ways. As a hyperlink from the word/phrase for which there is a help text. As a question mark in a consistent position which when clicked opens a box with the help text.
1 Low Low 1
FR16_02 Help content will be organized into a knowledgebase which resembles a book – a hierarchy of pages with sections and subsections.

1 Low Low 1
FR16_03 The help text administrators must be automatically notified of any site changes which may require a review of help texts.

1 Low Low 1
FR16_04 Users should be able to contribute to the help system.

1 Low Low 1








FR17 Menus

1


FR17_01 Each domain/website/group will have its own menu(s).

1 High Medium 1
FR17_02 Dynamic menu items must be allowed for. For example, a user may need to see a menu item 'My groups' which has sub items listing the names of Groups to which that user belongs, each menu item being a link to the homepage of the Group.
1 High Medium 1
FR17_03 Menus can only be administered by the webmaster role.

1 High Medium 1
FR17_04 Menus must be able to customised according to their position and environment. For example, some websites might have menus expanded, others not

1 High Medium 1
FR17_05 Theming of menus must allow for flyout menus.
Why flyout ? 1 Unknown Medium 1








FR18 Blocks

1

1
FR18_01 Blocks may only be administered by the webmaster role.




1
FR18_02 Blocks should be shareable across domains/sites




1








FR19 URLs

1

1
FR19_01 URLs should be stored in a table and be able to be inserted into content via appropriate syntax/statement.
I don't understand a reason for that. Drupal already has URLs in a simple forms


1
FR19_02 URLs may also be inserted into content by typing the full url.




1
FR19_03 Clean URLs' should be available for Pages and other content.




1
FR19_04 URL redirection is required, allowing aliasing of URLs.




1







1
FR20 File Management This package defines file uploads and storage.
1

1
FR20_01 Only certain file types will be allowed for upload.




1
FR20_02 All files must be scanned for viruses at the time of being uploaded. If a virus is found, the file must be rejected with a notification to the uploader and to an administrator.




1
FR20_03 Uploaded files must be able to be designated as 'Public' (accessible directly) or 'Private' (accessible only from the server).




1
FR20_04 Access to files must be able to be restricted by group membership.





FR20_05 Nodes and comments may have a files attached to them depending on the node type and preferences of the content owner and admins – but only the owner of a node may attach a file.




1
FR20_06 A proper document management system must be implemented to allow easy administration and presentation of uploaded files.
Define all requirements for “document management system” . What should it be able to perform ?


1
FR20_07 When a file is uploaded and attached to content that is related to a group, then an email notification will be sent to that group admin as well.




1







1
FR21 Search engine This package provides search functionality throughout the site.
1

1
FR21_01 For each domain/site, the search engine must search all (and only) content for which the visitor/user has access rights.




1
FR21_02 A search must look for the search term(s) within title, summary (teaser/intro), body, author name – and other fields to be determined.




1
FR21_03 Advanced searching is available only to authenticated users.




1
FR21_04 Search results must be presented in a format easily configurable by administrators, and sorted according to criteria to be determined.




1







1
FR22 Notification services This package defines the configuration of all notification services within the site.
1

1
FR22_01 It must be possible for email notification messages to be triggered by various actions on the sites.
Define these actions ?


1
FR22_02 Notification messages must be able to include a link to the page related to the notice.




1
FR22_03 Notification messages must be able to sent to more than one email address, for example to the author of a content item as well as an administrator.



1
FR22_04 Some content areas of the site should be able to offer visitors or users the option to subscribe to receive notification when new content is added.




1
FR22_05 Such notification messages should include a link to unsubscribe from future notifications – or another easy method of unsubscribing should be offered.




1
FR22_06 RSS feeds must be available and easily configurable for various sites and content types.




1







1
FR23 Email lists This package covers how email lists are provided and managed.
1

1
FR23_01 The solution should use a standard Mail List Manager for bounce processing, moderation, and other email list functionality.




1
FR23_02 The MLM must offer good multi-lingual functionality for template strings.




1
FR23_03 The solution must utilise the unique email addresses within the site-wide CRM system.




1
FR23_04 A subscriber to an email list must be able to unsubscribe from any email list easily. An unsubscription link should be included in each email sent to the list.




1
FR23_05 Email lists may be 'public' (open to subscription on public websites), 'restricted' (open to users but not visitors) or 'private' (available only to members of a group and/or via administrator subscription).




1
FR23_06 The existence of a list must only be visible to those with appropriate access permission.




1
FR23_07 A member of a restricted or private email list must be able to view the names of others subscribed to that list.




1
FR23_08 There must be an easy way for a user to review on one page those email lists available to him/her, and subscribe/unsubscribe as they wish.




1
FR23_09 When an email address is added to any email list by an administrator, an email message should be sent to that email address with a request for confirmation that the person wishes to subscribe to the list.




1
FR23_10 Email list membership and Group membership must be able to be synchronised. i.e. It must be possible for someone subscribing to an email list also to join the related Group, and vice versa.




1







1
FR24 Contact relationship management This package covers the management of contact relationship data in all its forms.
1

1
FR24_01 The solution must provide a flexible and secure method for storing and managing contact records. A contact record may relate to an organisation rather than an individual.



1
FR24_02 Contact records must be able to be linked to users records.




1
FR24_03 A user record must have a linked contact record, but a contact record need not have a linked user record.




1
FR24_04 The system must enable duplicate records to be easily found, and for safely deleting a duplicate.
maybe just avoid duplicate appearance ?


1
FR24_05 Most 'user' profile information should be stored with the contact record, so that data such as bio, photo, etc, can be used by the system even if the contact record has no linked user record.




1
FR24_06





1
FR24_07 Contact records must be able to be linked to one another (so that for example a married couple's records could be associated, and the employees of a company could be associated with that company, etc.)




1
FR24_08 It should be possible for linked contact records to share some address data. in CiviCRM there is the concept of 'household' which achieves this.



1
FR24_09 The visibility of contact record information must be limited to those who have permission to view/use it.




1
FR24_10 User contact information/profile will by default be visible to other users, but a user may control which parts of their information are hidden from other users.




1
FR24_11 Contact records not linked to a user will only be visible (via searching) to those users belonging to a group or role authorised to view the record.




1
FR24_12 Every contact record must be assigned to one, and only one, 'Data Controller', which will by default be the Data Controller role under which the user is creating the record.




1
FR24_13 When a new contact record is created by someone who is not acting in the role of a particular 'Data Controller', it will be assigned to a temporary 'Interim Data Controller' pending assignment to the appropriate Data Controller.




1
FR24_14 A contact record may only be edited by its assigned 'Data Controller' or by the linked user.




1
FR24_15 When a new contact record is created, an email should be generated to the email address of the record being added, detailing the data being added, and the purpose for which it is being added, and inviting confirmation of the accuracy of this action.




1
FR24_16 Admins and data-controllers must be able to filter records to extract a subset.




1
FR24_17 These subsets must be able to be displayed in various formats and printed to PDF.




1
FR24_18 Contact records must be able to be linked to nodes – initially to Articles (for authors, see FR06_03), and eventually probably to events (for event management) and other content types.




1
FR24_19 Records must be easily searchable.




1








FR25 Users This package covers functionality relating to the users of the system.
1

1
FR25_01 Users are required to undergo a registration process.




1
FR25_02 All users must agree to our terms and conditions.




1
FR25_03 Upon registering, a user by default becomes a Basic User, and therefore has the option to apply to become an Advanced User.




1
FR25_04 The submission of the registration form needs to use the Captcha or similar verification system.




1
FR25_05 The content of the registration form may vary depending on the context in which it is being submitted.




1
FR25_06 The registration form must allow entry of a special registration code which would authorise additional actions after submission, e.g. Immediate enrolling as an Advanced User.




1
FR25_07 The process of applying to become an Advanced User requires giving the name of a reference person. A notification system will be used.




1
FR25_08 Users who forget their login or password details must have an automated way of requesting a reminder, or password reset.




1
FR25_09 User activity must be logged and accessible to appropriate site administrators.




1
FR25_10 Users will be able to join groups within which they will be able to assume roles that give them permissions specific to that group (see FR02).




1
FR25_11 Users must be identified throughout the site by their full name, not by their user id.




1







1
FR26 Workflow This package describes the process of managing stages in the finalising of certain types of content.
1

1
FR26_01 A workflow is specific to a particular type of content.




1
FR26_02 Groups may have their own workflows for the same content types.




1
FR26_03 Dependent on the configuration of the workflow, users will be given a choice to advance a content item to the next stage of its completion whilst the item is either being created or edited.




1
FR26_04 Email notifications are used to inform appropriate users of a content items transition to a new stage.




1







1
FR27 E-commerce This package provides e-commerce to the system.
1

1
FR27_01 An online payments system must be provided to allow any visitor/user to purchase products or make donations.
The details of the online purchasing system will conform to the typical e-commerce requirements of small organisations – with final details yet to be defined.


1
FR27_02 The page/s where credit card information is entered must be secure.




1
FR27_03 The 'product' content type defines what will be available for sale.




1
FR27_04 A product must be able to be linked to another node. For example an event might have tickets for sale as products.



1
FR27_06 There must be a method for purchasers of digital products to download them after payment.




1
FR27_07 Any group must be able to offer products for sale or to invite donations.
How to invite donations?


1
FR27_08 An administrative interface must be provided for managing donor relationships effectively.
What does it mean “effectively” ?


1








Contact Relationship Management

FR001 Package Name Contact Relationship Management  
Details This package covers the management of contact relationship data in all its forms.  
Status Phase Version  
Proposed 1 1  
FR001_01 To support the high-level objectives of IofC’s global communications strategy: to embed the critical elements of personal transformation, forgiveness and remade relationships into the accepted thinking of policy-makers, academics and practitioners of peace-building and development; to equip, support and strengthen the network of regional and initiative-based IofC communities… giving cohesion to this movement for regional and global transformation.
FR001_02 To project a professional, consistent image of IofC into the public arena.
FR001_03 To support the personal relationship-building work of IofC activists with people in international organisations and peace-building institutions.
FR001_04 To support the development of the global network of IofC and help build a spirit of community.
FR001_05 To provide a method for offering a public web presence, and an intranet, for multiple IofC national bodies and projects.
FR001_06 To serve the global data management and marketing needs of IofC.
FR001_07 To maximise the sharing of informational resources across the global IofC network.
FR001_08 To provide a solid, easily managed, infrastructure to serve the web needs of IofC for at least the next 5-10 years.

NF - Non-Functional Requirements

Non-functional requirements can be broken down in to the following 2nd level packages:
  1. Business requirements These requirements describe needs of the IofC organization which are not directly linked to any particular functions of the solution but describe a business objective which must be achieved as a result of the system being developed.

  2. User Interface Requirements User interface requirements described how we would the solution to interact with the users of the system.

  3. Hardware Requirements Hardware requirements describe the hardware which will be available to be utilised by the application in order to achieve the solution objectives. This type of requirements is very closely related to the performance requirements.

  4. Software Requirements Software Requirements describe the various software needs of the solution such as operating system, browsers to be used, protocols, third parts software etc…

  5. Performance Requirements Performance requirements describe the expectations that the customer has in terms of how the solution will perform under specified conditions.

  6. Security requirements Security Requirements defines system access levels and data protection requirements. Desired security expectations should be described at both hardware (net topology, firewalls etc.) and software (checks, constraints, validations etc) levels.

BR-Business requirements

BR01

Package Name

Overall business requirements

Details

This package contains business requirements, answering the question 'Why does this project exist?'

Status

Phase

Version

Proposed

1.0

1.0

BR01_01

To support the high-level objectives of IofC’s global communications strategy:

  1. to embed the critical elements of personal transformation, forgiveness and remade relationships into the accepted thinking of policy-makers, academics and practitioners of peace-building and development;
  2. to equip, support and strengthen the network of regional and initiative-based IofC communities… giving cohesion to this movement for regional and global transformation.

BR01_02

To project a professional, consistent image of IofC into the public arena.

BR01_03

To support the personal relationship-building work of IofC activists with people in international organisations and peace-building institutions.

BR01_04

To support the development of the global network of IofC and help build a spirit of community.

BR01_05

To provide a method for offering a public web presence, and an intranet, for multiple IofC national bodies and projects.

BR01_06

To serve the global data management and marketing needs of IofC.

BR01_07

To maximise the sharing of informational resources across the global IofC network.

BR01_08

To provide a solid, easily managed, infrastructure to serve the web needs of IofC for at least the next 5-10 years. The decision to move into Drupal was taken because we considered the sustainability of our web projects to be more assured by building on an Open Source platform supported by a worldwide community of developers, with agreed coding standards, better security features, and with out-of-the-box functionality which would take much programming work to provide. The Drupal framework is also likely to move with the leading edge of web development in the years ahead.

HR–Hardware Requirements

Number HR1_001 Status
Approved
Title Server specifications Priority Hgh
Details

The solution must use our present web server ('Atlas') -

 

  • CPU: 2 (shared) cores (3.2GHz Xeon)
  • Memory: 1GB
  • Disk: 20GB
  • Bandwidth: a 10 Mbit/s uplink, up to about 1Mbit/s sustained traffic

 

Difficulty Low
Version 1.0
Phase 1.0

Number HR1_002 Status
Unknown
Title Upgrading options
Priority Unknown
Details The server specifications in regard to memory, disk capacity and bandwidth will be upgraded once the volume of traffic warrants it. Difficulty Unknown
Version 1.0
Phase 1.0

PR-Performance Requirements

Number PR1_001 Status Approved
Title Number of visitors Priority Hgh
Details We anticipate that the total daily number of visitors to the IofC sites will not exceed 25,000 in the forseeable future. Difficulty Low
Version 1.0
Phase 1.0


Number PR1_002 Status Unknown
Title Logged in users Priority Unknown
Details We anticipate that the total number of authenticated users will not exceed 10,000 in the forseeable future. Concurrent logged in users will not exceed 500. Difficulty Unknown
Version 1.0
Phase 1.0


Number PR1_003 Status Unknown
Title Server response times Priority Unknown
Details The typical response time for a browser request should not exceed 5 seconds. Difficulty Unknown
Version 1.0
Phase 1.0


Number PR1_004 Status Unknown
Title Bandwidth Priority Unknown
Details The applications should be designed with web users in Africa and Asia in mind, so graphics should be kept to a minimum. Difficulty Unknown
Version 1.0
Phase 1.0


Number PR1_005 Status Unknown
Title Availability of sites Priority Unknown
Details All sites, including log in sites, should be available 24/7. Difficulty Unknown
Version 1.0
Phase 1.0

SR-Software requirements

The solutions we develop often interact with one or more software elements on the client’s environment. Often these interactions constrain the way in which we can develop the solution or at least will guide the designers in design the best solution according to the scope of interaction with other software.

Number SR1_001 Status
Approved
Title Solution core - Drupal CMS Priority Hgh
Details Overall solution must be based on “Drupal” Content Management System. www.drupal.org

Version 6.0 of Drupal CMS must be used.

Difficulty Low
Version 1.0
Phase 1.0

Number SR1_002 Status
Unknown
Title Server environment
Priority Unknown
Details Solution must run on IofC web server 'Atlas'.
Difficulty Unknown
Version 1.0
Phase 1.0

Number SR1_003 Status
Unknown
Title Browsers to be supported
Priority Unknown
Details Application must be compatible with different browsers (IE 6 >, Firefox 2.0 >, Safari). Difficulty Unknown
Version 1.0
Phase 1.0

Number SR1_004 Status
Unknown
Title Programming language
Priority Unknown
Details Application should use the PHP programming language (Drupal default)
Difficulty Unknown
Version 1.0
Phase 1.0

Number SR1_005 Status
Unknown
Title Database software
Priority Unknown
Details Application should use MySQL databases (Drupal default) - IofC webserver allows as many as we need. Difficulty Unknown
Version 1.0
Phase 1.0

Number SR1_006 Status
Unknown
Title Coding standards Priority Unknown
Details Solution should use Drupal's coding standards.
Difficulty Unknown
Version 1.0
Phase 1.0

Number SR1_007 Status
Unknown
Title Post deployment support
Priority Unknown
Details The solution will be supported by IofC's web team after deployment. Difficulty Unknown
Version 1.0
Phase 1.0

Number SR1_008 Status
Unknown
Title Data exporting
Priority Unknown
Details Solution must support CSV exporting, and output of PDFs on the fly. Difficulty Unknown
Version 1.0
Phase 1.0

Number SR1_009 Status
Unknown
Title Audio and video codecs
Priority Unknown
Details

Audio and video codecs must not be encumbered by patents, and must not have DRM in them. Ogg/Vorbis and Ogg/Theora are prefered choices, with plugins and/or viewers available for many platforms.

Difficulty Unknown
Version 1.0
Phase 1.0

UR–User Interface Requirements

Number UR1_001 Status Approved
Title Required interface Priority Hgh
Details End user requires only a web-based interface. Difficulty Low
Version 1.0
Phase 1.0


Number UR1_002 Status Unknown
Title Branding and colour Priority Unknown
Details The branding and colour schemes should be the same as those currently deployed at www.iofc.org Difficulty Unknown
Version 1.0
Phase 1.0


Number UR1_003 Status Unknown
Title Plug ins Priority Unknown
Details Media which require additional browser plug ins, such as Flash animations, should generally not be used. Difficulty Unknown
Version 1.0
Phase 1.0


Number UR1_004 Status Unknown
Title Monitor resolutions Priority Unknown
Details The solution should cater for 800 x 600 and higher resolution. Difficulty Unknown
Version 1.0
Phase 1.0


Number UR1_005 Status Unknown
Title Web page widths Priority Unknown
Details

Public websites should be fixed width (770). Log in websites should be fluid width. The user should not be required to use horizontal scrolling bars for primary content.

Difficulty Unknown
Version 1.0
Phase 1.0


Number UR1_006 Status Unknown
Title Accessibility standards Priority Unknown
Details Web pages should meet the checkpoints of the Web Accessibility Initiative's Web Content Accessibility Guidelines to Level-A standards as well as Levels AA and AAA where possible. Difficulty Unknown
Version 1.0
Phase 1.0


Number UR1_007 Status Unknown
Title Multilingual requirements Priority Unknown
Details Both interface and content must be fully multilingual, including support for RTL scripts. Difficulty Unknown
Version 1.0
Phase 1.0

XR-Security Requirements

Number XR1_001 Status Approved
Title Type of solution Priority Hgh
Details It will be both an Internet application which provides public information, and an Intranet Web application. Difficulty Low
Version 1.0
Phase 1.0


Number XR1_002 Status Unknown
Title Level of data sensitivity Priority Unknown
Details Secret or highly sensitive material will not be stored on the websites, but security of user contact information needs to be ensured, to conform with data protection legislation. Difficulty Unknown
Version 1.0
Phase 1.0


Number XR1_003 Status Unknown
Title Authentication methods Priority Unknown
Details To be determined Difficulty Unknown
Version 1.0
Phase 1.0


Number XR1_004 Status Unknown
Title Password levels and logins Priority Unknown
Details A medium-level of password strength should be enforced. After 5 incorrect login attempts a user should be blocked and the administrator informed by email. All login attempts, whether successful or unsucessful should be logged. Difficulty Unknown
Version 1.0
Phase 1.0


Number XR1_005 Status Unknown
Title Session method and options Priority Unknown
Details To be determined Difficulty Unknown
Version 1.0
Phase 1.0


Number XR1_006 Status Unknown
Title SSL Priority Unknown
Details SSL should be used for all financial transactions. (This is already in place on our server.) Difficulty Unknown
Version 1.0
Phase 1.0

Evaluating Modules

This section is devoted to evaluating and cross-referencing modules which could be useful for us.

A spreadsheet of Drupal 6 modules we need, with their status, is at http://spreadsheets.google.com/ccc?key=pXTE_gZaA_mF12GVI4e9Vcw

Advanced contact

This simple module adds functionality to the core module Contact. Its main function is to allow the passing of parameters in the url to specify the category and/or subject of the email transmitted by the default contact form. This is useful if you have several categories and want to save the visitor having to choose the right one from the drop down list.

After installing the module, there is no configuration to do, and the module does not appear in the Admin section.

I found little documentation of how to use it, but something brief at http://drupal.org/node/131568.

Example of usage might be;

http://www.kanariefaglarna.com/?q=contact&category=Test&subject=Book%20O...

Autosave

This module makes it possible for a node being created/edited to be autosaved every x seconds. This would be very useful for users who might lose work if their computer crashes or some other unexpected happening occurs.

A JQuery plug in has to be downloaded, renamed (.txt removed), and placed in the module folder. To configure after installation, go to Content Types and choose the Autosave tab, and choose which types to apply it to, and how many milliseconds (1000 milliseconds in a second!) between autosaves.

http://drupal.org/project/autosave 

Content Access and ACL

The Content Access module (http://drupal.org/project/content_access) enables you to limit view/edit/delete permissions by content type, and also by individual nodes.

If the ACL module (http://drupal.org/project/acl) is also enabled, you can limit view/edit/delete to particular users.

Fontsize

This module (http://drupal.org/project/fontsize) provides a block with links to increase and decrease the font size using JavaScript and CSS. See an example at http://nten.org/newsletter

Masquerade

This handy module allows anyone with requisite permission to 'masquerade' as another user. This is really useful for Admins who need to troubleshoot problems reported by a user, and need to simulate the user's environment.

It is easy to configure. On the configuration page you can optionally specify a specific user to whom to switch easily via a Menu item 'Switch to test user', which would then need to be placed in the Admin menu. This could be useful if you have a bogus user configured with certain permissions, and you want to see what this role actually sees.

Once configured, Admin can go to a user's profile and click on the Masquerade link to switch to that user. Once masquerading, there is a link to switch back to the original user. But beware, you have set up this menu link BEFORE you masquerade! You will find it in the Menu but need to place it correctly.

Note also that while masquerading, any content you add will be shown as having been added by that user.

Watchdog logs all switches.

http://drupal.org/project/masquerade

Multidomain

General Info:

The module page is here: http://drupal.org/project/multidomain
The author's blog is here: http://www.bryght.com/blog/adrian/multidomain-module-for-drupal-5

The author alluded to future OGDomains and UserDomains modules (which would be useful to this project). But the statement was made in December 2006 and the modules are not yet implemented.

I will not yet pronounce at this stage about whether it is good or not for us.

Installation

- I am running Debian Linux.
- Made a clean install of Drupal.
- Enabled clean URLs, made my status report to give me no warnings.
- Enabled more themes.
- Configured the Apache Server to point drupal.test and one.drupal.test to the same Drupal installation directory.
- Installed the module.
- The module requires single signon module. It can be found here: http://drupal.org/node/50418. So I installed this too.
- The module needs to apply a patch. The patch is provided. To apply the patch I opened a terminal window, browsed to the Drupal directory and executed patch -p0 < modules/multidomain/multidomain_alias.patch

Configuration
Administer->Site Configuration->Multiple Domains

- Set the default domain to drupal.test.
- In the 'Content filtering by domain' setting chose 'All: all domains, including the default see their own content'.
- Added one.drupal.test domain.
- This module created a Vocabulary called domain. The domains I added where added to the vocabulary.
- Set the Domain Vocabulary to allow multiple selects.
- When creating the two domains, I've indicated that the Domain Vocabulary can apply to both of my only content types: page and story.
- Set marvin (different from default garland) theme for one.drupal.test domain.

Testing

- Added three stories: one assigned to both domains, and each of the other two assigned to one different domain. Both sites displayed the right set of stories.

Node Clone

This module allows you to clone a node and then edit it. After installation, you can configure permissions, and then when editing a node there is a Clone tab.

It seems to work well for basic content types, but the documentation at http://drupal.org/project/node_clone warns that it may cause problems with complicated types using a lot of CCK fields.

Profile/contact record module solutions

Getting one's head around a solution for our CRM requirements has not been easy. We have investigated the Nodeprofile family, but documentation is sparse, and it takes some understanding.

In brief: the Bio module is too limited, so we need Node Profile. The way it works is that the Usernode module has the effect of binding user data (which is not a node) to the node system by creating a node of content type 'usernode'. This is an empty node which does nothing much by itself, but allows you to attach nodes of other content types to a user. It also ensures that if a user is deleted, all nodes bound to the usernode are deleted.

  • Nodeprofile (with Nodefamily) allow us to create additional content types and link them to the usernode in a parent/child relationship.
  • One or more profile nodes can be put on the registration form.
  • It is possible to allow users to make certain fields private via the Node Privacy module.
  • CCK fields on the profile forms can be restricted via the CCK Field Permissions module.

We have to accept that all our contact records will have to have linked users, even if they are inactive/blocked. It would be very messy if we had separate content types for contact records which are not linked to users, as we could not merge the two contact record types in views, etc, and also it would be complex when a non-user contact becomes a user.

Some other points:

  • For an administrator to create a new contact record, he has to use the create user form. This allows the creation of new profile etc, which is not allowed if you try to create content of the profile type.
  • Through Usernode, if we delete a user, all the linked profile nodes are also deleted. But if we delete part of the profile (data of one content type) only that node is deleted.
  • Automatic Node Titles is good for hiding the title of a content type and automatically naming it based on tokens.
  • Pageroute allows us to set up good step-throughs of profile forms, and of linked admin nodes. So, for example, each ‘data user’ group will have its own content type (e.g. UK data user) and CAN (does not have to) have a node with data storing to a contact’s relationship to that data user (e.g. whether he receives a newsletter, or whatever) – and a custom pageroute can be provided for the datauser to go from the profile to an admin page.
  • Views Fusion is very good for building combined views.
  • Login Toboggan module is good for directing a registering user to a thank you page after registering.
Please add to this page any points you have!

Subscriptions

This module enables users to subscribe to be notified of changes to nodes or taxonomies, such as new comments in specific forums, or additions to some category of blog. Once enabled, all nodes will have an additional link that allows the user to change their subscriptions. Users have tab on their user screen to manage their own subscriptions. Users can also set an auto subscribe function which notifies the user if anyone comments on posts they have made. Admins can set this on by default.

This module offers what we have at present allowing users to subscribe when new message in a forum, but with more control/management features, and with any content able to be subscribed to.

http://drupal.org/project/subscriptions

Tasklist and Tasklist Advanced

These two modules taken together provide powerful tools for managing tasks. They may meet and exceed our requirements in relation to the replacment of our old Work Management System (WMS). (Though one or two features of our system are missing, like the statuses 'Back to Work', or 'Test'.

Tasklist (http://drupal.org/project/task) gives simple functionality: You can assign a task to a user, filter by complete/incomplete, colour code tasks for users, etc.

The Tasklist Advanced module (http://drupal.org/project/tasks_advanced) extends the existing Tasklist module, and adds categorization, additional views, and filtering based on "Getting Things Done" by David Allen. For attaching dates to tasks, use the Event module.

Features

(In addition to all of Tasklist's features)

  • Additional views
    • my tasks
    • all tasks, grouped by user
  • Categorization based on "Getting Things Done" by David Allen
  • Form or URL based filtering by
    Note: for advanced URL based filtering try this approach: tasks/user/1?status=1&taskcategory=unknown,next&tasktype=action
  • Status
  • Category
  • Task type
  • Tagging of tasks as action (default) or project (multi-action task)
  • Hierarchical tree listing

specify a task as a Project or an Action, and you can date it if you add in the Date module.

 

There is a module called Todolist which is development which might be worth exploring too. 

Taxonomy Node Operations

This module dds the ability to assign terms to nodes in the node operations dropdown in Content Management >> Content. It makes it easy to assign a taxonomy term to a number of nodes at the same time. There is no help file available, and the module once installed does not show up in the Administer by Module list, but if you go to the Node admin page, the 'Update Options' drop down includes options for assigning to terms.

http://drupal.org/project/taxonomy_node_operations 

TinyMCE

Install the main Drupal module first, then the separate TinyMCE files into new tinymce subdirectory.

For a detailed explanation of how to configure it all, see http://mybesinformatik.com/tinymce-and-drupal5

Be aware that if you are deploying this module on a multilingual website, you may need to change the Visibility settings. Typically you choose the option to show tinymce "on only the listed pages:" "/node/* /user/* /comment/*". However, now there might be an /en/ or /fr./ in front of the /node/, because of the internationalisation, these settings would need to read "*node/* *user/* *comment/*" instead. 

Web File Manager

This file manager is based on a heirarchical directory structure unlike the traditional flat filesystem used to date. WebFM uses AJAX to allow administrators to arrange files on the server in the same way they do with file managers on their personal systems. This ability to hierarchically arrange files improves the manageability of large collections of documents.

A demo is available at http://vera-ikona.com/webfm

Download the module at http://drupal.org/project/webfm 

Use Case List

We created a great list of use cases.

Guidelines for writing Use Cases

Use cases give us a structured way of capturing the behavioral requirements of a system, so that we can reasonably create a design from them. They help us to answer some fundamental questions:
What are the users of the system trying to do? What’s the user experience? A surprising amount of what your software does is dictated by the way in which users must interact with it.

Why Do We Need Use Cases in Addition to Functional Requirements?
Functional specifications are important, of course. But designing, coding, or estimating directly from a functional spec is like playing an enthralling game of “pick a random number.”
We need to do some exploratory work to even out the playing field. Use case modeling and preliminary design after it, gets us there.

The principles of writing use cases can be summed up as a list of guidelines.
1. Follow the two-paragraph rule.
2. Organize your use cases with actors and use case diagrams.
3. Write your use cases in active voice.
4. Write your use case using an event/response flow, describing both sides of the user/system dialogue.
5. Use GUI prototypes and screen mock-ups.
6. Remember that your use case is really a runtime behavior specification.
7. Write the use case in the context of the object model.
8. Write your use cases using a noun-verb-noun sentence structure.
9. Reference domain classes by name.
10. Reference boundary classes (e.g., screens) by name
A use case is often triggered by a user-initiated event that the system has to respond to. However, it can also be triggered by a system-initiated event to which the user responds. But in
either case, the use case follows the event/response flow.
So a use case really describes a dialogue between a user and the system. You need to write about the user side of the dialogue to keep your behavior requirements firmly user-focused, but it’s not sufficient to just write down what the user does, because ultimately you’re trying to spec software, and software really consists of the system’s behavior. So it’s vitally important to describe both sides of the dialogue between the user and the system in every use case.
Quite often, the user is reacting to a system action, so the use case starts with “The system displays the XYZ screen (showing ZZZ information),” and then the user does something in response. The main benefit of starting your use case with "The system displays..." is that the system showing something on the screen involves initialization behavior (getting ZZZ information from somewhere) that is often forgotten otherwise.

First a bad one use case; The capability is provided for users to log in, using a password-protected authorization
scheme.

Here goes a simple, good one example.

The system displays the Login screen. The user enters her username and password, and
then clicks the Login button. The system looks up the user profile using the username
and checks the password. The system then logs in the user.

Remember this is the basic course—the sunny-day scenario that assumes everything goes correctly. There would also be an alternate course describing what happens if the username or password weren’t found.

Or another one ..

The user clicks the Edit Shopping Cart button, and the system shows the Edit Shopping
Cart page with a list of books in the user’s shopping cart. The user selects one of the
books, changes the quantity, and clicks the Update button. The system shows the page
with the quantities and price totals updated.

Site Structures

General Use Cases for our site structure.

Definition of our multisite requirements

MULTISITE REQUIREMENTS

  • A substantial number (40+) of websites, each of which MAY have either or both
    • A ‘public’ site for ‘anonymous’ users
    • A ‘private’ site for ‘authenticated’ users
  • Each website needs to have its own domain or subdomain.
  • Each website to be, optionally, multilingual. This includes all image captions as well.
  • Each website to have its own administration, including control over theme, user roles, menus and other module configurations.
  • Main content (nodes, images, user data, possibly also blocks) can be made available or shared (where the creator permits) to all sites but with each site retaining complete control at the individual site level over what appears on each.
  • Universal ‘authenticated’ users able to log into all websites, and once logged in to move freely between sites without new login request.
  • User data (contact info, biodata, etc) integrated fully, but with full security.
  • Within any given website, a group system allowing establishment of multiple groups with own group content and networking tools and controlled content sharing between groups.

[The following was added to this document by Edward on 14/11/2007, after agreement with team members, for transmission to stakeholders for comment.]

Proposals for the new 'architecture':

  • The IofC family of websites will consist of multiple public sites EACH of which CAN have additional private section(s) for the needs of activists from that particular network. For example, the UK public site might have a UK extranet with additional content restricted to the logged-in person. The F4F public site might have an F4F extranet... etc.
  • Each extranet would in effect be a different site with a different look and feel, but the content in it would INCLUDE all content on the related public site.
  • What we currently call the 'Extranet' will become the private extension of the Global website, and called the 'Global Extranet'.
  • Those IofC teams which do not need/want a public website, can have a team/group section inside an extranet - either the global one, or another, as appropriate. If in due course such a team wants to have a public site, it can move out of its parent extranet.
  • A 'Global Extranet member' will have access to ALL extranets without separate registration/log in.
  • Content on any extranet can (as at present) be restricted to only certain members.
  • Webmastering of a site will be more intuitive than in our present system.
  • The webmaster will log in to their site and be able to edit any page by navigating to the desired page, make changes, and review those changes before making them live.
  • Much content will be shareable across sites, but not in the way we have at present through shared 'fixed blocks'. 'Dynamic' content such as articles, documents, etc, will be sharable across sites.

Research on Multiple sites in Drupal -- remaining questions.

Dear Pavel,

Located one level up in this online book is a definition of our site requirements regarding multiple site functionality. By 'multisite functionality' I specifically mean having different domains and subdomains; the infrastructure to acheive that is an entirely separate matter.

The purpose of this memo is give you some background on the research that's been done to discern how closely Drupal comes to what we need. This research is incomplete and is intended to give you a solid footing as you begin to look at this more complex use case.

___________________

There are 3 pathways forward which we have been researching.

These have been narrowed down to the latter two options, given that the Multisite Manager module can not acheive our use case on its own. It is possible that Multisite Manager and OG_sites can be made to work together I suppose, but I see no immediate advantage to doing that.

You may be entirely familiar with these, but here they are again. The modules we are talking about are found below:

User Group Structures

We have groups.

Data Display and Theming

We display stuff.

Files and Attachments

We attach things to things.

User Roles and Permissions

Users need roles and permissions.

Content Creation and Sharing

We create things and share them between groups and sites.

Domain modelling

Here we gather documentation relating to our domain model.

A document describing our domain model using the metaphor of an indoor shopping centre is attached to this node

Definition of terms

DOMAIN MODEL: Definition of terms


Note: the terms defined in this document are not necessarily the terms which will be used to present the concepts to the ‘consumers’ – they are for the benefit of the technical team.

Principal domain objects and their definition

Domain
a combination of the public website (all content visible to any visitor) and a private area with additional content and functionality accessible only to logged in users.

Universe
the totality of all domains in the IofC family of domains.
Global website the public website of IofC International (iofc.org).

Extranet
the private area of iofc.org, accessible to all IofC users.

Hub domain
the global website and extranet, which forms the hub of a family of related websites.

Related domain
A sub-domain of iofc.org serving an IofC national body, outreach programme or other related entity, which has a public website and a private area (site intranet), and which can share content with other IofC sites.

Site intranet
the private area of a related domain, accessible to all IofC users.

Group
A collection of users within a domain who collaborate towards a particular objective, and which can have its own site area (group intranet), private content, email lists, forums, etc.

Group intranet
an area or group space within the extranet or a site intranet which serves the needs of the group. (Note: this group intranet may be completely private to the group, or parts of it may be accessible to non group members. Clarification: if a group with a group intranet develops a need for its own public website, a new related domain is created and the group moves with its content to this new domain, becoming the principle group of that domain.)

Resource
a piece of content which becomes accessible depending on the domain and role(s) to which it is assigned. (Important clarification: contact records are both users AND resources in the sense that contact data may be administered/used/viewed by users with permission to do so.)

 

General user objects

Public visitor
someone who visits a public website without logging in ('anonymous user' in Drupal terminology, but NOT a user in our terminology – see next item)

Basic user
someone who has logged in to any domain with whatever level of privilege (Drupal's  ‘authenticated user’ role). The two membership types that follow both have this role and add additional permissions.

Site member
a user who has limited access to the extranet or a site intranet. (Note: a site member is given membership without moderation)

Network Member
a user who has full access to all content which is not private to a group. (Note: this role requires moderation) Only full users would be able to join and administer groups. A full user is allowed to create new content of particular content types, e.g. ‘News’.

 

Domain roles

(Note: for each role below there will also be a ‘chief’ administrator with all-domain responsibility, supporting each domain-specific administrator.)

Webmaster
a user who has primary responsibility for public and restricted resources on a site. This role requires domain-specific permissions for:

  • site building: domain blocks, menus, themes, url aliases, views
  • content management, including administering nodes

Administrator
a user with administration privileges. This role requires domain-specific permissions for:

  • site building: modules
  • user management
  • site configuration
  • logs

Super Administrator
a user who has access to everything and can administer everything

Groups administrator
a user who administers the formation and support of groups (limited to administering the ‘groups’ content type and the configuration of groups)

Email administrator
a user who administers email lists

Events administrator
a user who administers events (limited to administering the ‘events’ content type and the configuration of some views)

Forums administrator
a user who administers forums (limited to administering the ‘forums’ content type and the configuration of forums)

Translations administrator
a user who administers translations

 

Primary group administration roles

Group member
a user who is a member of a group

Group administrator
a user who administers all aspects of a group, including membership

Group webmaster
a user who administers the pages/content of the group’s intranet

 

Roles in special contact data administration groups

Group data controller
a user with full administration rights for those contact records belonging to the group. (Note: every contact record will be belong to one and only one group for the purposes of exercising ‘data protection’ responsibilities in relation to that data subject.)

Group data user
a user with permission to use for mailing purposes (but not change) those contact records for which the group has ‘use’ permission.

 

Resource access terms

Public
visible to visitors

Restricted
visible to users only. (Note: restricted will be further sub-defined to restricted basic and restricted full for the two general user roles of our universe.)

Private
visible to members of a group. (Clarification: if a resource is publicthere would no point in also classifying it as restricted. But there will be times when a piece of content is public or restricted but is also classified as private. The effect of this would be for this content to be visible to non group members, but it would place the content additionally inside a group intranet.)

 

Other terms

Audience
those persons (whether visitors to a public website, a general user role, or a defined group of users) which may view content.

Contact record
a set of data relating to a person or organisation (data subject), including contact information like name, address, etc, and also including user data such as username and password. (Note: all contact records will have user data even if the person is not an active user of the system.)

Group data viewer a user with permission to view contact records for which the group has ‘view’ permission. (Clarification: any group member will be able to view contact data relating to other group members. But a group member may not necessarily have ‘view’ permission for all contact data which belongs to the group or for which the group has use permission.)

Image database
a repository of images, with each image storing data relating to it (including captions, sometimes in multiple languages), and categorised with keywords.

Workflow
a defined set of stages through which a type of content flows until it is completed

The Plan

This section details the overall plan for the entire project. It breaks down into sections for each stage of the plan, and these naturally have their own steps which should be followed in a well thought out logic order. These sections are as follows:

Data Migration

We migrated.

Setup -- Stored Procedures on Install

Here are the stored procedures which run when the iofc_migration module is first installed. These aggregate all of the old data into nice and neat tables for the import scripts to plug into the Drupal forms.

 

Setup Taxonomy -- SP

CREATE DEFINER=`root`@`localhost` PROCEDURE `setup_taxonomy`(IN pid tinyint(3))
BEGIN



# TAXONOMY -- This creates the temporary tables needed for the running of the migration -- these are a place where the data for Taxonomy is altered and mapped into new fields with some intricacy.



# if this is an install then ... setup tables

IF pid=1 THEN



DROP TABLE IF EXISTS `set_vocabulary`;



CREATE TABLE `set_vocabulary` (

`vid` int(10) unsigned NOT NULL auto_increment,

`name` varchar(255) NOT NULL default '',

`description` longtext,

`help` varchar(255) NOT NULL default '',

`relations` tinyint(3) unsigned NOT NULL default '0',

`hierarchy` tinyint(3) unsigned NOT NULL default '0',

`multiple` tinyint(3) unsigned NOT NULL default '0',

`required` tinyint(3) unsigned NOT NULL default '0',

`tags` tinyint(3) unsigned NOT NULL default '0',

`module` varchar(255) NOT NULL default '',

`weight` tinyint(4) NOT NULL default '0',

PRIMARY KEY (`vid`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;





DROP TABLE IF EXISTS `set_term_data`;



CREATE TABLE `set_term_data` (

`tid` int(10) unsigned NOT NULL auto_increment,

`vid` int(10) unsigned NOT NULL default '0',

`name` varchar(255) NOT NULL default '',

`description` longtext,

`weight` tinyint(4) default '0',

`old_infocat_id` int(9) unsigned default NULL,

`old_infopath` varchar(255) default NULL,

`old_oppstype_id` int(9) unsigned default NULL,

`old_oppscat_id` int(9) unsigned default NULL,

`old_meta_id` int(9) unsigned default NULL,

PRIMARY KEY (`tid`),

KEY `vid` (`vid`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;





DROP TABLE IF EXISTS `set_term_hierarchy`;



CREATE TABLE `set_term_hierarchy` (

`tid` int(10) unsigned NOT NULL default '0',

`parent` int(10) unsigned NOT NULL default '0',

PRIMARY KEY (`tid`,`parent`),

KEY `tid` (`tid`),

KEY `parent` (`parent`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;





DROP TABLE IF EXISTS `set_term_relation`;



CREATE TABLE `set_term_relation` (

`tid1` int(10) unsigned NOT NULL default '0',

`tid2` int(10) unsigned NOT NULL default '0',

KEY `tid1` (`tid1`),

KEY `tid2` (`tid2`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;



#_____________________________________________________



# setup VOCABULARIES



insert into set_vocabulary

(set_vocabulary.name,

set_vocabulary.description,

set_vocabulary.help,

set_vocabulary.relations,

set_vocabulary.hierarchy,

set_vocabulary.multiple,

set_vocabulary.required,

set_vocabulary.tags,

set_vocabulary.module,

set_vocabulary.weight)

SELECT 'Article Category' as `name`, 'The type of story being posted' as `description`, 'vocabulary' as `help`, '1' as `relationships`, '' as `hierarchy`, '' as `multiple`, '1' as `required`, '' as `tags`, 'taxonomy' as `module`, '' as `weight`

UNION

SELECT 'Publication Category' as `name`, 'The type of publication.' as `description`, 'vocabulary' as `help`, '1' as `relationships`, '' as `hierarchy`, '' as `multiple`, '1' as `required`, '' as `tags`, 'taxonomy' as `module`, '' as `weight`

UNION

SELECT 'Issue' as `name`, 'A list of volumes and issues.' as `description`, 'vocabulary' as `help`, '1' as `relationships`, '' as `hierarchy`, '' as `multiple`, '1' as `required`, '' as `tags`, 'taxonomy' as `module`, '' as `weight`

UNION

SELECT 'To Do What' as `name`, 'To do?' as `description`, 'vocabulary' as `help`, '1' as `relationships`, '' as `hierarchy`, '' as `multiple`, '1' as `required`, '' as `tags`, 'taxonomy' as `module`, '0' as `weight`

UNION

SELECT 'At What' as `name`, 'Top level tag for Opps Category Tags' as `description`, 'vocabulary' as `help`, '1' as `relationships`, '' as `hierarchy`, '' as `multiple`, '1' as `required`, '' as `tags`, 'taxonomy' as `module`, '1' as `weight`

UNION

SELECT 'How' as `name`, 'Top level tag for Opps Type Tags' as `description`, 'vocabulary' as `help`, '1' as `relationships`, '' as `hierarchy`, '' as `multiple`, '1' as `required`, '' as `tags`, 'taxonomy' as `module`, '2' as `weight`

UNION

SELECT 'Keywords' as `name`, 'Top level tag for FAC meta tags' as `description`, 'vocabulary' as `help`, '1' as `relationships`, '' as `hierarchy`, '' as `multiple`, '1' as `required`, '' as `tags`, 'taxonomy' as `module`, '' as `weight`;







#_____________________________________________________



# setup the variables for the Vocabulary ID



SELECT `vid` FROM `iofc1`.`set_vocabulary` WHERE `name` LIKE 'Article Category' INTO @vidarticle;

SELECT `vid` FROM `iofc1`.`set_vocabulary` WHERE `name` LIKE 'Keywords' INTO @vidkeyword;

SELECT `vid` FROM `iofc1`.`set_vocabulary` WHERE `name` LIKE 'To Do What' INTO @vidtodo;

SELECT `vid` FROM `iofc1`.`set_vocabulary` WHERE `name` LIKE 'At What' INTO @vidatwhat;

SELECT `vid` FROM `iofc1`.`set_vocabulary` WHERE `name` LIKE 'How' INTO @vidhow;







#_____________________________________________________



insert into

set_term_data

(set_term_data.vid,

set_term_data.name,

set_term_data.description,

set_term_data.weight,

set_term_data.old_infocat_id,

set_term_data.old_infopath,

set_term_data.old_oppstype_id,

set_term_data.old_oppscat_id,

set_term_data.old_meta_id

)

SELECT @vidarticle as `vid`, `interimglobal`.`infocats`.`name` AS `name`,'' AS `description`, '0' AS `weight`,`interimglobal`.`infocats`.`id` AS `old_infocat_id`, concat_ws('','withauthor <',`interimglobal`.`infocats`.`withauthor`,'>, feedback <', `interimglobal`.`infocats`.`feedback`,'>, path <',`interimglobal`.`infocats`.`path`,'>') as `old_infopath`, null,null, null

FROM `interimglobal`.`infocats`

UNION

SELECT @vidkeyword as `vid`, `interimglobal`.`metatags`.`TagsDesc` as `name`, '' as `description`, '0' as `weight`, null, null, null, null, `interimglobal`.`metatags`.`MetaTagID` as `old_meta_id`

FROM

`interimglobal`.`metatags`

UNION

SELECT @vidtodo, 'Attend' as `name`, 'Just be present.' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidtodo, 'Volunteer' as `name`, 'Get involved and help out.' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidtodo, 'Participate' as `name`, 'Join into the action.' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidtodo, 'Contribute' as `name`, 'Support the work.' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidtodo, 'Apply' as `name`, 'Take the first step.' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidatwhat, 'Meeting' as `name`, 'General meeting of a team or group of any kind' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidatwhat, 'Conference' as `name`, 'A larger gathering which normally lasts for several days' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidatwhat, 'Workshop' as `name`, 'Focussed interactive training in practical skills.' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidatwhat, 'Course' as `name`, 'Training which covers a curriculum.' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidatwhat, 'Seminair' as `name`, 'Training sessions which each deal with particular subject' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidatwhat, 'Lecture' as `name`, 'A speaker presenting a paper.' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidatwhat, 'Screening' as `name`, 'The presenting of time-based artwork.' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidatwhat, 'Project' as `name`, 'Doing something with a beginning, middle and end.' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidatwhat, 'Consultation' as `name`, 'An informal conference which brings the leadership together with the membership.' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidatwhat, 'Gathering' as `name`, 'A very informal meeting with little or no agenda.' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidatwhat, 'Performance' as `name`, 'Presenting a work of Performing Arts (dance, theatre, music, etc.)' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidatwhat, 'Reception' as `name`, 'The welcoming of something or someone.' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidatwhat, 'Dialogue' as `name`, 'The meeting of two or more parties seeking agreement.' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidatwhat, 'Program' as `name`, 'An organised set of goals to acheive an outcome.' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidatwhat, 'Employment' as `name`, 'Paid Remuneration' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidatwhat, 'Campaign' as `name`, 'Working toward specific social goals.' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidatwhat, 'Celebration' as `name`, 'The formal recognition of acheivement.' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidatwhat, 'Memorial Service' as `name`, 'Upon the passing away of someone.' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidhow, 'Free Admittance' as `name`, 'At no cost.' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidhow, 'Registration Fee' as `name`, 'A registration fee must be paid.' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidhow, 'Registration Only' as `name`, 'Registration only -- no fee required.' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidhow, 'Application' as `name`, 'An application form is available.' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidhow, 'General Volunteering' as `name`, 'An opportunity to volunteer in general volunteer roles' as `description`, '0' as `weight`, null, null,null,null, null

UNION

SELECT @vidhow, 'Internship' as `name`, 'An application form available for this internship.' as `description`, '0' as `weight`, null, null,null,null, null;





ELSE IF pid=0 THEN





DROP TABLE IF EXISTS `set_vocabulary`;



DROP TABLE IF EXISTS `set_term_data`;



DROP TABLE IF EXISTS `set_term_hierarchy`;



DROP TABLE IF EXISTS `set_term_relation`;



END IF;

END IF;



END;

Setup Users and Contacts - SP

CREATE SP>>>

Setup Infos - SP

CREATE SP >>>

SELECT statements

This section regards the sources of our data in the migration. It makes sense to create this documentation to see where our data is coming from, so that we can more easily see the complexities which may exist in bringing these sources into Drupal.

To review the history of our migration prior to going Drupal, please have a look at the attached sql file, at the stored procedures therein. These might help you understand why a flattened database makes way more sense!!!

Country SELECT Statement

The very first step in migration is for the Country data to be setup. There is a special CCK address field for handling countries. Please look at the modules for helping with this so that each country can also build clean relations to states/provinces as well. This enables good validation on addresses. Anyway, it all starts with Countries.

Take a look at the cck_address module:

http://drupal.org/project/cck_address

and for other countries support:

http://drupal.org/project/cck_address_extensions

As you can see from this, I am suggesting we use an existing set of countries which comes with Drupal modules, and to link to our country fields using the country name. There may be some matching of names for us to do, but that should only take a few minutes.

 

Taxonomy SELECT statements

Given the nature of the relational data sources, there will be various SELECT statements to pull together the various Taxonomies of the old system scattered in different tables. A number of these statements will be generating the vocabularies from scratch.

 

There are three things which need defining in Drupal's database -- the vocabularies, the content types associated with these, and then the tags (vocabulary terms).

1. A content type is, for example, News.

2. Each vocabulary can have multiple content types associated with it so that it appears under News, Events, and Blogs. Normally each will only be associated with one content type.

3. Each vocabulary can have multiple tags/terms.

4. Tags/terms can exist in freetag hierarchies, if freetagging is enabled under that vocabulary.

 

_____________________

1. Create Vocabularies. There is at least one vocabulary, and one term, to go with every node content type.

 

# generate new fields (in pairs, delete first) -- vocabulary only

none to create for vocabularies -- see terms.

 

# add rows to vocabulary table

######### name, description, help, relations, hierarchy, multiple, required, tags, module, weight

 

SELECT 'Article Category' as `name`, 'The type of story being posted' as `description`, 'vocabulary' as `help`, '1' as `relationships`, '' as `hierarchy`, '' as `multiple`, '1' as `required`, '' as `tags`, 'taxonomy' as `module`, '' as `weight`

UNION

SELECT 'People Category' as `name`, 'People categories for the type life story.'
as `description`, 'vocabulary' as `help`, '1' as `relationships`, '' as
`hierarchy`, '' as `multiple`, '1' as `required`, '' as `tags`,
'taxonomy' as `module`, '' as `weight`

UNION

SELECT 'History Category' as `name`, 'Various types of histories.'
as `description`, 'vocabulary' as `help`, '1' as `relationships`, '' as
`hierarchy`, '' as `multiple`, '1' as `required`, '' as `tags`,
'taxonomy' as `module`, '' as `weight`

UNION

SELECT 'Publication Category' as `name`, 'The type of publication.'
as `description`, 'vocabulary' as `help`, '1' as `relationships`, '' as
`hierarchy`, '' as `multiple`, '1' as `required`, '' as `tags`,
'taxonomy' as `module`, '' as `weight`

UNION

SELECT 'Issue' as `name`, 'A list of volumes and issues.'
as `description`, 'vocabulary' as `help`, '1' as `relationships`, '' as
`hierarchy`, '' as `multiple`, '1' as `required`, '' as `tags`,
'taxonomy' as `module`, '' as `weight`

UNION

SELECT 'Feedback' as `name`, 'The type of Feedback being sent'
as `description`, 'vocabulary' as `help`, '1' as `relationships`, '' as
`hierarchy`, '' as `multiple`, '1' as `required`, '' as `tags`,
'taxonomy' as `module`, '' as `weight`

UNION

SELECT 'To Do What' as `name`, 'To do?' as `description`, 'vocabulary' as `help`, '1' as `relationships`, '' as `hierarchy`, ''
as `multiple`, '1' as `required`, '' as `tags`, 'taxonomy' as `module`,
'0' as `weight`

UNION

SELECT 'At What' as `name`, 'Top level tag for Opps Category Tags' as `description`, 'vocabulary' as `help`, '1' as `relationships`, '' as `hierarchy`, ''
as `multiple`, '1' as `required`, '' as `tags`, 'taxonomy' as `module`,
'1' as `weight`

UNION

SELECT 'How' as `name`, 'Top level tag for Opps Type Tags' as `description`, 'vocabulary' as `help`, '1' as `relationships`, '' as `hierarchy`, ''
as `multiple`, '1' as `required`, '' as `tags`, 'taxonomy' as `module`,
'2' as `weight`

UNION

SELECT 'Keywords' as `name`, 'Top level tag for FAC meta tags' as `description`, 'vocabulary' as `help`, '1' as `relationships`, '' as `hierarchy`, ''
as `multiple`, '1' as `required`, '' as `tags`, 'taxonomy' as `module`,
'' as `weight`

UNION

SELECT 'Links Categories' as `name`, 'The categories under which url links appear' as
`description`, 'vocabulary' as `help`, '1' as `relationships`, '' as
`hierarchy`, ''
as `multiple`, '1' as `required`, '' as `tags`, 'taxonomy' as `module`,
'' as `weight` ;

 

 

_____________________

-- May be possible in PHP script's select fields above 2. Link Vocabularies to Content Types

# update vocabulary_node to link vocabs to content types

 

 

 

 

_____________________

3. Create Terms -- at least one term per vocabulary.

 

# generate new fields (in pairs, delete first) - term only

 

ALTER TABLE `iofc1`.`term_data` DROP `old_infocat_id`;

ALTER TABLE `iofc1`.`term_data` ADD `old_infocat_id` INT( 9 ) UNSIGNED NULL ;

 

ALTER TABLE `iofc1`.`term_data` DROP `old_people_id`;

ALTER TABLE `iofc1`.`term_data` ADD `old_people_id` INT( 9 ) UNSIGNED NULL ;

 

ALTER TABLE `iofc1`.`term_data` DROP `old_history_id`;

ALTER TABLE `iofc1`.`term_data` ADD `old_history_id` INT( 9 ) UNSIGNED NULL ;

 

ALTER TABLE `iofc1`.`term_data` DROP `old_issue_id`;

ALTER TABLE `iofc1`.`term_data` ADD `old_issue_id` INT( 9 ) UNSIGNED NULL ;

 

ALTER TABLE `iofc1`.`term_data` DROP `old_feedback_id`;

ALTER TABLE `iofc1`.`term_data` ADD `old_feedback_id` INT( 9 ) UNSIGNED NULL ;

 

ALTER TABLE `iofc1`.`term_data` DROP `old_oppscat_id`;

ALTER TABLE `iofc1`.`term_data` ADD `old_oppscat_id` INT( 9 ) UNSIGNED NULL ;

 

ALTER TABLE `iofc1`.`term_data` DROP `old_meta_id`;

ALTER TABLE `iofc1`.`term_data` ADD `old_meta_id` INT( 9 ) UNSIGNED NULL ;

 

ALTER TABLE `iofc1`.`term_data` DROP `old_link_id`;

ALTER TABLE `iofc1`.`term_data` ADD `old_link_id` INT( 9 ) UNSIGNED NULL ;

 

 

 

# select infocats

 

SELECT `iofc1`.`vid` FROM `iofc1`.`vocabulary` WHERE `name` LIKE 'Article Category' INTO @vidarticle;

SELECT `iofc1`.`vid` FROM `iofc1`.`vocabulary` WHERE `name` LIKE 'History Category' INTO @vidhistory;

SELECT `iofc1`.`vid` FROM `iofc1`.`vocabulary` WHERE `name` LIKE 'Publication Category' INTO @vidpub;

SELECT `iofc1`.`vid` FROM `iofc1`.`vocabulary` WHERE `name` LIKE 'Issue' INTO @vidissue;

SELECT `iofc1`.`vid` FROM `iofc1`.`vocabulary` WHERE `name` LIKE 'Feedback Category' INTO @vidfeedback;

SELECT `iofc1`.`vid` FROM `iofc1`.`vocabulary` WHERE `name` LIKE 'To Do What' INTO @vidtodo;

SELECT `iofc1`.`vid` FROM `iofc1`.`vocabulary` WHERE `name` LIKE 'At What' INTO @vidatwhat;

SELECT `iofc1`.`vid` FROM `iofc1`.`vocabulary` WHERE `name` LIKE 'How' INTO @vidhow;

SELECT `iofc1`.`vid` FROM `iofc1`.`vocabulary` WHERE `name` LIKE 'Keywords' INTO @vidkeyword;

 

SELECT

@vidarticle,

`interimglobal`.`infocats`.`id` AS `infocatsid`,
`interimglobal`.`infocats`.`name` AS `infocatsname`,
concat_ws('','withauthor <',`interimglobal`.`infocats`.`withauthor`,'>, feedback <', `interimglobal`.`infocats`.`feedback`,'>, path <',`interimglobal`.`infocats`.`path`,'>')

FROM `interimglobal`.`infocats`;

 

# update the inserted record in the term_data table

UPDATE `iofc1`.`term_data` SET `old_infocat_id`=`infocatsid`

 

 

# select the terms for each vocabulary.

# event opportunity type

SELECT @vidtodo, 'Attend' as `name`, 'Just be present.' as
`description`,
'0' as `weight`

UNION

SELECT @vidtodo, 'Volunteer' as `name`, 'Get involved and help out.' as
`description`,
'0' as `weight`

UNION

SELECT @vidtodo, 'Participate' as `name`, 'Join into the action.' as
`description`,
'0' as `weight`

UNION

SELECT @vidtodo, 'Contribute' as `name`, 'Support the work.' as
`description`,
'0' as `weight`

UNION

SELECT @vidtodo, 'Apply' as `name`, 'Take the first step.' as
`description`,
'0' as `weight`

UNION

SELECT @vidatwhat, 'Meeting' as `name`, 'General meeting of a team or group of any kind' as
`description`,
'0' as `weight`

UNION

SELECT @vidatwhat, 'Conference' as `name`, 'A larger gathering which normally lasts for several days' as
`description`,
'0' as `weight`

UNION

SELECT @vidatwhat, 'Workshop' as `name`, 'Focussed interactive training in practical skills.' as
`description`,
'0' as `weight`

UNION

SELECT @vidatwhat, 'Course' as `name`, 'Training which covers a curriculum.' as
`description`,
'0' as `weight`

UNION

SELECT @vidatwhat, 'Seminair' as `name`, 'Training sessions which each deal with particular subject' as
`description`,
'0' as `weight`

UNION

SELECT @vidatwhat, 'Lecture' as `name`, 'A speaker presenting a paper.' as
`description`,
'0' as `weight`

UNION

SELECT @vidatwhat, 'Screening' as `name`, 'The presenting of time-based artwork.' as
`description`,
'0' as `weight`

UNION

SELECT @vidatwhat, 'Project' as `name`, 'Doing something with a beginning, middle and end.' as
`description`,
'0' as `weight`

UNION

SELECT @vidatwhat, 'Consultation' as `name`, 'An informal conference which brings the leadership together with the membership.' as
`description`,
'0' as `weight`

UNION

SELECT @vidatwhat, 'Gathering' as `name`, 'A very informal meeting with little or no agenda.' as
`description`,
'0' as `weight`

UNION

SELECT @vidatwhat, 'Performance' as `name`, 'Presenting a work of Performing Arts (dance, theatre, music, etc.)' as
`description`,
'0' as `weight`

UNION

SELECT @vidatwhat, 'Reception' as `name`, 'The welcoming of something or someone.' as
`description`,
'0' as `weight`

UNION

SELECT @vidatwhat, 'Dialogue' as `name`, 'The meeting of two or more parties seeking agreement.' as
`description`,
'0' as `weight`

UNION

SELECT @vidatwhat, 'Program' as `name`, 'An organised set of goals to acheive an outcome.' as
`description`,
'0' as `weight`

UNION

SELECT @vidatwhat, 'Employment' as `name`, 'Paid Remuneration' as
`description`,
'0' as `weight`

UNION

SELECT @vidatwhat, 'Campaign' as `name`, 'Working toward specific social goals.' as
`description`,
'0' as `weight`

UNION

SELECT @vidatwhat, 'Celebration' as `name`, 'The formal recognition of acheivement.' as
`description`,
'0' as `weight`

UNION

SELECT @vidatwhat, 'Memorial Service' as `name`, 'Upon the passing away of someone.' as
`description`,
'0' as `weight`

UNION

SELECT @vidhow, 'Free Admittance' as `name`, 'At no cost.' as
`description`,
'0' as `weight`

UNION

SELECT @vidhow, 'Registration Fee' as `name`, 'A registration fee must be paid.' as
`description`,
'0' as `weight`

UNION

SELECT @vidhow, 'Registration Only' as `name`, 'Registration only -- no fee required.' as `description`,
'0' as `weight`

UNION

SELECT @vidhow, 'Application' as `name`, 'An application form is available.' as
`description`,
'0' as `weight`

UNION

SELECT @vidhow, 'General Volunteering' as `name`, 'An opportunity to volunteer in general volunteer roles' as
`description`,
'0' as `weight`

UNION

SELECT @vidhow, 'Full-time Volunteer Position' as `name`, 'Proposals are welcome from those living their true vocation.' as
`description`,
'0' as `weight`

UNION

SELECT @vidhow, 'Internship' as `name`, 'An application form available for this internship.' as
`description`,
'0' as `weight` ;

 

# Update the above saving the old opportunity cat id to correspond appropriately.

 

 

 

 

# select opps categories

 

SELECT
`interimglobal`.`opportunitycats`.`id`,

`interimglobal`.`opportunitycats`.`name`,

@vocab1

FROM
`interimglobal`.`opportunitycats`;

 

# insert opps types

SELECT
`interimglobal`.`opportunitytypes`.`id`,

`interimglobal`.`opportunitytypes`.`name`,

`interimglobal`.`opportunitytypes`.`path`,

@vocab1

FROM
`interimglobal`.`opportunitytypes`;

# select people categories

SELECT
`interimglobal`.`people_categories`.`id`,
`interimglobal`.`people_categories`.`name`,
`interimglobal`.`people_categories`.`path`

FROM
`interimglobal`.`people_categories`;

 

#

# retreave the vid for the FAC vocabulary

SELECT `drupal???`.`name` FROM `drupal???` WHERE `name`='For A Change' INTO @vocab2;

 

 

 

______________________

 

4. Term Hierarchies -- Free-Tagging relationships between Terms.

 

 

# select metatags

SELECT distinct
`interimglobal`.`metatags`.`MetaTagID`,
`interimglobal`.`metatags`.`TagsDesc`
FROM
`interimglobal`.`metatags`;

 

 

# select tag hierarchys

SELECT distinct
`interimglobal`.`parenttag`.`id` as `parent_id`,
`interimglobal`.`childtag`.`id` as `child_id`
FROM
`interimglobal`.`treelink`
Left Join `iofc_content`.`res_tags` AS `childtag` ON
`childtag`.`old_fac_meta_id` = `interimglobal`.`treelink`.`MetaTagID`
Left Join `iofc_content`.`res_tags` AS `parenttag` ON
`parenttag`.`old_fac_meta_id` = `interimglobal`.`treelink`.`ParentTagID`
WHERE
((`childtag`.`id` is not null) and (`parenttag`.`id` is not null));

 

 

Contact and User SELECT Statement

This SELECT statement gathers all information about a single contact in our system. This includes all user and CRM data. This also includes all email list addresses. It represents a significant flattening of the extIC database.

 

SELECT
c.contactinfoID AS contactid,
c.FirstName AS firstname,
c.LastName AS lastname,
c.Public AS public,
c.createdby AS createdby,
c.createdate AS createdate,
c.title AS title,
c.initials AS initials,
c.suffix AS suffix,
c.`position` AS `position`,
c.organisation AS organisation,
c.spouse AS spouse,
c.salutation AS salutation,
c.refpersonID AS ref_id,
usr.userid AS user_id,
usr.userpwd AS `password`,
usr.lastsuss AS lastsuss,
usr.JoinDate AS joindate,
usr.VisitLog AS lastvisit,
usr.refBy AS refperson,
e.Email AS email,
e.ePrivate AS e_private,
e.modifiedby AS e_modifiedby,
e.modifydate AS e_modifydate,
phome.IDDCode AS h_iddcode,
phome.AreaCode AS h_area,
phome.PhoneNo AS h_phone,
phome.pPrivate AS h_private,
poffice.IDDCode AS o_iddcode,
poffice.AreaCode AS o_area,
poffice.PhoneNo AS o_phone,
poffice.pPrivate AS o_private,
pmobile.IDDCode AS m_iddcode,
pmobile.AreaCode AS m_area,
pmobile.PhoneNo AS m_phone,
pmobile.pPrivate AS m_private,
pfax.IDDCode AS f_iddcode,
pfax.AreaCode AS f_area,
pfax.PhoneNo AS f_phone,
pfax.pPrivate AS f_private,
a1.street1 AS a1_st1,
a1.street2 AS a1_st2,
a1.street3 AS a1_st3,
a1.city AS a1_city,
a1.state AS a1_state,
a1.zipcode AS a1_zip,
a1.aPrivate AS a1_private,
country1.countryID AS a1_country_id,
region1.name AS a1_regionname,
a2.street1 AS a2_st1,
a2.street2 AS a2_st2,
a2.street3 AS a2_st3,
a2.city AS a2_city,
a2.state AS a2_state,
a2.zipcode AS a2_zip,
a2.aPrivate AS a2_private,
country2.countryID AS a2_country_id,
region2.name AS a2_regionname,
url.URL AS website,
url.External AS web_external,
url.LanguageID AS web_lang_id,
bioimage.width AS image_width,
concat_ws('','http://photos.iofc.org/storage/images/fullsize/',image.filename) AS image_path,
bioshort.lang_id AS bioshort_lang_id,
bioshort.content AS bioshort,
biolong.lang_id AS biolong_lang_id,
biolong.content AS biolong
FROM
extIC.contacts AS c
Left Join extIC.users AS usr ON usr.contactID = c.contactinfoID
Left Join extIC.address AS a1 ON a1.AddressID = c.Address1ID
Left Join extIC.country AS country1 ON country1.countryID = a1.countryID
Left Join extIC.countryregions AS region1 ON region1.id = country1.regionID
Left Join extIC.address AS a2 ON a2.AddressID = c.Address2ID
Left Join extIC.country AS country2 ON country2.countryID = a2.countryID
Left Join extIC.countryregions AS region2 ON region2.id = country2.regionID
Left Join extIC.biodata AS bioshort ON bioshort.contact_id = c.contactinfoID AND bioshort.biotype_id = 1

Left Join extIC.biodata AS biolong ON biolong.contact_id = c.contactinfoID AND biolong.biotype_id = 2

Left Join extIC.bioimages AS bioimage ON bioimage.contact_id = c.contactinfoID
Left Join photos.images AS image ON image.id = bioimage.image_id
Left Join extIC.email AS e ON e.EmailID = c.EmailID
Left Join extIC.phone AS phome ON phome.PhoneID = c.HomePhoneID
Left Join extIC.phone AS poffice ON poffice.PhoneID = c.OfficePhoneID
Left Join extIC.phone AS pmobile ON pmobile.PhoneID = c.MobilePhoneID
Left Join extIC.phone AS pfax ON pfax.PhoneID = c.FaxID
Left Join interimglobal.urlsbank AS url ON url.URLsBankID = c.urlID

 

You can test this statement by adding:
WHERE
c.contactinfoID = 489

Info SELECT Statements

These are the SELECT statements which grab all records from interimglobal.infos

There may only be one, but will probably need others to complete the relations to Taxonomy and Pages.

 

SELECT
info.id,
info.lang_id,
info.contact_id,
info.title,
info.intro,
info.body,
info.postdate,
info.visible,
info.metakeywords
FROM
info

 

 

Events SELECT Statement

This is a complimentary migration to interimglobal.infos. It has a slightly different set of fields coming from a slightly different table.

 

Groups SELECT Statements - Including Datacontrol groups

This is for what we call 'orgunits' and 'datacontrolers' in the old system -- Groups in Drupal. There is the main data of a group, and then there is extended data as well, for example, 'datacontrol' data. These statements therefore deal with groups and who is in them, with extended group roles for tracking who is in a group for data control reasons only.  Really this is just about who is in a group because they are sharing their data with that group for some reason, and so someone in the group needs to be responsible. Anyway, these SELECT's draw up this data fabulously. 

 

Email List SELECT statements

These are the SELECT statements used for migrating the email list system.

 

 

Migration briefs

Spreadsheet documents are now on GoogleDocs. Text docs are in the sections below.

Remember that the [sequences] table has been abolished in Drupal 6, and that auto increment is now used. 

A key to the migration process is to store relevant old IDs from [extIC] and [interimglobal] in the appropriate Drupal tables, to allow us to keep data sets related to each other through each part of the migration process. Therefore all, or almost all, content types will be prepared to include extra temporary fields to store the old contact_id, old_orgunit_id and/or other important IDs, for use in further migration tasks, and the relevant fields must be imported in each import procedure described below.

It is also preferable, before doing the migration, to start with an installation where revisions have not been turned on for any content types, so that [nid] and [vid] values are identical throughout the database structure. This can save a lot of hassle. Revision can be turned on later for those content types which require it.

 

Contact records, users and groups

The briefs in this section cover migration of data relating to our contact database, Extranet users, groups and their members/admins, etc.

 

Contact data by Data Users

Friends News

Migrate into Contact Data (FN) from db_wprods_contact.

For each row in [datacontrol] with OrgUnitID64:

  • if 'privilege'=1, write nid from [content_type_contactdata_fn] to og_ancestry with group_nid=1400
  • if 'privilege'=0, write nid from [content_type_contactdata_fn] to og_ancestry with group_nid=1416
  • in both cases, is_public=0

Contact database

Contact record data from extIC has to be migrated into four content types: person_profile, organization_profile, contact_profile, biodata. Each of these content types will be prepared to include an extra temporary field to store the contact_id for use in further migration tasks, and must be imported in each import run. Special note: the same field(name) [old_contact_id] could be used for each of these content types, but that would have the effect of breaking this field out into a new table [content_field_old_contact_id]. Our various SQL scripts will be easier to run if we keep this old contact id inside the content type's own table, so I am naming this id differently for each of the four content types. See first item in brackets under each content type below.

Person profile

(extIC.contactid = old_contact_id)

CSV file needs to include all relevant fields, for all records from contacts except for those which are organisations, as identified by firstname and lastname fields being empty. One additional field (‘nodetitle’) should be created by concatenating lastname and firstname.This will be written in as the title of the new nodes. Eventually, this field will be an auto nodetitle field generating lastname-firstname automatically from the user input.

Simple SQL already used:

“select contactinfoID,lastname,firstname,email,title,initials,suffix,salutation,spouse, refpersonID, organisation,position,concat(firstname,' ',lastname) as nodetitle from contacts,email where contacts.EmailID=email.EmailID and lastname<>""

 

An SQL update will be run for all rows in the [content_type_profile] table to update the node reference field with the nid of the related row in the [content_type_person_profile] table, using the old contact_id which is stored in both tables.

SQL: "update content_type_person_profile, content_type_profile set content_type_profile.field_person_profile_reference_nid=content_type_person_profile.nid
where field_old_profile_contact_id_value=field_old_contactid_value"

Organization profile

(extIC.contactid = old_org_contact_id)

Same as person profile, except that only three fields are needed from extIC: [organisation], [email] and [contactinfoid]

Contact profile

(extIC.contactid = old_address_contact_id)

CSV needs to supply following fields:

  • all in extIC.address except for addressid and aprivate. Country should be the countryID as in that table.
  • email address
  • all four phone numbers - home, mobile, work and fax
  • urlID (from contacts table)
  • contactinfoID

Biodata

(extIC.contactid = old_bio_contact_id)

Final updates

The Node Family module provides the nid link between person_profile—contact_profile—biodata, and organisation_profile—contact_profile. Therefore we will need three SQL inserts to be run once Node Family is ready for D6:

  1. An insert for each row in the [content_type_person_profile] table to insert a row into the [node_family] table with the nid from the [content_type_person_profile] table and the nid from the related row in the [content_type_contact_profile] table, using the old contact_id which is stored in both tables.
  2. An insert for each row in the [content_type_organization] table to insert a row into the [node_family] table with the nid from the [content_type_organization] table and the nid from the related row in the [content_type_contact_profile] table, using the old contact_id which is stored in both tables.
  3. An insert for each row in the [content_type_biodata] table (there will not be a bio for each person) to insert a row into the [node_family] table with the nid from the [content_type_biodata] table and the nid from the related row in the [content_type_person_profile] table, using the old contact_id which is stored in both tables.

Data user information

Several tables in extIC prefixed with ‘db_’ contact data which needs to be migrated into new content types, one for each data user group. Each of these content types will be related to the person_profile and organisation_profile content types through the Node Relativity module.

Migration will be achieved by using the Node Import module and then using the old contact_id to run SQLs to insert rows into the [relativity] table.

Data in [extIC.db_uk_common] needs special handling, as some of it needs to go into [content_type_person_profile] and some of it needs to go into one or more of the data user content types. I suggest that we create a temporary content type to store all this data, imported by Node Import, and then run SQLs to update the required tables. This will need careful mapping in advance.

 

Datacontrol information

Note: this section needs reviewing when OG is ready for D6.

The [extIC.datacontrol] table does not need to be imported but will be used to run two SQLs to connect person_profiles and organisation_profiles to datacontrol and datauser groups:

  1. The first SQL inserts a row into the [og_ancestry] table for each row in [extIC.datacontrol] where [privilege]=1. It takes the [nid] in [content_type_address] (this table chosen because it ‘should’ have a row for every old contact_id) related to [extIC.datacontrol.contactinfoID] and the corresponding [nid] in [content_type_datacontrol] related to the [extIC.datacontrol.OrgUnitID].
  2. The second SQL inserts a row into the [og_ancestry] table for each row in [extIC.datacontrol] where [privilege]=0. It takes the [nid] in [content_type_address] related to [extIC.datacontrol.contactinfoID] and the corresponding [nid] in [content_type_datauser] related to the [extIC.datacontrol.OrgUnitID].

In both SQLs, [og_ancestry.is_public] is set to 0.

 

Group administrators

Note: this will have to wait until the OG User Roles module is available.

Data in [extIC.orgunitadmins] will be used to write the correct values to the [og_users_roles] table.

 

Group members

Note: this needs reviewing after OG for D6 available.

The [extIC.orgunitmembers] table will be used to write the correct values into the [og_uid] table. But more thought is need first because of the different ways in which ‘orgunit’ is conceived – in some cases as a way of collecting people (og members in Drupal) and in some cases as a way of aggregating resources (e.g. a list of IC members). This means that not all rows in [orgunitmembers] have corresponding rows in [users], so we will have to migrate the data more carefully.

On further review (2/7), I think this will have to be done entirely - or mainly - manually, as there is no obvious way to automate it.

Groups

 

Note: this section is based on table structure for D5 and will have be reviewed once OG for D6 is available.

The Node Import module will be used to import all rows in the [extIC.orgunits] table. They will be imported into the following content types (each of which is of the ‘group’ type, has an old_orgunit_id field in it):

  1. Data control (content_type_datacontrol) – those orgunits which are data controllers (see document ‘orgunits_migration.ods’)
  2. Group (content_type_group) – other orgunits

After import, the names of these groups will have to be changed to align with the naming convention for our groups (designed to allow aggregation of group content in Views through filtering by group names).

The Intro data will have to be stored temporarily, as it will have to be written later into a new table created by the Panels module. We will use Panels to create the group homepage. 

Each group of content type data control needs a new group to be created of content type data user. An SQL insert will be run to do this.

 

Users

The Content Profile module provides the means of linking a user to the node system. When a user is created, a node of type profile will be created with the uid of the linked user. This node will contain a node reference to the node id of the linked person profile which stores the main profile information about a user.

Our custom Migration module will import data from [extIC.users] and [ extIC.email] – username, password, email, and also the old contact_id which will be written to a temporary extra field in the users table so as to keep a reference to data in nodes which are part of the contact record system.

 

Issues/Newsletters -> Editions

The new content type Periodical will store the names of the three different magazines referenced in [intermglobal.issues], plus the 25 newsletter types in [extIC.newslettertypes]. Then we migrate data from [issues] and [extIC.newsletters] into the Edition content type.

ISSUES

There are only three different magazines (Periodicals) in that table, represented by three webuser ids. If we import that webuser id with each issue, we can use it to update the node reference to the Periodical, and can then use this to assign to the correct OG audience.

The CSV file for this import just needs all the original fields from the [issues] table.

I tried this and all OK (apart from error, solved by http://drupal.org/node/192211).

STEPS

1) Import csv file

2) Run PHP script to update language for each node

$sql="SELECT nid,shortname FROM content_type_edition as p,language_extic as l where p.field_old_issue_lang_id_value=l.LanguageID";
$query = db_query($sql);
while ($object = db_fetch_object($query))
{
$sql2="UPDATE node SET language='$object->shortname'
WHERE nid='$object->nid'";
$query2 = db_query($sql2);
echo $object->nid."--".$object->shortname."\n" ;
}

3) Run SQL to insert periodical nid into node reference field, three times with different values

update content_type_edition SET content_type_edition.field_periodical_reference_nid=329
where field_old_issue_webuser_id_value=17

4) Run SQL to update edition date

update content_type_edition set field_edition_date_value=concat(right(field_old_issue_date_value,4),'-',right(left(field_old_issue_date_value,5),2),'-',left(field_old_issue_date_value,2),'T','12:30:00') where field_edition_date_value="ERROR"

5) Run SQL to update titles of nodes, six times with different values

update content_type_edition,node,node_revisions set node_revisions.title=concat('FAC ',node_revisions.title)
where content_type_edition.field_old_issue_webuser_id_value=20 and content_type_edition.nid=node_revisions.nid

6) Run PHP script to assign editions to groups, three times with different values

$sql="SELECT nid,field_edition_description_value FROM content_type_edition where field_old_issue_webuser_id_value='11'";
$query = db_query($sql);
while ($object = db_fetch_object($query))
{

$sql2="INSERT INTO og_ancestry (nid,group_nid,is_public)
VALUES ('$object->nid','248','1')";
$query2 = db_query($sql2);

// print edition nid as we go along
echo "$object->field_edition_description_value\n" ;
}

STILL TO DO: linking each edition to image id

NEWSLETTERS

The NewsletterID in [newsletters] is used to reference the PDF file for that newsletter. We will migrate the data from this table into Editions, write the title of each node as a concatenation of the newsletter name + date, and then use the NewsletterID to populate the [files] table with the right filename.

STEPS

1) Import csv file

2) Run PHP script to update language for each node

$sql="SELECT nid,shortname FROM content_type_edition as p,language_extic as l where p.field_old_issue_lang_id_value=l.LanguageID";
$query = db_query($sql);
while ($object = db_fetch_object($query))
{
$sql2="UPDATE node SET language='$object->shortname'
WHERE nid='$object->nid'";
$query2 = db_query($sql2);
echo $object->nid."--".$object->shortname."\n" ;
}

3) Run SQL to insert periodical nid into node reference field

update content_type_edition, content_type_periodical SET content_type_edition.field_periodical_reference_nid=content_type_periodical.nid
where field_old_newslettertypeid_value=field_oldnewsl_newstypeid_value

4) Run SQL to update edition date

update content_type_edition set field_edition_date_value=concat(left(field_old_issue_date_value,4),'-',right(left(field_old_issue_date_value,6),2),'-',right(field_old_issue_date_value,2),'T','12:30:00')

5) Run PHP script to assign editions to groups

$sql="SELECT nid,field_edition_description_value,field_oldnewsl_orgunitrefid_value FROM content_type_edition";
$query = db_query($sql);
while ($object = db_fetch_object($query))
{
$sql3="SELECT nid FROM content_type_group,orgunitrefs WHERE $object->field_oldnewsl_orgunitrefid_value=orgunitrefs.orgunitrefid
AND orgunitrefs.orgunitid=content_type_group.field_old_orgunit_id_value";
$query3 = db_query($sql3);
$object2 = db_fetch_object($query3);

$sql2="INSERT INTO og_ancestry (nid,group_nid,is_public)
VALUES ('$object->nid','$object2->nid','1')";
$query2 = db_query($sql2);

// print edition nid as we go along
echo "$object->field_edition_description_value\n" ;
}

6) Assign tax term 346 (newsletters) to all newsletter nids:

$x=0;
$sql="SELECT nid FROM content_type_edition WHERE field_oldnewsl_newstypeid_value is not null";
$query = db_query($sql);
while ($object = db_fetch_object($query))
{
$sql2="INSERT INTO term_node (nid,vid,tid)
VALUES ('$object->nid','$object->nid','346')";
$query2 = db_query($sql2);

// print edition title as we go along
echo "$object->nid\n";
$x++;
}
echo $x." terms inserted";

7) Update files and upload tables with filenames etc.

Pages and menus

Vitalie's scripts in the IofC Migrate module take care of this. Before running them on our master build, we need to:

1) delete url_alias table entries

2) only create top menus if not already present

Other settings in master build are done.
Delete pages button only deletes pages imported by this module.

Main Project Build

This section of our documentation concerns the building of the new system. We must document details about the configuration so that we can remember everything, and track potential problems back through the process of building.

A spreadsheet of modules we need, with their status in D6, is at http://spreadsheets.google.com/ccc?key=pXTE_gZaA_mF12GVI4e9Vcw

Audit trail of final build (7 July on)

July 7

  • Migration of users/contact records

July 8

  • Migration of pages/menus for global website

July 9

  • Transformation of tags in page contents
  • Migration of articles

July 10

  • Transformation of tags in article contents
  • Placeholder banners for each language (final versions due 31/7), and hot linked to correct language homepage (page template)
  • left_menu.inc updated for dynamic top menus
  • Top menus for each language positioned

Blocks

Any blocks placed in right column should be configured so that, for ‘Page specific visibility settings’, ‘Show on every page except the listed pages’ is set to:

  • */edit*
  • */add*

This has the effect of collapsing the right column for node add/edit forms, giving more space for the form.

Configuration of modules

Here we will describe the details of configuration of each module used, and any issues relating to the module.

Image

The Image Assist module install.txt gives info on how to enable a drupalimage in the TinyMCE icon bar, but this icon does not display in a multilingual site.

Insert View

This module allows a view to be embedded in the body of a node via special syntax. This functionality has to be enabled for each input filter which needs to use it.

Internationalisation (i18n) & Locale

The i18n module should only be enabled for those domains which will have multilingual content, as this module adds the language identifier to the url, and we do not want that for monolingual domains.

Localization: Import and enable language(s) needed in each domain.

Multilingual system: Links to node translations set to ‘Main page only’

Node Relativity

This module allows parent-child relationships between content types.

We are initially using it for the relationships between the 'contact record' content types:

  • Person Profile -> Address (child may have more than one parent)
  • Person Profile -> Biodata (child may have only one parent)
  • Organisation -> Address (child may have more than one parent)

Configuration is done by first choosing which content types should be used in relationships, and then for each one, choosing the 'Parental Ordinality' (i.e. how many parents it may have) and the 'Allowable Child Node Types' (i.e. which content types may be children of the selected content type).

The Advanced Settings tab allows us to limit the number of children for each parent. For example setting the Biodata Child Ordinality for the Person Profile to 1 (one), on the view form for a Person Profile there will be no option to link a second biodata once one has been attached. I have set the Address Child Ordinality for both Person Profile and Organisation Profile to two, so that people and organisations may not have more than two addresses.

We ran into error messages when adding nodes, but the data seemed to be OK. Vitalie found that the module needed a small patch, which eliminated some of the error messages. A lengthening of the [name] field in the [variable] table to 255 (see http://drupal.org/node/76828) solved the rest of the error messages.

We also needed to patch the relativity_views.inc file to add Relativity support for Views Fusion.

Node Type

This module adds an option to the node edit form allowing it to be changed to a different type, but it needs to be used with care.

Organic Groups and family

OG configuration:

  • Created group content type
  • Enabled access control for OG
  • Node authoring form: audience required
  • Other settings not changed at this time, but will need examination

OG User Roles configuration:

  • Assignable roles: Data controller, group admin, news editor, webmaster
  • Group creator gets group administrator role by default.
  • Readme file has CSS to add to stylesheet for display of the Configure Member Roles screen.

I created five Network members groups, one for each domain, each with *domain* (e.g. *uk*) in the title so that we can set up Views for each domain. We need to work out the best naming convention.

For a Network member to be able to create a new group, he has to be given that role in the domain.

Content types

Information about those content types which need some explanation

Content Profile

This content type contains no user data, and serves only to link a user to a Person Profile. It contains simply a node reference field to that content type.

Issue

This types is used for issues/editions of a magazine, for example 'Disha', 'Caux Information'. It stores:

  • Issue descriptor, e.g. 'Disha, Vol 5 No 6, Jan 2008'
  • A brief intro text, if any, about the theme of the issue
An issue is attached to a magazine via taxonomy: the vocabulary 'magazines' is exposed to the form when creating/editing an issue node.

Periodical

This content type is used for magazines and newsletters, like Caux Information, Disha, FAC, Breakthroughs, Global Update etc

Publication

This content type is for published items like Book, DVD, Video, Magazine (description not content) etc

Database issues

This section concerns anything to do with how the database was configured during the building of the system.

Table prefixing

The following tables need to be site specific by table prefixing:

  • blocks
  • boxes
  • cache
  • cache_menu
  • menu
  • system (info about module enabling etc)
  • url_alias
  • users_roles
  • variable
  • view_argument
  • view_exposed_filter
  • view_filter
  • view_sort
  • view_tablefield
  • view_view

Further tables added by new modules may be shown as needing to be domain specific/prefixed.

We will be wise to prepare the configuration as fully as possible for iofc.local, and then duplicate each table for each domain with appropriate prefix to save having to configure each domain entirely.

Additionally: locales_meta table (which stores languages enabled/defaults) should be domain-specific for all domains which vary from the default of English-only.

Sequences table needs updating with a new row inserted for each prefixed table.

Domains

Documentation:

 

Email systems

This section includes:

  • Brief for new module to run our email lists, integrated into Mailman
  • Notification services
  • Mailman issues 

Image system

Documenting our image system

New modules

Here we document the new modules we need

Email lists module

Introduction

This is a module that would take care of our mailing lists. We want to use Mailman (http://gnu.cict.fr/software/mailman/index.html) as the engine and integrate an interface into our Drupal build.

There are a few modules available on drupal.org, the main one being http://drupal.org/project/mailman_manager. I am however thinking that we need to do our own module because:

1. Our subscribers would come mainly from the Contacts, not from the Users.

2. Existing modules have very limited functionality.

The email lists system involves the following main parts:

1. Lists

2. List administrators

3. List subscribers

4. Subscription access to a list

5. Categories of lists

6. General settings of the module

7. Interaction with other modules

Lists

We will have a Content Type for lists. Thus lists are nodes. A list would include the following [CCK] fields:

1. Title* - the tile of the list

2. Mailman name* - the name of the list in mailman

3. Description

4. Weight

5. Other (see below) Access to lists is managed by Node access policies.

List administrators

Here, list administrators are those who can subscribe and unsubscribe anyone from among the Contacts. Question:What happens if a person is not yet in the Contact database? I am thinking to implement this by means of a separate table:

[lid] - id of the list

[uid] - user id

List subscribers

These are Contacts subscribed to a certain list. Again implemention would use a separate table:

[lid] - id of the list

[cid] - id of the contact

Remark 1: In the settings of this module there will be a variable to indicate which is the Content Type which refers to Contacts.

Remark 2: I am thinking to borrow ideas from Relativity module. There is a possibility to actually use it, but I favor an independent module which may use some of its ideas.

Subscription access to a list

Will a certain list be accessible to a certain user for subscription? In other words, there will be a nice listing of lists for a user somewhere (a new tab in My Account?). So which lists will actually be there? Those which display will allow the user to subscribe or unsubscribe to them.

Possible audiences:

- user roles, e.g. only authentificated users can subscribe

- groups, e.g. only members of a certain group can subscribe

- private, e.g. only list administrators can subscribe people

Question: How would these be combined? by AND, by OR?

Categories of lists

These are simply for making user experience more friendly. All email lists would be presented in groups (categories).

Taxonomy can be used here.

General settings of the module

  1. The Contact Content Type
  2. The Email List Content Type
  3. How should communication with Mailman engine happen: directly using scripts or by HTTP requests

Interaction with other modules

Other modules might want to trigger a subscription action. For cases like these we would use the Actions module.

Overview of major configuration structures

We will document here the bigger picture of how major sets of functionality are met.

Contact record / user system

This is how we have structured the data/content types/modules to met our requirement of having contact records which are not linked to users:

In brief:

  • the Usernode module ensures that a node of content type 'usernode' is created when a new user is created. For any content types linked to the usernode by the Node Profile module, a node of that content type is also created when a user is created. So, in our configuration, when a user is created, a node of usernode type is created and a node of 'user profile' type is created (see more detail elsewhere).
  • the User Profile node has a node reference to the Person Profile content type, so a user can (and should) have a Person Profile. This node has to be created programmatically when a user is created. By this method we allow a user to have a Person Profile, an Address and a Biodata (via Node Relativity).
  • Primary contact record information is stored in either the Person Profile/Address nodes, or in the Organisation Profile/Address nodes. An organisation will never be a user, so there is no link to that content type from the usernode. An organisation also does not have Biodata, so there is no Node Relativity link between an Organisation Profile and a Biodata.
  • The Biodata type will allow translations, so that we can have translations of the English biodata. All other content types mentioned so far here will not allow translations.

 

Data control / data user system

Definitions:

  • A 'contact record' is the set of data for a person or an organisation which is to do with who they are (their profile) and how they may be contacted (their address, phone number, etc).
  • A 'data controller' is a group (a special content type for each), whose members have permission to EDIT the contact record information for any person or organisation whose profile is assigned to the group. Each contact record will be assigned to one, and only one data controller group. For example, the contact record for Edward Peters would be assigned to the 'UK data controller' group which has responsibility for maintaining his data.
  • A 'data user' is a group (a special content type for each), whose members have permission to USE (but not change) the contact record information for any person or organisation whose profile is assigned to the group. By use is meant the permission of the person to be in contact with them by way of email or postal transmissions. For example, the 'USA data user' group might have permission from Edward to store information about his relationship to IofC USA which enables IofC UK to stay in touch with Edward.

For each data user group there will be a content type with fields which store the data relating to the association of a contact record with the data user group. A node of this type will have a Node Relativity link to the parent contact record to which the data relates - either a Person or an Organisation.

This may be understood more easily through a concrete example. Let's look at IofC UK head office. It will have some contact records attached to it for which it is 'data controller' and some for which it is only 'data user'. This will be achieved by three content types:

  1. The 'UK data controller' content type which is an organic group type. Any Person or Organisation nodes which are assigned to this group will be editable by a member of this group.
  2. The 'UK data user' content type, also an organic group type.Any Person or Organisation nodes which are assigned to this group may be viewed and used (but not edited) by a member of this group.
  3. The 'UK data' content type: this stores the data relating to the record's association with IofC UK.

The contact record for Edward Peters would thus be assigned to both groups, so that the UK office can both edit and use his contact data - he has given permission for this. The 'UK data' content type would record details which the UK office needs to know in order to make contact with him - e.g. whether he gets the UK newsletter, whether by email or post, which regional teams he belongs to, etc etc.

The contact record for Vitalie Cracan might be assigned to the second group, if he has asked for UK IofC to keep in touch with him. But his 'data controller' group might not be UK IofC. 

Proto and live sites

The main Drupal build includes:

  1. A code-base (mostly PHP scripts)

  2. A data-files repository (includes documents, images, etc and these may sit in different locations on the filesystem)

  3. One database for all domains in the IofC family

-) There will be a prototype site environment for each live site.

-) The code-base would sit in two locations - the prototype location, accessible through SVN, and the live location, accessible through deployment of the prototype copy. The names of the different domains in the prototype location should be the same as those in the live location. If the actual prototype site is named as the live one plus the prefix e.g. “protobuild.”, then Drupal would pick it up correctly.

-) There would be one testing (prototype) and one live database for all domains. It is highly recommended that every new configuration be done first in the proto database and then, once one is satisfied, repeated MANUALLY in the live database. From time to time, the proto database will be overridden with content from its live corresponding database in order to bring them to synch. It is recommended that this procedure be done by one person only. 

-) There will be just one copy for the data-files, thus the prototype and the live environments would share them.

Roles

Working list of roles needed either at domain level or OG level:

  • Network member (Full user)
  • Administrator
  • Group admin
  • Webmaster
  • Data controller
  • News editor

Users can be created in any domain and are universe-wide. But the roles they are assigned are only granted in the domain in which the grant is made. I created a webmaster for each domain (e.g. aflwebmaster, ukwebmaster) but other roles are granted at the group level. Also created data controllers (e.g. ukdc) and ‘basicuser’ for testing.

There will be a lot of work to do to define which roles are needed in which domains, and to assign users manually after migrating user data.

All users who become Network members need to be assigned to the ‘Network member’ role in ALL domains (this allows them to create some content in any domain, including creating a new group). Each such user also needs to be made a member of the Network member group in each domain. We will need a module to do this for any user who becomes a network member.

The creator of a group by default gets ‘group admin’ role in the new group, so that role needs to give access to ‘Configure member roles’

Group roles

Documentation about which roles needed in which groups

Search issues

Access permissions given to anonymous and authenticated users for basic search and to network members for advanced search.

Running Cron to update the search database covers the whole universe (not just the domain in which it is run)

Theming

Here we will document everything to do with theming

Visual design changes - proposals for discussion

  1. The iofc.org family: we will port our existing designs as they are, with the following changes:
    1. Page widths: we will move to 970/990 pixels width (any views on best one?). The fact that the BBC News website, which is super-sensitive to developing-world surfers, has recently moved to wider pages, gives confidence that it is OK for us to do so too, without prejudicing our users.
    2. Menus:
      • The right column menu will become a top menu, with dropdown for second level items, and perhaps flyout for third level items.
      • When the active page is second or third level, a ‘sliced menu’ will appear in the right (or left?) column, showing the navigation of that level and below
      • We will abolish the minisite top menu system and put that navigation into right column menus
      • All menus will be text menus, with no graphics
    3. Columns: we discussed the possibility of dropping back to two columns (left and centre), but with the increased page width, I am inclined to stick to three. Views?
    4. Language selection: we will replace the current horizontal language names on homepage with a drop down selector in the right column (as we have at present for all pages except homepage).
    5. Login block: I suggest we have this in the right column of all sites, rather than displaying a link to a login page.
    6. Email subscriptions: we will abolish these subscription blocks in the right column of many sites, as there is no buffer against spammers. Instead we will implement a signup system.
    7. Banner: this will become a static, complete image, for each site rather than using the complex dynamic system we have at present.
  2. Caux website: we will need to consult them. Our comms team is keen to encourage Caux to move towards the IofC brand, but this may take time, so we may need to port more or less as they have it.
  3. For A Change: given that this is now an archive site, I think we should do little to it, and simplify some of the surfing features we are offering (‘Browse by…’) which are complex to migrate into the new system. It is OK as a searchable archive.
  4. Michael Henderson: Port as it is.
  5. Some other sites currently situated inside the global site (e.g. Farmers Dialogue, Caux Scholars, etc) will become standalone, but usually in the iofc.org template.

Page and column widths

FINAL VERSION

Page width: 970px
Left column: 175px (which includes 7px of left border of white space; I.e. 168+7)
Margin (left/centre): 20px
Centre column: 517px (515px centre image)
Margin (centre/right): 20px
Right column: 238px (which includes 7px of right border of white space; I.e. 231+7)

PREVIOUS VERSIONS (for the record)

VERSION 1
Page width: 970px
Left column: 180px (which includes 7px of left border of white space; I.e. 173+7)
Margin (left/centre): 15px
Centre column: 520px
Margin (centre/right): 15px
Right column: 240px (which includes 7px of right border of white space; I.e. 233+7)


VERSION 2
Page width: 970px
Left column: 177px (which includes 7px of left border of white space; I.e. 170+7)
Margin (left/centre): 18px
Centre column: 520px
Margin (centre/right): 18px
Right column: 237px (which includes 7px of right border of white space; I.e. 230+7)

Users

Information about user related issues

User registration

If we want a user to be able to input a special code which gives instant promotion to the Network Member, the Registration Code module (http://drupal.org/project/regcode) may help as a starting point - it will probably need adapting. See http://drupal.org/node/85861 for a discussion of issues on this.

Completion

We contributed.

Miscellaneous ideas

Dropdown for other IofC websites

Search contacts
Search help

Technical manual

Instructions for those who have to maintain our system in future.

Accessibility

For an international Network, such as IofC, we shall think of accessibility to any of our Internet sites. The W3C offers guidlines for creating accessable Internet Services.

The Web Content Accessibility Guidelines (WCAG) documents explain how to make Web content accessible to people with disabilities. Web "content" generally refers to the information in a Web page or Web application, including text, images, forms, sounds, and such. (More specific definitions are available in the WCAG documents). This material is based on the April 2008 Web Content Accessibility Guidlines 2.0 of the W3C wich are at present just before final release. It is expected that they will release by the end of this summer.

Accessiblity is in many different way a sensible issue. A personal comment: f.e. the whole information about accessibilty is only presented in english. As a native german this allready makes it difficult to understand.

We might not achieve to cover all the mentioned recomondations but we certanly shall achieve as many as possible for Level A(Read more about Priority Levels).

Within this section we will document the process of achieving accessibility to our websites and related issues such as why we might not achieve one or the other recomondation.

A very helpfull Link to the customizable Quick Reference

Accessibility Recomodation for IofC Websites by Heinrich Pick

After reading the WCAG recomondation for Lavel A and AA, and reading serveral contributions to serveral forums I still have to admit that the whole issue of accesibility needs more time and attention to really get to a full understanding. Time which I doubt is worth spending at this point.

To my understanding the very basic points for Accesibility are:

Checklist on Design

  • always offer a text alternative to nontext content
  • only use text for the navigation (topnavigation and sidenavigation)
  • try not to use Java, Javascript or anythink alike
  • only use the latest HTML which the correct sytax
  • not flickering or blinking elements (animated GIFs, Flash)

Checklist on fonts

  • allways use relative font-size (100%) never absolut or fixed font-size (e.g. 12pt)
  • fontsize 1em= 100%
  • do not use the<Font>, <Blink> or <Marque>- Tag
  • Use only sans serif fonts like Arial, Verdana
  • do not use more than three different fonts

Checklist on colours

  • best to use is anything with highcontrast text/background (e.g. black text on white background)
  • no red/brown or red/green, some people will not see the difference
  • All information has to stay understandable when displayed using no colours. (e.g. how it should not be done: "the names below, which are highlited in green are the responsible..." - for viewing this without colour there will be no difference between the name)

Checklist on images

  • Another option is aTextlink below the image pointing to a page with further discription of the image
  • if we use nonvisiable grafik leave ALT-Tag empty. Screenreader than do not read anything
  • do not put image numbers etc. in the alt tag. Its anoing when the screen reader reads them all
  • As ALT-Tags are visible to all user (on mouse over/MSIE) we might consider a link bellow the picture if we have a longer discription to an image (the usage of the ALT-Tags are also an SEO issue)
  • try to aviod using background images
  • charts (images only) be offered also as text chart or with an alternative text description

Checklist on Video

  • possiblity to stop, pause and play
  • no flickering in the array of 4-59 Hertz (flashing stuff)
  • no subtitels, playing in the video - text alternative

Checklist on Audio

  • deaf people need a text alternative (link bello the audio to a text description page)

Checklist on Applets and Scripts

  • only use if the information retain the same if the user cannot use the applet or offer a textalternative to it

Checklist on Links

  • use short textlinks which describes it function
  • do not use "klick here"-Links as some people jump from link to link and will not have the information in the text before. Link the whole sentence (e.g.: "for further information on the International Association click here")
  • all links reachaable with the Tab-key
  • Links not to close to each other (think of the displaying of the taxonomy)
  • skip links option on the beginning of the site (not only readable for screen readers as keybord user who can read might whant to use this as well-- I have no idear how we can achieve this)

Of course there are more recomondations related f.e. to using/not using frames or tables etc. etc. but so far I think they do not affect us. We will see.

Please leave any comment on "is it possible for us to achieve this?"

Priority levels

The Guidlines have three priority levels:

  • Priority 1 (Level A): Web developers must satisfy these requirements,
    otherwise it will be impossible for one or more groups to access the
    Web content.
  • Priority 2 (Level AA): Web developers should satisfy these
    requirements, otherwise some groups will find it difficult to access
    the Web content.
  • Priority 3 (Level AAA): Web developers may satisfy these requirements,
    in order to make it easier for some groups to access the Web content.

IofC websites are designed to cover Priority Level 2 / AA.

Priority 1 / Level A

These are the requirements for Priority 1 / Level A:

Text Alternatives

  1. Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. Have a closer look at Buttons like a "send-button" informs or images /icons that indicate to start a function like a "search-icon" or link to an pdf staing "this lik will open the pdf".

  2. Pictures should have a short discription telling in one Sentance what is on the picture. In some cases it might be useful to have a longer discription, when the image is important to understand the text (but I suggest we do not try to achiev this)

  3. Charts (non-text only) need to have a short discription stating what this chart is about and a longer text telling what is in it.

  4. Charts (text) A table presents a list of times across the top row and a list of events in the first vertical column. The cell corresponding to the time of a particular event has a specific background color and diamond shaped glyph so it can be identified by color and shape.
  5. An on-line multi-page survey
    An on-line multi-page survey uses a link implemented as a green arrow icon placed in the lower right hand corner of the content to move from one survey page to the next. The arrow is clearly labeled with "Next" and the instructions state, "To move to the next section of the survey, select the green arrow icon labeled 'Next' in the lower right below the last survey question." This example uses both positioning, color and labeling to help identify the icon.
  6. Forms: An introducing text stating that a asterix indicates compulsory fields and, if so, are marked in (f.e.) red is recomended. Asteriks behind a field will determine by assistive technology. Also offer an programmatic assigned alternativ text or label to each field stating what is requiered and if compulsory (f.e. "required field first name").
    Espacially have a closer look how forms behave when the user try to sent/saved them with compulsory content missing. Are the missing content fields only indicated in red? Than we need to think about an alt-tag or label for this.
  7. CAPTCHA: provide text alternatives that identify and describe the purpose of the non-text content, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.

    CAPTCHAs are a controversial topic in the accessibility community. .

    Because some users with disabilities will still not be able to access sites that meet the minimum requirements, the Working Group provides recommendations for additional steps. Organizations motivated to conform to WCAG should be aware of the importance of this topic and should go as far beyond the minimum requirements of the guidelines as possible. Additional recommended steps include:

    1. Providing more than two modalities of CAPTCHAs

    2. Providing access to a human customer service representative who can bypass CAPTCHA

    3. Not requiring CAPTCHAs for authorized users

  8. Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
  9. Audio Control: If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.

  10. Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

  11. No Keyboard Trap:If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys, the user is advised of the method for moving focus away. Example: A calendar widget allows users to add, remove or update items in their calendar using the keyboard. The controls in the widget are part of the tab order within the Web page, allowing users to tab through the controls in the widget as well as to any links or controls that follow.

  12. Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology >no alt-tag or empty alt-tag.

  13. Tests: If non-text content is a test or exercise that must be presented in non-text format, then text alternatives at least provide descriptive identification of the non-text content.
  14. Sensory: If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content. ...to be continued >>I suggest not to use non-text content to creat a specific sensory experience

Time Based Media
If we use Time based media such as video and audio this following is only relevant for Time based Media which is not an alternative to a text. >> If the TBM is off less relevance, as there is a text going with it, it can be labeled (labeling is important!) as such and we do not heve to do the following, if their is no text we do (podcast f.e.):

  1. Audio: a textalternative is provided that presents equivalent information.
  2. Video: either a text alternative or an audio track is provided that presents equivalent information.
    >> This is relevant for all our podcast f.e. The upload function for Audio and Video must have a text alternative descritpion field!
  3. Captions to the Video is provided. Captions not only include dialog, but identify who is speaking.

Adaptable

  1. Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
  2. Meaningful Sequence:When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.
  3. Sensory Characteristics: Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound.
Timing Adjustable:

For each time limit that is set by the content, at least one of the following is true:

  1. Turn off: The user is allowed to turn off the time limit before encountering it; or
  2. Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
  3. Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or
  4. Real-time Exception: the time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
  5. Essential Exception: The time limit is essential and extending it would invalidate the activity; or
  6. 20 Hour Exception: The time limit is longer than 20 hours.

Note: This success criterion acts to ensure that changes in content or context as a result of a time limit will not occur unexpectedly, which could prevent users from completing tasks. While exceptions to Success Criterion 2.2.1 where timing is essential exist, guideline 2.2 in general limits changes in content to those places where there is no other option. This success criterion should be considered in conjunction with Success Criterion 3.2.1 which puts limits on changes of content or context as a result of user action.

Pause, Stop, Hide:

For moving, blinking, scrolling, or auto-updating information, all of the following are true:

  1. Moving, blinking, scrolling: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and

  2. Auto-updating: For any auto-updating information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.

    Note 1: For requirements related to flickering or flashing content, refer to Seizures.

    Note 2: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion.

    Note 3: Content that is updated from a process, real-time or remote stream is not required to preserve or present information that is generated or received between the initiation of the pause and resuming presentation, as this may not be technically possible, and in many situations could be misleading to do so.

    Note 4: An animation that occurs as part of a preload phase or similar situation can be considered essential if interaction cannot occur during that phase for all users, and if not indicating progress could confuse users or cause them to think that content was frozen or broken.

Seizures
Three Flashes or Below Threshold:

Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.

Note: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion.

Navigable
  1. Bypass Block
    A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. Understanding Success Criterion
  2. Page Titeled
    Web pages have titles that describe topic or purpose.
  3. Focus Order:If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. Understanding Success Criterion >>f.e. on home the language select should be first. That we detect the language setting on loading the page could be useful so the site apears in the probably right language right away. How can we open the drop down?
  4. Link Purpose (in Context)
    The purpose of each link can be determined from the link text alone, or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.
Predictable
  1. On Focus:When any component receives focus, it does not initiate a change of context. Understanding Success Criterion

  2. On Input:Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. Understanding Success Criterion

Input Assistance

  1. If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.
  2. Labels or instructions are provided when content requires user input.

Compatible

  1. Parsing: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. Understanding Success Criterion

  2. Name, Role, Value: For all user user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. Understanding Success Criterion

Note: This two success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.

 

Hacks to core files

Garland theme

themes/garland/template.php contains custom functions. If new version of core is installed, make sure to back up and restore this file.

Mailman administration

This is where the Mailman administrators manual will be drafted

Menus

TOP MENUS 

Nice menu module used to provide the flyout menus at the top. Site configuration -> Nice Menus sets the number of nice menus. Set to 8 initially, one for each global website language.

For each 'nice menu', a block is provided in the blocks list, which needs to be renamed and configured for correct language and correct menu.

The menus themselves each also provide a block in the block list, and these should be ignored/left disabled.

MAIN LEFT MENU 

This is a block with an 'include' file (sites/all/includes/left_menu.inc) which shows the active menu item and its children.

USER ROLE MENUS

Several user roles will have their own menus which will appear on the left if the user has the role. In particular:

  • Site member menu for site members
  • Network member menu for network members
  • Webmaster menu for webmasters 

Theming manual

This Manual explains how we have prepared themes, for the benefit of future maintainers of our system

The main IofC Global theme

The theme 'iofcglobal'

Most of our themes will be derivatives of this main theme. The naming convention for iofcglobal derivative themes will use 'iofc[xxx]', e.g. iofcuk, iofcf4f, iofccaux.

Names are given in http://spreadsheets.google.com/ccc?key=pXTE_gZaA_mHirDy-vLScCg&hl=en 

Menus

Top menu

Uses the Nice Menus module. Themed via top_menu.css.

Main left menu

Block called 'left column menu', visibility all pages except front. Body of block includes PHP code which outputs the menu. Themed in style.css 

User Manual

This is where we collect articles documenting the use of Drupal.

Notification services

There are several ways in which you can choose to receive notification of new content added to a website:

(1) You can choose to receive email notification when a new item is added to the site. There are three possibilities for subscribing:

  1. by 'type' of content, e.g. article, book page, event, image, etc
  2. by 'thread' - this means you can subscribe to a particular 'page' (node) and be notified of comments that are added. Most useful for Forum topics.
  3. by 'author' of an item - the person who adds the item, not necessarily the person who wrote it!

You can subscribe for 1. by going to My account -> Notifications tab -> Content type

To subscribe for 2. and 3. use the links at the bottom of pages which allow subscription. Any subscription you make there will appear in your My Account -> Notifications tab under 'Thread' or 'Author'.

When subscribing you can choose the frequency of the notifications, and whether you will be notified by email sent to your email address, or by a message in your My Account -> Messages page.

You can unsubscribe at any time via your My Account -> Notifications tab, or by clicking on the unsubscribe link that comes at the bottom of emails received. 

(2) 'Web alerts' [if we keep these, text to be written] 

(3) Email updates [text to be written when we know how exactly we will configure these] 

(4)  RSS feeds.... [text to be written]

Webmaster manual

Drafting pages for the webmasters manual

Introduction to Drupal

With Drupal we need to learn a new terminology and context.

A block will usually be placed in the left or right hand columns of the page. Blocks can be dependant on the user's role, whether you are given permission to see and do things. Whether or not a block is visible depends on the role of the user and their privileges. For example, what blocks the user can see, blogs etc. Another example could be a block that displays the title of the last 10 news items anywhere on the website that could only be visible to a webmaster. The UK webmaster could see articles on the Australian site, the Canadian site, etc. if desired.

Roles are where you have been assigned what you can see and do and whether you see blocks.

Menu controls navigation

Theme means overall look and feel of the website – header, colour, width, where the menu is, the basic look of the page.

Nodes are the basic building blocks or the contents. For example, in a spreadsheet with columns, the node would be a row in that, including the title and main body. If an article was a node, the node would have similar structure to the old system but it goes further. There is an article node and also an events node, which have a slightly different structure. Almost everything apart from blocks and menus is a node (though for non-webmasters we won't use the word node, we will call it an article, a page, forum, blog). Node is a technical term, understood by webmasters. You can extend the node with fields, e.g. Title, body and author. If you wanted a reference to an issue of a magazine you could extend the node structure.

Node type and Content type are synonymous, the content is exactly the same.

Another useful feature of Drupal is that it implements revision. A previous version will be saved as well as the new version of the article, etc.

Taxonomy means the science of classification. e.g. All books from Malta could be classified.

In Drupal we create vocabularies, a collection of terms. The term for an article might be editorial or blog, for example, it is a way of classifying articles. There is a category drop down list for you to choose from. Vocabulary with a lot of terms. This is needed in order to present content in different ways in different places.

A tag is synonymous with a term. There can be a drop down list of terms, you can select one or multiple select, or none at all if not required. There is also free tagging, where instead of a drop down list you can input your own terms.

Comments are equivalent to feedback in old system.

Module: this is an additional bit of computer code which can be added in and allow extra things to happen. It is an extension of Drupal and means that you can programme extra code and is added for an extra function.

Teaser is equivalent to the introduction of old system.

User: there are 2 types of user. A visitor who is not logged in is anonymous. Once they are logged in they are an authenticated user. So the users have two roles as described above, but there is also a third role, a network member (like old Extranet member) who is able to subscribe and comment, with a moderator processing it.

On the Homepage of iofc website all the centre is in one block. A syntax inserts in between a command – you create a view and it is configured to show this. A View has a unique name - “syntax” and it is inserted by its name, e.g. [view:latest_3_news]

Click on Edit on homepage. You will see various boxes. The first one says that the title is “Homepage”. The title can't be seen by the visitor, it is for admin purposes. The title will show for dynamic content, not for static.

Node: these have different content types. One of the most important is page content type. A page in drupal is very similar to Manage pages in the older system – a static page. Fox example, on the About Us page, we need to create a node of the type page. It will have a navigation, similar to the path in the old system. Other node types are articles and news. Opportunity and event nodes are called events nodes. Pages are equivalent to pages, Articles equivalent to articles, events equivalent to events.

The left and right column blocks are similar except they won't break down into so many individual items, things will all appear in one block, e.g. The programmes in the left hand column of old system will all be in one block.

There will not be any user input unless the user is logged in or possibly has security verification. They would have to register with name and email, then proceed to 2 levels of membership. Comments, forums, buying from online shop, emails would be the first level. Second level, a further process, would need to be moderated.

Adding email links

IofC policy is to 'hide' email addresses behind forms, rather than publishing on web pages - in order to prevent spammers from 'harvesting' email addresses.

To do this we use the concept of 'Categories' of email form. A 'category' can be linked with (point to) a single email address for a person or organisation, or it can point to to multiple email addresses. Categories should be named in a user friendly way, as they will appear at the top of the contact us form.

For example:

  • 'John Smith' could be the category which links to the email address 'john.smith@example.com'
  • 'IofC UK' could be the category which links to the email address 'info@uk.iofc.org'
  • 'Caux Administration' could be the category which links to the email addresses of a team of people, e.g. 'admin1@caux.ch', 'admin2@caux.ch', etc

To create a link to email a person or organisation, first go to Site building -> Contact form (admin/build/contact/list) and see whether the person/organisation you want to link to already exists in the list of categories. If it does not, click the 'Add category' tab. Name the category carefully according to the above rules. Input one or more email addresses separated by commas. If you want the person using the contact form to receive an auto reply you can put some text into that box. Otherwise leave the other settings as they are.

You then use the Category to create the link in your node body. Highlight the word/s you want to transform into the link, then click on the Link icon. In the popup box leave Link type as Url. In the prototype drop down, select <other>. In the Url text box put 'contact/{categoryname}'; replacing any space/s in {categoryname} by underscores (e.g. 'contact/John_Smith') - without the apostrophes.

This will create the link which when clicked takes the visitor to the contact form and when they use it the email will go to the email address or addresses associated with the 'Category'.

Please note that the email addresses are not linked to the email addresses in our contact record database, so if an email address is updated there it will not be updated for the Category.

Adding to Top Menu

To add to the Top Menu, click on Site Building, Menus.

Click on Top Menu. You can drag and drop, up and down, left to right.

Click on Add item -
The Path box is mandatory, similar to old system.
The Menu link title is mandatory, containing words that appear in the menu, e.g. “Finances”
Description box is optional, it enables the user to hover over a heading to see what it is, e.g. “All about how IofC is financed”.
Ignore the green cross and picture.
Enabled – this should be ticked if you want it to be visible. For example, if you are creating something but don't want other people to see it, then do not tick this box. Expanded – if selected and this menu item has children, the menu will always appear expanded.
Under Parent item there is a drop down list which selects where it appears. Select Top Menu
Weight is where you select what order it will appear in. You can enter a number here or you can drag and drop later.
Click on Save.

Go to the tab at the top which says List Items and click on the edit menu tab. The title would say Top Menu and the Description could say The main 'public' top menu.

On the list items page you can choose to tick on enabled and expanded.
(The news menu item says reset rather than delete because it is linked to a view.)

It is unlikely you will have to use the Edit menu.

The following is an example:

We want to add a new page to CEC, on finance. In the Top Menu list (under list of Menus) go to Clean Elections Campaign, which can be found in Programmes & training, National building & transforming society.

Under Content Management go to Create Content and select page. This is a semi-static page, not something that is being updated.
The Title doesn't display to users
The Title field does appear, so to identify it put CEC finance page.
In the body put the title followed by the text. Click on rich text and choose Heading 2 for the heading. (Finance)

Where does this appear? Click on menu edit for CEC
Menu link title – Finances (this will be seen)
Parent – CEC is parent
Weight – if you are building up a site introduce pages in correct order if poss and start off with a low weight, e.g. -40. If you can't remember, change it in site building menu area.

Go to Site building, menu and click on Top menu
If we have 7 languages, there are 7 top menus. Menus will be blocks, each set to the language of the top menu. The menu items are set to the language. If you add an item to the top of the English speaking menu, for example, the French would have to create the menu item and new page or translation of a page.

Authoring information

Some tips which needed to be written up:

  • Provided the Diff module is installed, there is a new button at the bottom of the node edit page 'Preview changes'. This enables you to compare your new version with the existing one, and see just the changes you have made.
  • If the Book module is installed, there is an extra tab when viewing a node, 'Outline', which enables you to add your node to the book outline as a book page, choosing its parent. Doing this does not remove the node from the content type it was created in.

How to add a view (revised)

A View is a way of presenting information in the database, it is a way of providing listings according to certain criteria and orders. It is a user interface which enables non-programmers to present complicated data.

The example that follows is to produce a view which is a page, that allows the user to choose a drop down list of periodicals and to filter the editions of the periodical chosen.

Go to Site Building, Views. You will see a list of all the views that have been configured. Most of these have been created by Drupal. Click on "Add" in box near the top. The View Name is for admin purposes - in this example add editions_periodical_bd. The View Description used here is filterable list of editions by periodical. The Tag is an optional way of sorting, making it easier to find - add editions for this example. The View Type is a Node, click on this and then click on Next.

On the left of the page you now see is a the heading Defaults. We want to display it as a page, not a block so select page and click on "Add display". You willl notice that a red block appears under the Live Preview, which is telling you that you haven't finished! Next we need to give a path to the page or it won't be found - to do this you go to Page Settings - path. Click on the word "none" and you will see a new horizontal block underneath, to determine the path. The path used here was Editions-by-periodical-bd - click on update. Click on No menu and change to Normal menu entry. Update and save.

The Filters determine what data is shown. So click on the plus sign by Filters and you will see a large box below, called Defaults: Add filters. In the Groups drop down select Node - the display will automatically change. Then click on Node Type as we want a list of editions. Add this - you will then come to another box! Operator is one of or is not one of - you have the choice of the node being one of or not one - in this example we want to select is one of Edition so tick on that and click on Update. Add another Filter and select Content under Groups and then select Periodicals. When you add this a list of periodicals appears in a box on the right - you don't need to alter this. Click on the Expose button so that the user can choose what periodical they want to read. Also click on the Reduce duplicate box (same as the distinct box, to avoid a view appearing twice if it is filtered twice). Leave the Optional box and Force single boxes ticked. The Label should be changed to IofC newsletters and periodicals and then updated.

Fields are where we specify which bit of items in the list we want to display. e.g. Author, country, photo, teaser. Fields could have several rows. Click on the plus sign and then go to box below which says Defaults: Add Fields. Click on Node, then Node Title and click on Add. You will see a box that says Label: Title - if you left this the word Title would appear in front, so clear this. In the second box it says Display field as a link to the full node - tick this as we want it to be a link to be seen. Update.

Underneath you will see a live preview, which allows you to preview it. It is only showing ten editions as the number in Items to Display is set to 10 in the basic settings.

We want to add the link to PDF attached to nodes. Click on adding to Fields again and select node. Then select Node: Attached files and add. In the box that says Label, we have to decide what we want it to say, and in this case we deleted the words that were there and instead inserted PDF. Tick the box that says Link this field to download the file. In Empty list text you could type in the wording that would appear if no PDF was found, such as No PDF available. Update and save.

Sort criteria select Content, content date edition date and click on add, then click on descending

Under Basic settings, Number of items - if this was set to 0 it would show all of the editions. You could click on use pager if you wanted to number pages.

The More Link can be used to show a link which when clicked on gives more information.

Distinct can be used if a view might show twice using the same node as it responds twice in the filtering. If you selected Distinct to be yes then it wouldn't appear twice.

Access allows us to control the view by access, e.g. by role.

Header and footer could allow us to put in text in an introductory text. We are more likely to use the header than the footer.

Empty text is useful, e.g. it coulde say "no results found". So if a user found no pdf for example, it could say no results found.

Theme - don't worry about this for now!

How to add an Article

(To work on the menu settings part I had to go to Tools, Options, untick Java Script).

To add an Article go to Content Management, Create Content, Article. 

Type in the title of the article in the Title box 

In the Vocabularies box you will see Topics, Article type and keywords. (Taxonomy is about vocabularies and each vocabulary has terms, like a category, in it). Selecting from the Topics drop down is optional and you can select more than one, by holding the “Control” key and selecting the topics you want. Some topics might require that you select General from the Article type and then a more specific category from the Topics drop down. You do have to select from the Article type, e.g. Editorial.

In the Keywords section, the user can input new terms if they want to. If you typed in “c” it could come up with possibilities for that letter and you could select any of these, if appropriate. If you wanted a new keyword, type it in, e.g. Caux 2008. This would then be saved as a new keyword.

In the Body field the text can be have an introduction/teaser and you can choose whether the teaser is displayed in the main body of the text or not.

Select language and author.

Groups – this will be covered later!

Book outline. There is the possibility to place a node into a book structure. The content is structured into a hierarchical form, like Chapter and section 1, sub section. This is useful for presenting something, e.g. in the User manual and webmaster manual there is a book with child pages. So you need to think “Do I want this article to be a part of a book?”. The book would be in the drop-down section. Attach it as a child for a page in the book.

In the Search engine keywords box add keywords that would not visible on the website, but which are used by search engines like Google.

Create new revision – we may well use this and allow this for network members. It would allow users to edit, a decision needs to be made on whether this is moderated or not. You could then compare the old version with revised versions by going to http://drupalproject.iofc.org/node/293/revisions
The default will be ticked so that we can track changes – this will be for editing, not creating of course.
Look at Revision for definition of terms article and click on "Show diff". You will see the older version and the newer one, with changes in red.

Log message – put a note of any changes.

Comment settings – the policy on this still needs deciding on. What would probably happen is this: a public visitor cannot leave a message, they would have to be logged in and be a site member to leave a comment; if a comment about an article is on the public site it should be moderated; if it is private, it wouldn't need moderating. So leave this for now.

Url path settings – we won't usually use this. It is where we would put anything that can be used as an alias. This may well be hidden for articles.

The Authored by will probably be changed to “Posted by” whre you put the name of the person adding the article to the site.

The Posted on box can be left empty, though you could change it to another date if you needed to. The date of the article is more important.

In the Posting options, if the Published box is ticked it is indicating that it is visible. The Promoted to front page box should be left unless you don't want the article to appear on the homepage, if say you felt other articles were more important.
Sticky at top of lists could be selected if you wanted the article to remain at the top of the latest 3 articles on the hompeage until you deselected this. To be more specific about the order please refer to Nodequeue section of this manual which would allow you to control the node list so you could decide in what order things appear.

If you later want to edit an article go to Content Management, Content and you will see a list of articles. Edit the one you want by clicking edit on the correct article.

How to create a Nodequeue

A Nodequeue is used in order to allow you to choose the order of nodes, not necessarily in the order that they were posted but in the order that you want them to appear in. They are most commonly used in blocks on the right hand side, for example in a block that shows periodicals.

The following is an example of how to do this. Go to Content Management, Nodequeue and click on Add nodequeue. In the title field add a title (which will not be shown to the user). In this example choose featured periodicals bd. In Queue size type in the number you want, in this case 5. The Reverse in admin view is to do with the order in which one periodical will drop away when a new one is added - we will look at this later when we are clearer about it! We won't need to use the next two fields, which enable links which appear in the node. Once roles are set up you may want to tick webmasater in a box that would appear here. Under Types select periodical and then click on submit.

Select View so that you can now choose which periodicals to put in this box, in the Select Title to add box. For FAC type in the letter F and a drop down of periodicals beginning with F appear - select For A Change. Add the other 4 periodicals you wish to add and then click on save. Under the heading Operation on the right hand side you can click on the up and down arrows to choose the order in which you want the periodicals to appear in the box. If you add another title the top periodical would drop off.

Now you need to go to Site Building, blocks and in the disabled blocks you will see this block you have created listed, under the heading 'Queue'. Select right sidebar. Configure this block Choose English as the language, then add a title such as Periodicals, then under Custom theme add the style you want such as full border with angled corner (right column). Tick for network members to see it and to show only on selected pages. Click on Save. In this example, the word more appears under the five periodicals, which we don't want to appear. Hover over the block and click on Edit. In the basic settings go to where it has the heading More link: yes, click on this and remove the tick. Save.

 

 

.

How to upload an audio module

Audio modules for IofC are usually podcasts.

If you see any other field sets not mentioned below please ignore them.

Go to Content Management, Create Content, audio. (The MP3 file is attached to a node). This module will read what is on the file embedded in the MP3, such as the artist, date, album etc.).

Leave the Title box [ ...] [...] as it is for now as it will be filled in automatically later, once the name of the artist and title field have been added. Add the name of the Artist and the Title of the music. Click on Add a new audio file Browse to find the music you wish to upload. Leave the check box ticked to allow visitors to download the music. Save.

 

 

How to upload an image

To upload an image, go to Content Management, Create Content, image. (Information about the image is stored on a node.)

If you see any other fields not mentioned below please ignore them!!

You will come to a form. The first box Image is where you browse on your computer for the image you wish to upload. Ignore the tick box that says rebuild derivative images. Date taken: today's date automatically goes in but you can click on the box to choose another date, either by typing it in or using the calendar. Format: choose the original format it came in, e.g. digital. Title: add a short title. The Description is the caption that will appear under the photo (please keep short). Ignore split summary at cursor. The Photographer box will show a list. If a new photographer needs adding, you will be able to add a name and wait for the administrator to approve and check that the name isn't there already. Keywords: add new keywords if they are not there already. You can type in the beginning of a word, such as Ca and words with Ca will come up such as Caux. Check this box should be ticked. Under comment settings is a drop down choice, allowing network users to leave comments on photos, such as more information about the photo etc.

Click on Save.

 

Naming conventions

Blocks

The name should be as distinct as possible to make its content/purpose clear. If the block is displayed on only one or a very few pages, this should be stated in brackets at end of the block name, e.g. "In Brief (homepage)"

Views

The name/title of the view should be as distinct as possible. For example, a block which shows titles of latest three news items should not be called "news" or even "latest news", but something like "news_latest_3".

Translation for Blocks, Menus and Taxonomy

Blocks, Menus and Taxonomy use string translation.

User interface is distinct from content. The menus or admin screens are part of the user interface, not content. It is necessary for the user to navigate the website, e.g. The Search button.

In Drupal there are over 4,000 strings, which are pieces of text of one word or a paragraph. Drupal has a string translation system. All English strings can be translated, if we wanted them to be. We can use translations others have already done.

Go to Site configuration, languages. You will see code, native name, direction (only Arabic goes right to left), default (each configuration will have a default language). The French will have only French, the Dutch only Dutch. Each site will have its own list of languages.

Go to Site Building, Translate Interface. Under Built in interface it tells how many strings are in English (483 at moment), for Arabic 1621 have been translated. The default is back to English. This is a user only interface, the language groups will decide on this.

Click on “Search” the box “String contains” is case sensitive. Copy and paste the text.
In languages – this helps to limit it.
Click built-in interface and click on search.

You will then be able to see the languages this is already translated into.

We will use menu translations only for menu items in user menus.

For the top menu we will have different menus for different languages.

Taxonomy translations

Each vocabulary can have one of four settings:
None. No multilingual options for this vocabulary
Localize terms. Terms are common for all languages but their name and description may be localized.
Per language terms. Different terms will be allowed for each language and they can be translated.
Set language to vocabulary
. The vocabulary will have a global language and it will only show up for pages in that language.

Some of our vocabularies will be set to the second option, which allows translation via the translation interface.

Multilingual blocks

A block can be assigned to language as follows:
All languages’ : it displays whatever language is active
All languages – Translatable’: the block displays in whatever language is active but the translated content of the Block body is displayed if there is one in the active language. (Note: the whole content of the block body is made into a translatable string, and if that text is updated the English string is updated, but of course not the translations.)
A specific language: in which case the block only appears if the language is active.

We can use Translatable blocks for some important blocks which appear in all languages (e.g. the In Brief block on homepage, but otherwise mostly language-specific blocks.) When adding a block webmasters shoud select only their own language, not All languages translatable!!

Here is an example:

Go to list of blocks and select in Brief and configure. You will see that it is in all languages (translatable) - the block displays whatever language is active but the translated content of the Block body is displayed if there is one in the active language. 

The block can be in all languages.

The content of the block body is content, but using string translation system. We want this block in all languages so we want it translated. There are 2 ways of doing this:
We could mark it as Engish, but it would only display on the English site, and not be translated. What would be better would be to have one block, made translatable. Therefore we would not have lots of blocks, but this will only display if translation exists, otherwise it would display in English. So use with care as mustn't forget to follow through with translations.

Go to Site building, translate, search – search in blocks and edit.

The Search form cannot be translated when you click configure, this was provided by Drupal.

Site building, menu
Top menu
If we have 7 languages, there are 7 top menus. Menus will be blocks, each set to language of top menu. The menu items are set to the language. If you add an item to the top menu, the French have to do the menu item and new page or translation of a page.

Brief overview of translation issues:
http://www.developmentseed.org/blog/2008/feb/26/drupal-i18n-saga-continu...

Translation for Nodes

Blocks, Menus and Taxonomy use string translation. A node which may be translated uses a different way of translating.

The link “About Us” always points to one node. The menu system points to different pages.

We will use translation for the network menu. For example, if you want to find a network member in the contact database, you go to the search page. There is only one page, the only difference is that they'll see different userface instructions in different languages. Therefore we do want to translate the menu item for that.

When we add content we do want translaton.

For each node type (content type), you can specify whether multilingual support is enabled, without or with translation also enabled. If translation is enabled, when you edit a node there is an extra tab ‘Translate’ which lists all enabled languages and allows you to manage translation sets of the source node. So we can decide if the node needs translation, e.g. Node type, person profile, last name, spouse, kids etc. Names are language independent as you don't want these translated, they are language neutral. You therefore wouldn't enable multilingual. So for each of the content decide which needs to be multilingual.

We would want an article to be multilingual. So we enable multilingual support.

We would want to enable translation and when translated a new node is created.

If a page has a translation, the drop down list of languages shows only those other languages for which there are translations.

The following is an example:

Create an article by going to create content and selecting article. Type in a title and add some content and choose language and save. Click on Translate screen. You will see that English is the source. Now translate it into French – by clicking on French add translation link. Translate title and body and save.

If the source is changed considerably it will mark translations as needing updating, possibly by an email alert.

Users

Go to User Management - Users. This will give you the full list of Users. Drupal tends to work with user names, password and emails. The user can be active or blocked. You can filter the users to show who only fulfil certain positions. So in the drop down list you could filter, e.g. by comment, - administer comments and press on filter.

For example, click on Edward P's name and edit – you can't remind him of his password or know what it is, passwords are encrypted and can't be unencrypted. You can't have a reminder sent, the user needs to reset his password and generate a new one. An email would be sent with a new password which the user could change.

The person's status is blocked or active, you could block them here.

The language for emails can use changed here too.

Don't worry about theme.

Locale settings – you can choose default time zone and dates and times would be shown in that zone.

Now go to User Management, Roles

There are three roles. An anonymous user is not a person identified to you, it is a catch-all to describe any visitor, browsing but not logged in. We could know their IP address and which pages they visit, that's all. It is important when you come to permissions that you only allow anon visitors to do certain things, not looking at confidential material.

Go to User Management, Permissions

Anonymous, authenticated and network are the 3 basic permissions. Scroll down to node module -
anon and authenticated are ticked, network and authenticated already, that's why it isn't ticked. It is best to control things by membership of groups. In this same box you will see rows of create, deleted and edit.

Create – you only want network members to create. Authenticated users can only have the basic permissions without approval. They might be able to create an article but not given authority to edit any. They could edit their own article, and create their own, but might not be given permission to delete their article. They would not be given permission to edit others articles. The webmaster would be given a role where they could create paths, editions, other content. They would have different settings.

Our roles are going to be granted within a domain, so a webmaster could be a webmaster in the global website but if they went to the FFF site they would not have a webmaster role in that domain. We would have to go to FFF website wembaster screen and given that person permission. You can only do roles on one particular website.

In the User screen you see all users on the screen, but a role is applied within a domain.

Views

There are a lot of configuration issues relating to Views, and this section will attempt to gather them together.

Views are ways of aggregating content to display sets of content in one place. E.g. news articles aggregate into a list on a news page.

Views can be created to display as a Page, and/or as a Block which can be positioned like any other Block.

If you choose 'List View' as the 'View Type', you can choose which field(s) display via the 'Fields' section.

Filtering is the key to determining what displays.

A note about whether an item displays or not: if an item is 'Published', it will by default display in a View. If that item is 'Unpublished', it will by default still display, but when you click to read the full item there is a message saying 'You are not authorised to access this page'. If you want your item to NOT display in the view when unpublished, add a Filter 'Node: Published', and then unpublished content will not display in the View.

'Sort criteria' - choose 'Node: Created Time' and Descending if you want the most recent item to display first in the list.

Webmaster Menu

To look at the Webmaster menus go to Site building/Menus.

The admin menu for the site administrator is different to the webmaster role. Admin role is for someone else to keep track of technical things on website.  Click on webmater menu.

The webmaster block on left hand side has 3 roles at moment – blocks admin, views admin, menu admin, but eventually it will have short-cuts to different roles, e.g. add content.

Clickon Blocks admin. You will then see a list of blocks. In the one that is called webmaster menu click on configure. This block will be seen by specific roles. Under role specific visibility settings the webmaster role is ticked for this specific role.

 

 

 

 

Blocks

A block will usually be placed in the left or right hand columns of the page. Blocks can be dependant on the user's role, whether they are given permission to see and do things. Whether or not a block is visible depends on the role of the user and their privileges. For example, the user may choose to see blogs. Another example could be a block that displays the title of the last 10 news items anywhere on the website. Webmasters in particular would find this unseful, with for example the UK webmaster seeing articles on the Australian site, the Canadian site, etc. if desired.

To help you understand this better, please lookat "Eyes on IofC" block on the right hand side of the homepage. To do this go to Site Building at very top of homepage. Under this select Blocklist. Here you will see a list of all the blocks availbable. Under the heading Right side bar, go to Eyes on IofC and click on configure.

Scroll down the page a little and you will come to Block specific headings. Click on Block specific headings if it is not already expanded and you will see more information on that topic – this is called a Toggle where it can collapse and expand in a cycle through 2 or more activities. Some links are collapsed by default, so as not to confuse the user if they are unlikely to use them. If you are likely to need to use the heading then it will be open.

When this block was created the the Block description was "Eyes on IofC block on homepage”. Eyes on IofC, is an administrative name, not seen by the visitor. There will be many blocks so it needs to be precise, e.g. “Eyes on IofC block on homepage”.

The Block title is shown to the user and are the words that appear, in this example “on IofC”.

If the heading has an orange asterisk next to it it is mandatory to fill it in, if there isn't one then it is optional. So block titles don't necessarily have to have a name.

The Block body is the main body of the block, giving the text of what you want to appear in the block.

Under Custom visibility settings you can decide on the appearance of the block, with lines, shading. In this block "full border with angled corner & eye (right column)" was selected.

In Custom specific visibility settings the webmaster can decide whether to allow each user choose whether they want to see the blocks on the page, e.g. whether to have a block on the right hand side that shows the next 3 events or the latest three comments, or new members of my group, etc. The user can decide what blocks are on show by hiding those blocks when they go to their account and choose. This is not an option for all the blocks, and users would not be able to control this particular Eyes on IofC block.

The box that says Show block for specific roles is where a specific role is given e.g. the Administrator is given permission to do things. A team administrator is another example, or a team. There will be quite a few new roles, e.g. Group adminstrator, data administrator, webmaster. A webmaster could give permission for someone to have a role. The new system will have a lot of websites with roles in them. The roles will be given within a domain or website. The display will be limited to people who have this role.

The Page specific visibility settings box decides which pages the block appears on. The third option, “Show if the following PHP code returns TRUE (PHP-mode, experts only)” is not to be used, it is only for programmers.

Under Pages you can add the path of where the block should appear - for the homepage you type in <front>, for the About Us page you type in about.

Go back to the list of blocks and look at the Search block. This is like a dynamic block, created by Drupal. We can't edit the text of the block, all we can do is choose where it appears. You will notice that we can only delete some of the blocks, but the rest can be disabled. These blocks are automatically on the page.

Adding a block

Example of adding a block on right hand side:

You can add a block on the About Us page by going to the Site Building on the top black menu and clicking on Blocks. Then you will see the word “Add” near the top in the centre.

We are going to add a block about the international leaflet onto the About Us page.

If the heading has an orange asterisk* next to it it is mandatory to fill it in, if there isn't one then it is optional. So block titles don't necessarily have to have a name.

Block description: IofC International leaflet for About Us page
The Block description is an administrative name, not seen by the visitor. There will be many blocks so it needs to be precise.

Block title: Download IofC International leaflet
The Block title is shown to the user and are the words that appear to the person visiting the page.

Block body: Insert: Across the divides… With operations around the globe, our programmes target strategic opportunities to create change. Different situations call for different approaches but all our projects are driven by the purpose of building trust across the world’s divides.
Block body is the main body of the block.

Custom theme: you can decide on the appearance of the block, with lines, shading, though in this case I left it as “none”.

Custom specific visibility settings: Leave as it is.
Each user can decide whether they want to use the blocks on the page, e.g. whether to have a block on the right hand side that shows the next 3 events or the latest three comments, or new members of my group, etc. The user can decide what blocks are on show by hiding those blocks when they go to their account and choose.

Show block for specific roles: don't change this.
e.g. Administrator, given permission to do things. A team administrator role is another, or a team. There will be quite a few new roles, e.g. Group administrator, data administrator, webmaster. A webmaster could give permission for someone to have a role. The new system will have a lot of websites with roles in them. The roles will be given within a domain or website. The display will be limited to people who have this role.

Show block on specific pages: Show on listed pages only, in this case “About” - so click on “Show only on the listed pages”. The third option, “Show if the following PHP code returns TRUE (PHP-mode, experts only)” is not to be used, it is only for programmers.

Pages: the path would be “about” so simply type in about.

Click on save block

You will then see that your new block is in the disabled block. You need to select right sidebar and it will then move up to the blocks in use. You then need to decide the order of the blocks - you can drag and drop by clicking on the cross in the left hand side of the name of the block and keeping the mouse depressed until you have selected where you want it to appear in the blocks list.

Then click on save blocks.

There are different types of box style, e.g. With border line around a block, a grey bar, an angled corner. So you need to select which style you want.

Custom theme: go to add Block and you will see drop down list for custom theme. These are the different styles

No style – no lines, only text
Top border line – line at top
Full border line – lines all way around text
Angled – angled corner
Shaded green box – shaded green box

You cannot share blocks with other sites, though they can be cloned. You could share the content of the blocks by copying and pasting information in them.

A lot will be dynamic content, e.g. Latest 8 comments, you can control the style, not the content.

How to create an Edition

Before you can add an article you need to add an edition from a drop-down list. We are going to create an edition of Disha in this example:

So to create an edition, go to Content Management in top black menu, create content, edition.

Quite far down the page you will see a drop-down list for Periodicals: select Disha

For the Title at top use whatever formula is being used, e.g. Disha Volume 20, Number 1.

In Edition date. click on it and choose date.

Leave edition description blank.

For Language select in this case English as Disha is in English.

In the Body box you might not put anything.

It will be sorted by edition date, not post date.

Save the node. Then, if an article is created it would have an option of which edition to appear in.

How to add an article of a Periodical to an Edition

A periodical is in most cases a newsletter or magazine, like UK Initiatives or Disha. Each must have an edition to add it to. Disha, for example, has several editions or issues, which can appear as January 2008 or Vol 3 No 7. Articles then appear in these editions.

To add an article go to Content Management in top black menu, create content, article. Select language, edition number, add title, date and body of text and save.

Adding a View

NOTE: there is an excellent 30 minutes screencast introducing Views at http://www.masteringdrupal.com/screencast/new-features-in-views2/play.

A View is a way of presenting information in the database, it is a way
of providing listings according to certain criteria and orders. It is a
user interface which enables non-programmers to present complicated
data. A view is a dynamic listing of contents, very similar to dynamic blocks in old system.

Go to Site Building, Views and click on Add. You will see a list of all the views that
have been configured. Most of these have been created by Drupal. Click
on "Add" in the box near the top.

The View Name is for admin purposes. We are going to use the example add latest_3_news_title.

The View Description used here
is latest news from homepage.

The Tag is an optional way of sorting,
making it easier to find - you could add news for this example.

The View
Type
is a Node, click on this and then click on Next.

Near the top of the page you now see, on the left, is the heading Defaults. We want
to display it as a block so select block and click on "Add
display
". (If you were wanting to create a page for articles to appear on, then select page instead of block, e.g. a list of editorials).

You will notice that a red block appears under the Live Preview, which is telling you that you haven't finished!


Block settings
appeared when you clicked on Add. You need to add a
description for Block Admin description of latest 3 news items and update it. Now you will see
at the top the name of the block.

Ignore cache

The Filters determine what data is shown. So click on the plus sign by
Filters and you will see a large box below, called Blocks: Add
filters
. In the Groups drop down select Node - the display will
automatically change. Then click on Node Type and click on Add.


Operator
is one of or is not one of - you have the choice of the node
being one of or not one - in this example we want to select is one of Article so tick on that. You also need to select Article from the Node type and then click on Update.

Add another filter and go to Taxonomy in the drop-down list of Groups and then select Taxonomy term ID, click on and then select News - udate this and it will appear in
filter at top.


S
ort criteria select Content, content date:article date and click on add, then click on descending.


Fields
are where we specify which bit of items in the list we want to
display. e.g. Author, country, photo, teaser. Fields could have several
rows. Click on the plus sign and then go to the box below which says
Defaults: Add Fields. Click on Node, then Node Title and click on Add.

You will see a box that says Label: Title - if you left this the word
Title would appear in front, so clear this. In the second box it says Display field as a link to the full node - tick this as we want it to be a link to be seen. Update.


Items to display box
– the requirement is to have the latest 3 news headings, so we need to alter the amount of 10 to 3 . Click on the number shown and go to the box that allows you to change the number to 3. Save.

We want to edit the title of the view to be latest news. Click on
Fields, then click on Node:Title and the box entitled Label opens. Delete the word title from this as you don't want the word Title to appear and then update and click
on save.

View settings – how the view is listed in the admin list. (don't worry with this)

Under Basic settings, Number of items to display- if this was set to 0 it would
show all of the editions. You could click on use pager if you wanted to
number pages.


Relationships and arguments
– leave this as it is advanced!!.

Tutorials

This section is devoted to various Drupal tutorials we are creating.

Groups as Roles

Introduction

This tutorial was inspired by an article "HowTo: Segment your site with access control" - see http://drupal.org/node/153686. But we take things a little bit further, describing a solution with even more fined-grained control using the same taxonomy-based approach. This first tutorial addresses the 'groups' functionality in our requirements. A second tutorial, to be ready very soon, will add powerful multisite functionality using exactly the same approach.

We need a solution with the following requirements:
  1. Separate content area for each group or department of an organization (private zone)
  2. Members of a group must be able to create any type of content
  3. Assign writers and editors to specific sections of an online publication, or create a locus of collaboration for each of organization's clients.
  4. Access to some content on each private part must be able to be limited to a group of people. Groups need to be able to have their own Group pages.
  5. Anonymous user can see only content marked as "Public"
  6. Authenticated user can view and create "Public" and "Restricted" content.

What all the above scenarios have in common is that they require access control--that is, access to certain parts of your site must be restricted to certain users.

In order to satisfy the group requirements you might come up with a pretty solution based on the Organic Groups family modules, installing at least 2-3 additional modules.

This tutorial describes an alternative, probably cleaner, solution for groups using the core taxonomy module and the contributed taxonomy_access modules

When building a site you must consider future changes and upgrades to next Drupal releases. Therefore it is better to use as much as possible from the Drupal core and as few as possible contributed modules. The updating of contributed modules can be very slow and sometimes the author of a module might even abstain from upgrading his module for a newer Drupal release.

This tutorial assumes a reader has a basic knowledge about drupal system.

Implementation

This tutorial will describe how to build the required solution step by step. There are 6 steps:
  1. Install Drupal.
  2. Install Taxonomy_access module.
  3. Categorize the site with the taxonomy module.
  4. Create user roles and assign users to the newly-created roles.
  5. Set role access control with the taxonomy_access module.
  6. Test.

The rest of this tutorial will use as an example a company website (example.local) that will have site areas and content for two groups : finance department and planning department. The goal is to restrict editing of each department's area/content to members of that department. But also we need to restrict the visibility of some content only to department members, other content to general authenticated users in the company, while some content should be visible on the homepage of the company website.

1. Install Drupal

The process of Drupal installation is described very well in its INSTALL.txt.

This tutorial is written for Drupal 5.x version

Thus we are not going to go here into details. Make sure you have installed Drupal, created a database and you have successfully created the first user (username 'admin')

2. Install the taxonomy_access module

We need this module to achieve a fine-grained access policy for our departments. In the folder where you have you drupal files go to the sites/all folder and create a new folder "modules" here. Download (http://drupal.org/project/taxonomy_access) and extract the taxonomy_access module in the newly created folder. This tutorial is based on the dev version, taxonomy_access-5.x-2.x-dev (http://drupal.org/node/153216). This newer version introduces some important SQL optimizations, which drastically reduce the number of database records required for sites with a large number of terms and roles. The admin interface has been updated to allow you to keep your access rules lean and mean.

Login as your admin user and go to Administer > Site building > Modules. Tick taxonomy_access checkbox and click "Save configuration" button. That's it.

3. Categories

Next we are going to categorize the site with the taxonomy module. If you are not familiar with it, the taxonomy help page explains simple usage of it. Go to administer > content management > categories

3.1 Groups

First we will define a vocabulary that will contain our groups (departments). Create a new vocabulary "Groups". On creating the new vocabulary make sure you select all content types you want to be categorised by terms in this vocabulary (e.g. Page, Stories) . Leave 'hierarchy' disabled for now. You can build your groups hierarchy later. Check the "Multiple select" checkbox - this allows nodes to be assigned to more than one group (required in cases where you want your content to be available to more than one group).

Then add new terms in your Groups vocabulary. First is our Finance department and second is the Planning department. That is it for groups. You can extend this vocabulary as you want.

3.2 Access

Now we are going to declare levels of access using another vocabulary. Create a new vocabulary and name it "Access". On creating this vocabulary make sure you have selected the same content types as you've done for the Groups vocabulary. Disable 'hierarchy'. Check the "Required" check-box - this assures that every node must have at least one access level.

Add the following terms:

  1. Public - A node marked as "Public" will be visible for anyone in the world (anonymous users)
  2. Restricted - visible only for Authenticated users
  3. Private - only group members can see it.
This vocabulary just declares our Access levels. Next we are going to define them and make it all work as each term indicates.

4. Create user roles - and users.

Before defining our access policy we should add one more component: Roles.

In this tutorial we allow an authenticated user to create stories. Edit the role "authenticated user" (administer > user management > access control) and give it these permissions: "access content", "create story content" , and "edit own story content".

"Groups As Roles": there must be a one-to-one relationship between the terms in our Groups vocabulary and corresponding roles. We need a role for each of our groups.

Go to administer > user management > roles and add two new roles:
  • "group - finance" - Assigning this role to a user we will make him a member of Finance Group
  • "group - planning" - Assigning this role to a user we will make him a member of Planning Group
These groups are just simple labels so far and we are not going to assign any permissions for them.
Don't forget about users. Create two new users in your system:
  • username: 'accountant' (choose your own password) - and make him a member of the Finance group, by giving him the "group - finance" role.
  • username: 'manager' - and make him a member of the Planning group, by giving him the "group - planning" role.
For testing purpose add one more user. He should not be a member of any group: username: 'user'. Do not assign any role. All registered users have the authenticated role assigned by default.

Your User's list should look like this.
5. Set role access control with the taxonomy_access module
First read the module's documentation, that will help you to understand things better. (Administer > Help > Taxonomy Access Control)

Go to administer > user management > taxonomy access: permissions. You should see a list of roles registered in your system:

5.1 Permissions for anonymous user.

Rule: By default, an anonymous user must be denied access to any content which is not categorised as "Public".

Click on "edit" next to "anonymous user." There is a drop-down list box at the bottom just above the delete and save buttons. Select the "default" item under "Access". Set View to Deny, and for Update and Delete, set Ignore. Untick the check boxes for Create and List. Press the "Add" button and "Save All". Removing the ticks for Create and List mean he cannot create nor list any content categorized by the Access vocabulary.

This is the default access policy for an anonymous user. We just denied him access to any categorised content. But we need to give him permission to see content from the "Public" category. Thus, we need to define an exception to the above "default" rule.

Select "Access - Public" in the drop-down list. Set View to Allow, and for Update and Delete, set Ignore. Untick the check boxes in Create and List. Press the "Add" button and "Save All". We have granted access to view "Public" content. You might set "List" checked, then your visitor will see a "Public" link in each node. But we removed it because visitors should not know about our access categories.

Your screen should look like this:

5.2 Permissions for authenticated user

Rule: All authenticated users are allowed to access, create and list "Public" and "Restricted" content, but not "Private" content, unless a user is member of a group. Users should know about all groups existence.

Next, go back to administer -> user management -> taxonomy access: permissions. Click on "edit" next to "authenticated user". We must explicitly define grants for all access levels for this role, because all registered users have this role by default.

Select "Access - Private" in the drop-down list. Set View to Deny, and for Update and Delete, set Ignore. Untick the check boxes for Create and List. Press the "Add" button and "Save All".

Select "Access - Public" in the drop-down list. Set View to Allow, and for Update and Delete, set Ignore. Tick the check boxes for Create and List. Press the "Add" button and "Save All".

Select "Access - Restricted" in the drop-down list. Set View to Allow, and for Update and Delete, set Ignore. Tick the check boxes for Create and List. Press the "Add" button and "Save All".

And we must let our users to be aware about the existence of groups. Select "Groups - default" in the drop-down list. Set Ignore for View, Update and Delete. Tick the List check-box only, and untick the Create check-box. Press the "Add" button and "Save All".
Your screen should look like this:

5.3 Permissions for groups.

Rule: Group members must conform to the access policy defined by the "authenticated user" role. But additionally they must be able to access, create and list "Private" content assigned to a group of which they are a member.

A user cannot become a group member unless he is a registered user of the site. Once a user registers and joins a group, he receives permissions given to the "authenticated user" role and those given to the "group - NAME" role as well as grants (defined in taxonomy access) for each role.

Users with multiple user roles: Allow/Ignore/Deny options are interpreted only within one user role. When a user belongs to multiple user roles, then user gets access if ANY of his user roles has the access granted. In this case, permissions for the given user are calculated, so that the permissions of ALL of his user roles are "OR-ed" together. Meaning that Allow will take precedence over Deny.

First we define grants for the "Finance" role/group.

Go back to administer -> user management -> taxonomy access: permissions. Click on "enable" next to "group - finance".
Select "Access - Private" in the drop-down list. Set Ignore for View, Update and Delete. But tick the check boxes for Create and List. Press the "Add" button and "Save All".

But our rule requires that a user should not be allowed to create content in a group of which he is not a member. Therefore, select "Groups - default" in the drop-down list. Set Ignore for View, Update and Delete. Untick the check boxes for Create and List. Press the "Add" button and "Save All".

But a user must be able to access, create and list all content of his group. Select "Groups - Finance" in the drop-down list. Set Allow for View and Ignore for Update and Delete. Tick the check boxes for Create and List. Press the "Add" button and "Save All".

If you want your group members to be able to edit content written by other members in the same group, you might set Allow to Update in that group. Or you might define a new role (group-finance-admin) for that and configure grants within that role. But here we keep it simple.

The result should look like this for your Finance group.
Repeat the whole process for the Planning Group. Go back to administer -> user management -> taxonomy access: permissions. Click on "enable" next to "group - planning". Use the "Planning" item under "Groups" in the drop-down list now.

After you have finished, the result for Planning should look like this.

6. Test

Let us now see how it works.

 

To make it easier to see how it all plays out, let us create a block with a list of our groups. Each item in that list will be a link to the content of the corresponding group.

 

Go to Administer > Site building > Blocks. Click on the "Add block" link. In the "Block description" field put "Groups". Then put the following PHP code inside the "Body" text-box:

 

<?php
$vid = 1; //The vid is the vocabulary id of the Groups we wish to list the terms from
$items = array();
$terms = taxonomy_get_tree($vid);
foreach ( $terms as $term ) {
$items[] = l($term->name, "taxonomy/term/$term->tid");
}
if (count($items) ) {print theme('item_list', $items);}
?>


Below "Body", expand "input format section" and select the "PHP code" option. Click the "Save" button.

Next define a region for this new block. Choose "left sidebar" and set the Weight to 1. Click "Save". Add a block title by clicking "configure" next to block. Put "Groups" in the Block title field. Save.

Your block should now look like this.

Log in as the "accountant" user. Click on the "Create content" link. Then create a story. Being logged in as the accountant user (member of Finance group) you can see only "Finance Group" in the Groups list box. The accountant user cannot create any content in other groups.

Fill the Title text box, select Finance Group in Groups list-box, and make this a Public announcement by selecting Public (anonymous users) from the Access drop-down list. Write something in the Body text-box and submit it.

Log out and check if the anonymous user can see the new story.
Then, if you create another story and set Access to "Restricted" your public site visitors will not be able to access this story. Only registered users will be able to - including Our "manager" and "user".

Next try to create a private story.

In this case, neither "manager" (a member of another group) nor "user" (simple user) nor anyone (anonymous user) from the world can access the private story, only Finance group members.

Conclusion

It is important to remember that the "areas" you have created are really an abstract thing. A node is part of an area simply by virtue of its categorization.

Everything described here was fully tested. A database dump with the configuration described in this tutorial is available for download and import into your own database. (This configuration assumes you have put the taxonomy_access module in the ./sites/all/modules/ folder.)

We would be happy to answer your questions related to the approach described. But we also ask for your feedback on this approach, whether it has advantages over others, or whether there are problems we have not realised.

Soon we will have a second tutorial showing how to extend this approach to create a multisite installation.

Policies

We need documents outlining policy in regard to all kinds of matters.

Blogs

IofC Guidelines on Blogs

The content of personal blogs is the sole editorial property of their author, but personal blogs on IofC websites need to reflect the spirit and ethos of IofC. The following overview and guidelines need to be respected by IofC bloggers.

Blogs are personal in nature and the most popular blogs in the ‘blogosphere’ tend to be stongly opinionated and often controversial.

IofC blogs should also be personal and should reflect the spirit and ethos of IofC. In particular:

  • The line between good and evil runs through every human heart - so bloggers should avoid attacking or condemning individuals or groups of people, while being free to condemn evils. Frank Buchman never wrote anybody off, always holding out for the possibility of change.

  • Change starts with me. Before pointing out where others need to change, look first to see if there is a similar issue in you own life or your own community. Be clear that you are willing to apply the same standards to your own life and community that you ask others to apply.

Blogging is about discussion. Treat all who engage you in dialogue with respect, even if you strongly disagree with their views.

Blogs take different forms – some comment on the news, either general news or news in a very specific field. Some are more like personal journals, following the ups and downs of a person’s life and struggles. The important thing when starting to blog is to find your unique voice and then be consistent. Readers need to know what to expect.

Some examples of different types of blogs:

Personal journals:

http://www.karencheng.com.au/

http://redpen.vox.com/

http://www.greensahm.com

Comment on the news

http://www.huffingtonpost.com/

http://andrewsullivan.theatlantic.com/

http://stuckon-stupid.com/

Eclectic collections

http://www.boingboing.net/

Combination of personal and news comment

http://www.nathanrice.org/

Specialized news blog

http://www.treehugger.com/

http://gigaom.com/

http://www.slashfilm.com/

Religious/Spiritual

http://www.progressiveislam.org/

http://methodius.blogspot.com/

http://thebuddhistblog.blogspot.com/

 

 

Commentaries

Vision and Aim

Our overall vision in offering these commentaries is:

  • to help establish IofC as a network of people with something distinctive and important to say, which is not only intellectually satisfying but also personally challenging;
  • to demonstrate a unity of purpose which transcends our human differences;
  • to offer a resource to media people on the look out for fresh thinking and experience.

Individual commentaries aim to offer one or more of the following:

  • a distinctive moral and/or spiritual angle on the issue being addressed (often a topical one, in the news headlines);
  • personal experience, pointing the reader towards a practical step of personal change we could each take;
  • a constructive approach which helps to build respect and trust between people on opposing sides of a conflict or debate.
  • a challenge to the thinking of those on all sides of the issue being addressed.

Guidelines for Authors

  • Commentaries should be written in the spirit of Initiatives of Change, and seek as far as possible to present a distinctive angle, and some practical personal experience.
  • Commentaries should be between 500 – 800 words, but tending towards the lower figure.
  • They should be written with a non-IofC audience in mind. Assume no knowledge of IC by the reader.
  • Aim for the highest writing standards possible, and seek help if needed.
  • Consult, to the extent possible, with others in the fellowship who may offer a perspective on a particular issue that would enhance the commentary.
  • Take care to ensure that any facts presented are properly verified.
  • Avoid expressions of political opinion. Be careful to ensure that any language used might not be construed as racist, sexist, or ageist.
  • Be particularly mindful of the need to avoid language that could be considered finger-pointing, overly judgmental, or divisive. We should all seek to present our thoughts and ideas in such a way as to build bridges and promote honest conversation whenever possible.
  • Commentaries should bear in mind a global audience; please avoid overly technical terms or modern jargon that is particular to one culture.
  • Your piece will fall under the terms of the Creative Commons Licence used on our site, UNLESS you specifically ask to retain the copyright. Under the terms of the CC licence, texts may be reproduced without permission on condition that they are properly attributed, are not used for commercial purposes, and that if there is any alteration to the work it may only be distributed under a license identical to this one.

Guidelines for Editors

  • If it is your on-duty week (one per month) you have an obligation to respond. If it is not, you are free to respond if you have time, but are not obliged to.
  • Editors are responsible for ensuring that the commentary is written in a spirit which will enhance rather than diminish IofC’s objectives. It may also be appropriate to run the draft past others in some cases, where the subject is related to a particular area of the world or of expertise.
  • Editors should read commentaries with an eye toward:
    • Whether the commentary reflects the spirit of IofC
    • Whether the commentary reflects, to the extent possible, the values of honesty, purity, unselfishness, and love.
    • Whether any facts and quotations given in the commentary are watertight
  • Editors should focus on the predominant message and tone of the commentary. This does not mean that they have to agree with all that is expressed in it.

Weekly methodology

  • Draft commentaries should be sent to the co-ordinator for that week, and not to the editorial board. They should be submitted not later than one week ahead of the Monday publication deadline.
  • The co-ordinator is responsible for sub-editing the commentary, if needed, to ensure grammatical and spelling accuracy.
  • The draft is then sent out to the editorial board on Tuesday, reminding the on-duty editors of their particular responsibility. The co-ordinator may need, if the commentary tackles a difficult area of the world or topic, to send it immediately to a few in our global work who have long-standing knowledge of the region or issue involved, and/or may come from different perspectives on the issue. If the balance of their response points to non-publication (i.e. editorial improvements alone are not sufficient, in their view, to enable publication) the commentary should not be published.
  • Editors should respond to the co-ordinator within 24-48 hours. These responses should go to the whole editorial board unless they concern small subediting points, in which case they only go to the coordinator.
  • The co-ordinator feeds back to the author any comments likely to be helpful. The author is given time to work further on the piece, before submitting the final version to the co-ordinator not later than Saturday evening.
  • The co-ordinator sends it to the webmaster for posting on site on Monday.
  • This schedule needs to be flexible when circumstances require it. Where possible, commentaries on delicate issues should be given extra preparation time.
  • In the final analysis, the commentary co-ordinating team are empowered to make the decisions about editorial changes and/or non-publication/removal of a piece.

Comments

Policy on Comment writing

needs writing 

Data controller

Policies for Data Controllers

Data user

Policies for data users

Email addresses

IofC email addresses are provided for bona fide IofC users.

Mailboxes have a maximum size of 300MB.

Email list creation and management

Need a policy with criteria for the creation of new email lists, and the requirements in terms of management/administration/moderation.

Group creation and management

To be written

User Terms and Conditions

Terms and conditions for Users

Information on the extranet is not to be used for any other objectives than those of the publisher, Initiatives of Change International (assuming those objectives are visible somewhere), nor are files or other information to be uploaded except for the purposes of serving the objectives of IofC international. All decisions on whether these terms have been abused rest with the Editors on behalf of the publishers.

A history of the project

This section provides a chronological record of the project, why and how it started, from beginning to end. Some material in this section is duplicated in other parts of the documentation manual, but this section is designed as a readable, user-friendly narrative.

The story up to June 2007

In mid 2002, IofC decided to take forward its web development strategy in a major way. Up to this point, its internet presence had been patchy. There was a global website consisting of just a few static pages, in four or five languages. Some IofC national bodies had websites, but they were on the whole minimal and there was no branding consistency. This was not through any fault on the part of the technicians and editors who did their best to produce quality sites - but there was a lack of priority given by IofC to the internet, and inadequate resources invested.

In September 2002 a small team started work in Oxford: Jit-Mun Chong, a brilliant technician from Malaysia, took a year of unpaid leave to base in Oxford and do the programming; Eve Wojciechowska, a graphic designer from Canada already living in Britain, took on the visual work; Edward Peters, a jack-of-all-trades-and-master-of-none, undertook the team leadership.

In retrospect, we achieved the impossible! Jit-Mun worked far too long hours and produced our first website in less than three months - a standalone 'Extranet' (login) website to serve the needs of IofC's worldwide network. This site was programmed from scratch, and included some high-end features. We had started with a vision of a fully integrated content management system and this was the first step.

By the middle of 2003, we had a public global website in seven languages, and a few other public sites for national bodies. It was a heroic effort!

Jit-Mun returned to Malaysia after his year out, and was succeeded by Vitalie Cracan from Moldova. Vitalie had little programming experience but being a brilliant mathematician he quickly became an expert programmer - and stood at the heart of our web team for the next four years.

The second iteration of our sites (achieved in 2005) was the integration of all the public websites into one database infrastructure – with major benefits in content sharing and in speed of new site development.

The third iteration (on which we were working since 2005) involved a migration to a new, more solid architecture to carry the weight of an integrated Extranet (with its more specialised functionality) as well as the public sites, all in one system.

In mid 2007, however, it became apparent that our little team was too small, and not skilled enough by itself, to complete the third iteration in the way we had envisaged. Eve had moved on in 2006. And although John Freebury (Canadian, with considerable technical and community experience) had joined us in 2005, we were having to face the fact that the retirement of Vitalie was presenting major challenges to the sustainability of our whole web project.

We came to the conclusion that we could not continue as we were going, and needed to take stock.

After initial dismay at this reality check, we came to see it not as a failure, but as an opportunity to embrace a new vision of how IofC’s web needs were to be met.

Clarifying the direction

After some weeks of research we reached the preliminary recommendation that we should change our approach completely. Having been attempting to build a proprietary system, using our own dedicated personnel, we decided that the way forward involved engaging with an Open Source CMS project and community. Advantages of this approach includes:

  1. Access to much completed programming which would save us time.
  2. Access to a worldwide network of technicians who share learning.
  3. Future sustainability more assured.
  4. An opportunity to contribute to this online community, offering to others the benefits of our own experience of the past five years.
  5. A faster way to network with other NGOs which are creating similar systems to meet their needs.
  6. ‘Open Source’ fits well with IofC’s ethos of sharing and community-building.

Drupal was recommended to us as one of the best CMS projects available. Our initial look at it confirmed that it might have most of what we needed. But there were other CMS fameworks to consider....

After some research, it narrowed down to a choice between Drupal and Joomla. Each had their advantages. If you want to read some details of our assessment read our article Assessing and choosing Drupal.

It was a difficult choice: firstly to abandon our proprietary system after so much effort, and then to choose Drupal. We knew it would place limitations on us, mean sacrificing some of our ideas, and involve compromises. But going with Drupal also mean embracing many good new ideas, and would give us significant advantages in terms of adherence to standards, access to core functionality which is time-consuming to programme, participation in a worldwide community of developers, and the capacity to stay close to the leading edge of web development.

Getting started on the Drupal project

At its AGM in August 2007, IofC's International Association agreed to increase the 2008 web budget to make possible a one-year project to move IofC's web infrastructure into the Drupal framework. Nevertheless, the available budget was small for a project of this size: around $US30,000 plus 60% of the project leaders time.

To understand the scale of what was being attempted, you need to review where we stood at mid 2007:

  • 15 or so 'public' websites, all sharing a codebase and and run off the same two mysql databases, and grouped into
  • One 'private' site for IofC activists (the 'Extranet'), with its own codebase and database - though a good deal content shared with the public sites.
  • Integrated email lists running off the main Extranet contact database (one email address per person, kept up to date!) synchronised with the Mailman mailing application for multiple lists.
  • Full CMS system for management of content on all sites.
  • Etc etc

Reconstructing all this - and adding desired new functionality too! - in Drupal was going to be a big task. And we soon realised that the learning curve for Drupal is very steep.

John Freebury began the autumn in Moldova, where he had been based for half a year, but moved to Oxford in late September to work more closely with Edward. We were fortunate, meanwhile, to find a systems analyst in Moldova, Pavel Capcanari, who was able to commit up to 20 or so hours per week to work on the project with us. He brought to the team some important skills which others of us lacked, and we began to design the project.

Having spent five years previously developing a web application with little advance planning or documentation - working things out as went along - we were determined to do it differently this time. We recognised that the first months would need to be spent in careful preparation.

Where have we got to?

We are now well into the planning process. We have drafts of the requirements documents, including the long outline of 'Functional Requirements'. The next stage is to prepare the 'use cases' which detail exactly what users need to achieve through the steps they go through on our sites. I am getting started on this, and it may take between now and Christmas to get these all ready.

Meanwhile, Pavel and Vitalie are researching solutions for our multiple-sites-and-groups needs. This is the biggest issue we need to crack, as we are attempting a complex configuration, with many sites and groups and languages all working off one codebase and one database. There are no ready-made solutions yet in Drupal which meet our needs, but there is a new module 'Domain Access' which, together with its extension modules, might take us a long way - even if we end up having to programme our own module(s) to get all the way there.

John is deep into planning the process of data migration which is a huge and complex task. Fortunately, a Drupal expert who gave us some training ten days ago, shared a brilliant way of migrating data. Instead of mapping old database fields to new database fields, you use the Drupal form API as an intermediary. Thus we do not have to understand the Drupal database structure entirely, so long as our old fields are correctly mapped to the right fields in Drupal forms - and the Drupal execute function writes the data to the new db structure.

It is far too early to say, yet, exactly when we will be able to roll out the new system. We envisage a Phase One release next summer or autumn...

At times I get discouraged, as the planning takes so much time. But I think it is wise to plan carefully. It will save time in the long run. And we must remember that we are building an infrastructure which we hope will serve the needs of IofC for many years to come.

Archives

Pages no longer current or useful to us, which we don't want to delete.

Menu system

It takes a while to understand how the menu system works. Here are a few tips:

Each menu item has a

  • Title (the word/s which appear in the menu)
  • Description (the phrase which appears when you hover over the menu item
  • Path - if url aliases are enabled you can overwrite the default inserted by Drupal
  • Expanded checkbox - if ticked, any child menu items will be displayed
  • Parent dropdown
  • Weight (-10 is highest, 10 is lowest in the sort order)

When you create a page you have a section where you can link the page to a menu item which will be created with the page. So be careful not to create a menu item and then create it again with the page!

It is possible (depending on theme) to place a menu in the left column outside a fixed width website (e.g. the Nokoala theme used in our Profect website) which is only visible to authenticated roles. Easiest is to place the Navigation menu block there, and create a separate menu for the Public menu links.

Newsletters: configuring and sending

This tutorial refers to the 'Simplenews' module

Definition of terms: 'Newsletter' is used to denote a type such as 'Monthly Updates', 'News from our site', or whatever, not an actual 'Issue' of a newsletter. You create a Newsletter, add Subscribers to receive it, and then send Issue(s) to that list of subscribers.

After installation, there is a 'Newsletters' section under Content Management in the Administration. It has five tabs:

  1. Sent issues:his shows issues that have been sent, and can be filtered by Newsletter.
  2. Drafts: if you create a new Issue (via Create content) but do not send it, it will appear in this list, allowing you to work further on it, and send it when it is ready to go.
  3. Newsletters: this lists your newsletter(s), and there is a link to add a new one.
  4. Subscriptions: this lists your subscribers and can be filtered per newsletter. There is a link to 'Import subscriptions' where you can put one or more email addresses to add, making sure you choose which newsletter(s) to add them to (if you have more than one).
  5. Settings: only Plain Text can be sent with the default installation. If you want to be able to send HTML, we have to install the Mimemail module and configure it (see: http://drupal.org/node/112669). This allows you to choose the default (whether Plain Text of Html), and also to override that when creating the issue itself. There are other settings, both general and per-newsletter.

To send an issue of a newsletter, go to Create Content -> Newsletter issue. You have to choose the Newsletter to send to (if more than one) and you can also choose whether to send immediately, or to send to the test email addresses which you stated under Settings (point 5 above), or whether to send later (which puts it under Drafts, point 2 above).