I'm excited about building a module that, if designed properly, would useful to others. I see how it might be useful for the development of a human resources department for personnel reviews and really any place where reports or static documents pass from one party to another.
I am building a community site based around an organization. We produce custom reports for many of the community members and provide them through a very simple and custom php app on our website. I want to move this to drupal to take advantage of the other powers to build community, as well as flexibility to improve access to these reports for archive purposes.
This has been floating around in my head for several months, but I've not developed a drupal module before so I crave review, comment and even participation.
First, populating the data
I have to deal with making this support the older system without creating more work. Currently, we FTP the reports generated by a local software to a server where it is picked up and handled accordingly. This is very little work on the users who have an app that does everything for them when they start it without even showing them an interface. They don't even know what FTP is, let alone what it does. Changing this would be bad.
I figure a separate app that, on a cron run, takes the contents of a directory and loads them into the database as nodes. I expect this would be best as a separate module, with the idea that others could create similar ones to handle the similar tasks. I figure a lot of good code could be found in this project http://drupal.org/project/import_html.
I'd also like the individual user to be able to add individual reports that have to do with them eventually, but that isn't one of my initial needs. It is something I'd want to consider in the design, but not really code up for the first version. Of course, this probably will be as simple as creating a content type which would happen as a result of coding the rest. Drupal is looking like a really good solution! :-)
Second, characteristics of the data
We have reports that are monthly, quarterly and yearly. We also have reports that go to and from a variety of departments. I'd need to track the type of report, report name, date of submission, date due, report sender, report receiver, department of interest and maybe some other things. It would probably be good to have the sender and receiver have the ability to contain more than one user, and maybe even an entire role or group.
If I understand correctly, CCK will provide me with the flexibility I need on this. I'll just need to have the module depend on CCK. I guess some of this would be more taxonomy than CCK.
Third, display of the data
I expect, using Views, that I can organize displays of the reports to show an archive of past reports by type or perhaps even a calendar list of the reports. Some templating of the reports node would make sense, is that a function of the module dev or the theme dev?
Fourth, privacy of the data
I need to protect the data to ensure that the report sender and report receiver are the only ones who can view the node containing the report. Some data can occasionally be private. We'd assume that the reports are private. Perhaps an optional checkbox could be used to easily extend the module to allow public reports. I'm not sure how to best accomplish this. Perhaps one of the TAC-like modules or ACL, Content Access could do it simply. I'm not entirely comfortable with my ability to make this decision because I'm not sure I understand the different approaches as well as their strengths and weaknesses. Additionally, I'd like to develop this in a way that any security module could be dropped into place and work fine, without complicating the user interface.
Conclusion
If I understand my problem correctly, I expect what I really need to do is glue together Views, CCK, Taxonomy and some permission module into a package that meets this need. I plan on waiting for all these to pieces to be ready for D6 before I try to deploy anything. I'd really like to hear from others about what they think of this and if anything in their experience would identify a problem or potentially another method that would be easier. I'm especially interested in how to handle the privacy of data, but comments on anything would be appreciated.
Finally, I need a better name. There is already a "Reports Module" which was my first choice. I'm not sure "User Reports Module" sums up the idea succinctly. Your ideas are welcome. :-)

Comments
Kinds of data
What kinds of data are you planning for the report?
Matt Farina
www.innovatingtomorrow.net
www.geeksandgod.com
www.superaveragepodcast.com
www.mattfarina.com
Each of the reports I'm most
Each of the reports I'm most interested in providing are currently individual HTML files. In the future there could also be a collection of reports in a CSV file or individual reports in a CSV file. They could also take on the form of a PDF file. Whatever format our various softwares (some of which are due for change) put out. There is also the serious potential of syncing/summarizing data between Drupal's database and another SQL database. Then there is the potential for people to make reports built by typing data into a Drupal Form.
Should all these different kinds of reports be different content types? Is there a way to make them "sub-content types" of a primary (meta) content type?
Which are you looking for?
I guess I'm a little confused. Is the data the system going to store the html, csv, or other report? Or, is the the format that the system will produce the report in based on some other data?
Matt Farina
www.innovatingtomorrow.net
www.geeksandgod.com
www.superaveragepodcast.com
www.mattfarina.com
Perhaps I did more assuming
Perhaps I did more assuming than I should have on this. My plan is to import these into a node. I'd probably have several different modules that would handle the various different type of data imports. Each of these would result in the same type of format, a node. So once those modules are complete, all the data would be nodes and this module would deal only with nodes in the database.