We are building a new application and are just at the point of thinking about how all of the pieces in the real world might map to Drupal concepts and I figured we may as well throw this out there for comments.
The application is used to submit information from a person or business who has an existing relationship with us and they will be submitting information regularly. The information will go into a typical database of rows/columns for the purpose of summaries and reports but the full set of information is also publicly published. Think submitting your 1040 to the IRS if they also posted information about you and your entire 1040 online.
For this reason, we are thinking that each submission should be a custom content type.
The bigger unknown is how to represent the users and the association between multiple submissions. XYZ corp must submit one form per month so we want to have a view of all the content submitted by XYZ corp. XYZ corp has multiple owners or employees who may submit this document and have rights to submit documents on behalf of XYZ. They may have different roles such as only being able to save unpublished or the ability to publish/finalize the submission.
We are thinking that we can map this into a group for XYZ corp and have the persons submitting information for XYZ corp as drupal users. Some persons may be part of ABC corp and XYZ corp. Also the membership or association between users and groups changes over time and so we need a way to maintain the historical coupling. For example, some user Bob was a member of XYZ corp from begindate to enddate but isn’t any longer a member. The content is still associated with XYZ corp. We would want to be able to do some view filtering based on the temporal bounds.
Just throwing this out there. If you have any thoughts, seen similar patterns, know how they were implemented, etc. We would welcome the feedback.
Comments
Feedback
Hi James,
Not sure why you would need unique content types for each sub?
Sounds like the rest can be achieved with Rules and Taxonomy.
As far as maintaining the history there is an event tracking module. I would have to look into what that is it escapes me at the moment but if just capturing a history or relationships is the goal then that would work.
You may also want to explore Organic Groups as you mentioned the Groups this would give you a greater depth of roles and relationships "ready-made".
Good luck!
Let me know if I can be of further assistance in flushing out the concept.
RE: Feedback
Thanks Chris,
Only one content type, for now. I could have worded that better. For example, every company submits a form 123, one per month. Form 123 is a single content type.
For the history, Assume each company includes their employees on form 123. Each employee is a Drupal user. In January, Bob worked for xyz but not in February.
Activity Module
https://www.drupal.org/project/activity to track what users do / have done.
Some initial thoughts
I've seen/worked on similar things using entity and entity_reference fields. The idea is that you create user reference and node reference fields on a content type and make sure they get populated correctly using something like entityreference_prepopulate.
We have built a system where users submit essay contest entries that then get viewed by others that isn't unlike what you're talking about but probably not near as complicated as what you need.
Basic approach:
* Build an organization content type
* Build a submission content type
* Add an Organization entity reference field to both the user entity and the submission entity
This is basically the future of building stuff with d7 and beyond. Some of the entity stuff has moved into core, but not as of d7.
Here are some relevant projects:
https://www.drupal.org/project/entity - Provides good programatic api for working with nodes and user entities in an OO fashion.
https://www.drupal.org/project/entityreference - Provides a field type for conecting entities.
https://www.drupal.org/project/entityreference_prepopulate - Simple module for propopulating entity references fields that can be used with existing node creation forms.
Other people have different/better ideas?
RE: Some initial thoughts
Thanks Dave, Confirms that we are not completely insane.