3

The Overall Plan

I'm creating a staff "portal" area for a non-profit. In the future I want to migrate the current static front-end website to Drupal, so I thought it would make sense to develop this portal area as a custom module into the back-end Drupal administration.

About the custom module

The non-profit provides a Child Sponsorship program, allowing supporters to pay a monthly fee which pays the school fees for children in East Africa. So the idea of the portal will be that it will reduce the administration of staff by holding the sponsorship database online. The database is split into two: children who are sponsored and children on the waiting list. So I want to produce a module where each child is effectively a node. The node will contain sensitive information such as DOB, Address, School Exam Results etc and so isn't AT ALL for public viewing.

However, that when a child is added to the waiting list, a short bio will feed into the front-end website allowing them to be sponsored. This is one reason for trying to build it into Drupal from the beginning. In the future, it is also planned that when a user goes onto the front-end website, chooses a child to sponsor, they will be made a 'user' in Drupal, and given the ability to view certain information about their child such as a school report.

Questions

Is it conventional use of Drupal to build a module specifically for internal use where primarily the data is not for the public or front-end website? Is it an appropriate use?

To me it makes sense that each child functions as a node of content type 'child', however I'm worried about making them actual nodes.....as I said the data is private, and Drupal currently sets node public at URL node/{nid} What is the best solution moving forward with creating this database within Drupal? Could I make an equivalent 'node' style format?

Improve this question
1
  • 1
    It's a very appropriate use of Drupal to maintain data that is not meant for public or front-end website use. The idea of roles aids greatly in maintaining levels of access to data in Drupal (anonymous users get one level of access, authenticated users another, admin users a third, and you can add more roles as necessary). If, in the future, you decide you need even finer grained control, Organic Groups is great for breaking users and content into groups with a second layer of roles. It doesn't sound necessary for your project, but it's a good system to learn.
    – thirdender
    Commented Jan 1, 2013 at 23:53

1 Answer 1

Reset to default
7
+50

Drupal only sets node/nid as public when you give anonymous users permission to "access content". Additionally, you can use modules like http://drupal.org/project/content_access to specify what roles can access specific content types. Lastly, you can use http://drupal.org/project/field_permissions to specify what roles have access to specific fields on your nodes.

To answer your other questions, I don't think you need to write any custom modules to cover these needs and using Drupal to provide content only to privileged members is a very common use case.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.