Hello! I created a module which is similar in concept to customreports, yet takes a different approach, and wondered if I should start my own project, or merge it with yours. It basically provides a simple hook for modules to generate and optionally store their own downloadable CSV reports with a common UI.

If you're interested, take a look at the attached module, throw it into a test site, and look at the README.txt for instructions on how to use it.

I could go either way. I'm happy to create a module at the namespace of "custom_reports", and I'm equally as happy to become help maintain customreports and merge the two modules. They seem close enough in scope, and they should work together to give users and module developers easier tools to generate reports (which I frequently find easier to do in a custom fashion than trying to smash the requirements into Views).

CommentFileSizeAuthor
#2 custom_reports.zip10.29 KBjoelstein
custom_reports.zip9.39 KBjoelstein
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

geerlingguy’s picture

The UI would be very helpful to me.

joelstein’s picture

FileSize
10.29 KB

Here's the latest version of my Custom Reports module. Please give it a quick look (especially the README.txt), and let me know if you would like me to merge this into your module. If not, I'll create my own.

geerlingguy’s picture

Looking over everything, there are some very useful features in joelstein's version; I would really like if the modules could be merged, rather than having another 'competing module' (not really, but that's how many would see it) on d.org.

snufkin’s picture

I have a few problems with this.

First of all I don't really see how the features provided with this module would conflict with the ones in customreports. Customreports allows you to get the results of sql queries from nodes into cvs files. Your module provides an API so it can list all reports provided by a module (from the code) downloadable in one location. The reports coming from customreports are done in the node level, so I am not sure how we would go, or want to go with an integration.

Secondly, your modules is an API module. The best would be to keep it at that. Provide an api, no features as a separate project.

Third, the namespace. customreports holds this namespace, and while you could create a project called custom_reports I would ask you not to as it would just make people confused about what the respective modules offer, which one they want. Instead I suggest you rename the module, perhaps to reports_api?

I can imagine customreports leveraging your API later on to somehow provide all its reports in one location, but I don't think merging the code is a good idea.

joelstein’s picture

The features don't conflict, you are correct. But since the purpose of the two modules are nearly the same, I thought it would be useful to merge them into one, so that users aren't confused as to which custom reports module to download. I'm happy to do all the heavy-lifting to merge the two together, and to jump on board as a maintainer as well.

If you still disagree with me, I'll give up, and start my own module. Thanks.

snufkin’s picture

I've asked a_c_m to take a look at this issue and comment, I couldn't grant you commit rights even if i thought that merging is a good idea.

I am not trying to tell you off, dont misunderstand. I am looking at the most effective development path here and I don't see the benefit in merging for either of us. You could maintain your module more easily if you dont have to deal with all the other functionality that this module provides, and the same applies to us. And yes, this module might benefit from your API, but we could as well just ask for your module as a dependency.

All I would ask is that you chose a better/different name to avoid the confusion.

a_c_m’s picture

Assigned: Unassigned » a_c_m

Sorry for being a bad module maintainer - i will take a look at this this week and get back to you. For some reason this never ping'ed in my queue.

a_c_m’s picture

Assigned: a_c_m » Unassigned

Ok, so looked over the code and more or less came to the same conclusion as snufkin. The module looks like a nice api way of storing reports and it would be great if customreports could be extended to use its functionality if the api module is installed (but i dont think it should be a dependency).

If you were interesting in improving customreports to work with your module, i would welcome that - however i think, again as snufkin said, your module is better named reports_api or something like that and left as an API for modules like customreports to use.

I too would ask is that you chose a better/different name to avoid the confusion and namespace pollution.

apaderno’s picture

Issue summary: View changes
Status: Active » Closed (outdated)

I am closing this issue since the project doesn't have versions for supported Drupal versions.