- Each user has a private space for reports visible and editable by that user alone.
- Users can copy any report that they can access into their own private report space.
- Report listings do not show user-private reports, except those belonging to the current user. (This includes civicrm/report/list; I'm thinking it will be hard to block these reports from the CiviCRM navigation menu, and the simplest thing might just be to disallow private reports from being added to the navigation menu.)
- Any user-private report must refuse access by users other than the owner.
- Users must have CiviCRM's "edit report criteria" and this module's "administer own CiviCRM reports" permissions to use these features.
I like the idea, and have experienced similar needs. One other possible solution to consider --
We could create a reserved flag for reports, which has it's own permission. Similar to how reserved tags and other reserved elements work, such objects are locked down unless the user has the reserved permission. For reports, I would envision that flag preventing people from updating reports. If they have the permission to alter report criteria, they can still "tweak" an existing report on a temporary basis, or save as a new report instance, but may not update the report they are working working with.
The end result is similar, but it approaches the problem from a different perspective which might be easier to implement. The challenge I see with having "user-owned" reports is that you're not just dealing with vertical permissioning (user can't promote a report to be a site-wide report) -- but also peer-permissioning (Jane can't modify Jim's report, but can she see it? Can Jane see it but Fred not see it? Can Mary edit it but Fred not see it? Can Alice the admin modify and save it, as well as promote it?). That would be a useful feature, no doubt, but definitely more work, especially as you work out the implications on navigation, report listing, dashlets, etc.
That sounds like a nice option, the reserved one....I would probably prefer that one.
Adding a "reserved" flag to reports seems like a good way to layer some additional benefit on top of user-private report management. I don't think it would replace it entirely, since it adds only one more level of access: currently we have "administer reports" as a boolean permission, and this adds only one more boolean permission "administer reserved reports."
Peer-permissioning of user-private reports is a great thing; although it multiplies the complexity of the work, it might be worth it.
It may be time to start considering a page-and-folder oriented design, as the number of reports is starting to outgrow the menu. Proprietary systems often boast over 100 standard reports. The permissions thing could use a bit more granularity too. Bob the Development Director runs 8 different versions of a contribution summary report each month. Susie the Membership Director needs to run the same reports, and occasionally make one-off changes for her needs. Bob would have options for each report like 'visible to everyone', 'visible to me only', 'editable by everyone', 'editable by me only'. This means Bob can make his report visible, but not save-able. Now Susie can leverage Bob's work, and even make changes to criteria as needed, but she can't overwrite his reports. Instead, Susie can start with Bob's report instance, change the criteria, and save it as her own if needed.
I realize talk is cheap and code is gold, but my skills are in SQL and Crystal (I'm actually a report developer by day). I worked several years in tech support for a proprietary donor CRM that is considered the industry 'gold standard'. I'd be glad to talk design (or even create a detailed functional spec) and share things I've seen work well (and not so well) if that's useful. Side note, I'm willing to write the SQL for new reports if stored procs are allowed and there are some requirements in Jira.
the fact that you are willing to work on the design / spec makes the code aspect a lot easier. I think code/design/documentation/tests are the equivalent to code in terms of gold status :)
Wanna do a detailed post on the forums with a design proposal or two. Might be good to think about "report templates" vs "report instances" (including using different / better terminology), permissions and structure / hierarchy that will scale for us going forward. We have approx 30-40 reports now, so i suspect we'll get up to 100 in the next few releases
Once the above is moving, we can potentially think about making report creation even easier
Sure, I'll work on a spec proposal over the Christmas holiday and post on the forums. Is it better suited for the Feature Requests or Developer Discussion forum?
since you are going quite a bit beyond a feature request :)
we can iterate on forum and then if someone wants to develop it, we'll move it over to wiki as a more formal spec
I haven't forgotten about this. I have a lot of projects at my day job and run a nonprofit at night (which uses CiviCRM). In between, I've been writing up a spec of how CiviReports could behave and creating mock screenshots of the user experience. I'm continuing to make progress and will post on Developer Discussion when I'm close.
Allen, I appreciate your blogging and creative solution and agree that creating the right set of reports for a variety of larger organizations is generally not a solvable problem.
From my experience most larger commercial CRMs or association management software either (1) build their own reporting solution (2) integrate in a reporting solution such as business objects or Crystal. I think long term having a good integration with Jasper, the largest open source reporting tool makes sense for CiviCRM.
We've take this approach with our larger clients either by installing Jasper or allowing them to integrate Crystal or other reporting solutions that they already own. With larger organizations they generally have some report building skill sets and with a little data model training they will be able create most all reports themselves.
We like Jasper (and our larger clients like Jasper) because it has a very large community, the largest install base, excellent tools, seems seamless to the report users (they think it is part of CiviCRM)and we find it easy to use for most clients with "access skills".