CiviCRM Community Forums (archive)

Hi,

We are working on a new function "petition". that would mean some entries in the navigation menu, new tables in the database, more access rights...

My initial idea was to create a new component, like report or civimail. However, I have some practical issues here and there:

1) Not sure how to "register" the new component, seems to be into the
common xml GenCode bit, not something you can put separately ?
2) Not sure how to alter the menu to register new urls
3) Not sure how to alter the navigation to register new items

I looked at SFS, might be easier to go the drupal module road ?
http://civicrm.org/node/624

More generally, should we aim at making easy(ier) to extend civi from within, like on
sugarcrm and hopefully getting more features that can easily be added ?

It seems to be easy (some issues still as described by lobo), but this means that joomla won't get as much features as drupal, eg they won't be able to get the petition module.

What do you think ? Is there a way to avoid it ?

X+

There is already a Civi dependent Drupal petition module that might give you a head start:
http://drupal.org/project/petition

1) Not sure how to "register" the new component, seems to be into the common xml GenCode bit, not something you can put separately ?

I’m pretty sure Michał did quite a lot of work on creating a component base; I’ll get him to reply here, but in the meantime check out the (dummy/example) Touchstone component in CRM/Touchstone.

2) Not sure how to alter the menu to register new urls
3) Not sure how to alter the navigation to register new items

As Lobo says, getting hooks for these would be a great first step.

Xavier,

1) Not sure how to "register" the new component, seems to be into the
common xml GenCode bit, not something you can put separately ?

Most of information about creating and registering new components in CiviCRM is here: http://wiki.civicrm.org/confluence/display/CRMDOC/Creating+custom+components. Basically, once you have CRM_Petition_Info class ready (use CRM_Contribute_Info as an example), you just need to add an entry to civicrm_component table and you're ready to go with the rest of implementation.

Thx,
m

Hi!

Is there somewhere a more explicit howto on how to build a new component?

I know http://wiki.civicrm.org/confluence/display/CRMDOC/Creating+custom+components, but it doesn't really answer all questions!

I would like to try to do some where basic "webmailer" into CiviCRM - just for my own need, a crude and simple version just for handling one mailbox. Most is of the needed parts are allready in CiviCRM (reading the content of an IMAP mailbox, sending mail, mail activities) - but I can't do the first steps.

What I don't see is:

- How do I add my component to CiviCRM without adding a entry into the database by hand?
- How do I add my component into the top menu?
- How may I use CiviCRM-Hooks from inside a component, not an module?
- How do I add new tables without doing the sql from outside CiviCRM?

What's the best way for an hobby programmer with only a small knowledge to get some CiviCRM knowledge?

Bye and Thanks
Marcus (aka Tiggr)

Hi Xavier!

Not quite sure what the goal of a webmail within Civi is, but let's try to find a way to add a module

A bit offtopic:

Webmail is perhabs not the right word for it! It is about the "support-mail"-inbox. We are a small team of 3 people, using CiviCRM (yeah, a really small application of CiviCRM - but CiviCRM is really great even for small jobs). We have one email-adresse info@....de, and I want all of us to be able, to read and answers mails received at that inbox. It should be possible to read and answer form everywhere (home, work, mobile computer, ...) - that's why I want to have a webinterface. No problems with firewalls, no installations, just open the browser and start to work.

And everybody of us should be able to see the whole communication done with one contact, all phone calls, emails, meetings, no matter who has done them.

So I'm thinking about a small component, fetching mails from the mailbox per imap, showing them as simple list. I want to have the possibility to read them, reply to them, and attach them as activity to an contact.

Have you looked at CiviReports or other components? I think the best way is to look how others are done and imitate.

Of course, I did! ;-)

Quote from: Tiggr on March 11, 2010, 04:13:45 pm

- How do I add my component into the top menu?

I don't think it's possible, I haven't seen any registrerNavigation() in Info.php
(or other method)

That's where I ended too! Digging through the code gave me the impression, half of the infrastructure for this is allready in CiviCRM, but not enought to use it allready... but I may be wrong about it.

Bye
Marcus (aka Tiggr)

Hi Xavier!

For what I see, it works pretty well already (bin/CiviMailProcessor.php), but it might need some tuning, on how to find the proper contacts, and who to assign it to and so on.

I thought about bin/CiviMailProcessor.php too! But we do only one hobby workshop a year. (I told you, we are a very small CiviCRM-Application! ;-)) So there is a huge part of mails of a more private nature. I don't want to have these inside the CRM automaticly. And some of our participants use changing mail adresses (at home, at work, ...) - so I want an alternative way to attach a mail manualy as activity to a contact.

Do be a bit more honest: I'm modelling this a bit after the model of how such common mail adresses are handled in Microsoft Dynamics CRM. We implement this at work at the moment! ;-) They call such "group mailboxes" Microsoft Dynamics CRM queues.

If you have a logic of "helpdesk", it might need some dashlet or equivalent to see what requests are on the pipe.

Does it make sense ? What do you think ?

Yes, that makes sense!

But because of our small application, and seeing, that I'm no programmer, I decided to try to do one step after another. ;-) My first aim at the moment is: Getting the mail from the IMAP-Mailbox into the database, and showing them! Most of that is very new to me!

Perhaps we should go with this "incoming mail handling" to an new thread, not bloating this one!

Bye
Marcus (aka Tiggr)

1. yes as we move components to be self-contained, moving the templates/i/js/css files to within CRM/Component makes more sense. Note that within civicrm-drupal modules we are going with the above setup (i.e. templates within the module directory)

2. current images / css all share the top level namespace, i.e. CIVICRM_ROOT/i and CIVICRM_ROOT/css

lobo