CiviCRM Community Forums (archive)

Post your ideas for things you'd like to work on during the sprints.

The .extra.tpl feature doesn't work with the numbered directory appended (for specific events, profiles or contribution pages)

http://issues.civicrm.org/jira/browse/CRM-8467

Would be good to knock that issue off at the sprint.

I know this is a bit vague... but I'd love to see some work done to make it so that Joomla Plugins can utilize the "full power" of CiviCRM.

The biggest issue that I've personally run across is that there seems to be a slight disconnect between utilizing Joomla plugins to implement hooks while plugins can't (shouldn't?) install files outside of their own folders and thus can't write to the custom folders that are defined in Administer -> System Settings -> Directories.

Hooks help, but can't solve everything. For example, I can't see a way to use a Hook to implement a new Name Badge. As far as I can tell currently, that file HAS to be in the custom folder.

I know you could "just" copy the file manually... but it would be real nice to be able to install a plugin via the Joomla admin and it would do everything: add any custom fields needed, install the necessary hooks, add the appropriate name badges, reports or whatever to the right menus and so on.

Conversely maybe this is more a task for an expanded CiviCRM Extensions system (since my understanding is that right now that only supports new payment processors, reports and searches). Either way I'd rather not have to muck around finding the right directory to install stuff into if it can be handled via an extension (Civi) or plugin (Joomla)

Matt

P.S. While I'm wishing... I'd also love to see the Joomla 1.7/2.5 Extension Manager be able to upgrade CiviCRM using the Upgrade button without "outside help".

With Kellie Brownell from EFF, we've been discussing work on CiviCRM documentation related to designing CiviCRM before first use - how and where to create custom fields in order to have a proper foundation for future data entry/import. We are planning to divide the documentation based on CiviCRM modules and use case scenarios.

We are still planning this piece of work so any suggestions are welcome.

The goal is to provide "how-to" documentation so that organizations are aware what they need to consider when "planning CiviCRM database" - what I mean by that "planning CiviCRM database" is recognizing the data an organization wants to put into CiviCRM and then recognizing what modules should be used to record that data and what custom fields (and assigned to what entities) should be created.

Kasia

Some issues I'd like to look at are:

1) Standardising BAO crud functions (for better API integration - the first step is to agree what they should be).

2) Figure out how to get tests to 100% & keep them there - this probably involves running tests on all branches with active development & having a regular email going out with the status of tests so that people are aware when they break something rather than someone having to do diagnostics later (when the people with knowledge of that bit of code may no longer be about). This is about people & processes rather than just technical stuff.

3) Refactor Activity Assignee & target into activity_contact to make queries more efficient

4) Look at Some improvements to CiviReport (do a bit of an audit for some of the inconsistencies & look at using the 'building block' approach I have tended to use where joins & columns are defined as external functions. http://issues.civicrm.org/jira/browse/CRM-9501). I'll certainly want to look a bit with Deepak but would be good to have other inpur.

I am interested in ACLs with regards to their interaction with Joomla.

I have a project coming up where I'll need to make sure that CiviCRM ACL Groups are linked to Joomla ACL Groups so the interest is entirely selfish

In the above case, in a perfect world, the CiviCRM smart group that contains all the participants for a given event will sync up with right Joomla group so that we can then grant access to DocMan folders (a Joomla component) that contain documents related to the event (speakers notes, schedules, etc) using the Joomla ACLs. Right now I don't see any linkage between Joomla and Civi ACLs so what I might end up doing is checking the participant status change in a post hook and when the participants status is "Attended" or "Registered" adding the Joomla user to a group that matches the ID and Name of the event (creating that Joomla group as needed) but that feels like a hack.

I'm on board to help with the new CMS-independent extension system and directory.

So, still on the API being able to leverage BAO functionality better - would be good to be able to send receipts from the API - kinda tricky to extricate though - CRM_Member_Form_Membership->postProcess is 600 lines long - does anyone else think that's too long for a single function?