Symphony.

Hmm not sure. I think it might conflict. Since you’d be customising your event PHP anyway, it wouldn’t take very much additional time to write the code to send an email using the mail() function.

All it needs to do is send a notification and include the jobID in the title and possibly Company name and Job Title from the form in the body of the email.. a link to the job entry from within the email would be pukka, but I’m not sure how to kick start customising the event for mail()

Do you mean the pre configured send() that is installed as an example with the core? Or am I missing something here? Also How would I go about editing events? using the file manager and workspace->events then edit the php directly?

Sorry send() should be mail()

Can EventEx handle members[login-details][username] as a handle? It appears to turn a example@comcast.net value into e.

Are EventEx (and Databasemanipulator and ADSC) compatible with 2.0.7?

I am getting an error when trying to execute an Event.

Argument 2 passed to ASDCMySQL::connect() must be an instance of resource, resource given, called in C:/Users/Nils/Arbeit/Server/de/obsessive-media/trac/extensions/asdc/lib/class.asdc.php on line 71 and defined
C:/Users/Nils/Arbeit/Server/de/obsessive-media/trac/extensions/asdc/lib/class.asdc.php line 240

235         if(isset($details->force_query_caching)) $query = preg_replace('/^SELECT\s+/i', 'SELECT SQL_'.(!$details->force_query_caching ? 'NO_' : NULL).'CACHE ', $query);
236         
237         return $query;
238     }
239
240     public function connect($string, resource &$resource=NULL){
241             
242         /*
243             stdClass Object
244             (

Edit: Dang, it has happened again. I thought I had the latest version but didn’t.

adsc on github was updated yesterday and works at least with 2.0.7RC1 (as required part of not yet published members extension)

How difficult would it be able to incorporate $eParamFILTERS? I need to do some custom error checking and I need the filter message in the XML to apply to the correct section. As is, it duplicates the filter error message for each section. My callback for the EventPreSaveFilter delicate looks like this:

public function customDBMS(&$context)
{

    if($context['fields']['waiver'] != 'yes')
    {
        $context['messages'][] = array('waiver', NULL, 'You must agree to the terms and conditions by checking the waiver box.');
    }

    return;
}

The resulting XML from EventEx looks like this:

<save-new-student>
    <entry result="error" section-id="15" section-handle="members">
        <filter name="waiver" status="failed">You must agree to the terms and conditions by checking the waiver box.</filter>
        <post-values>
            <title>Dr.</title>
            <first-name>Bob</first-name>
            <middle-name>David</middle-name>
            <relationships>59659</relationships>
        </post-values>
        <message>Entry encountered errors when saving.</message>
    </entry>
    <entry result="error" section-id="6" section-handle="students">
        <filter name="waiver" status="failed">You must agree to the terms and conditions by checking the waiver box.</filter>
        <post-values>
            <sex>M</sex>
            <date-of-birth>09/27/1979</date-of-birth>
            <waiver>no</waiver>
            <member>60288</member>
        </post-values>
        <message>Entry encountered errors when saving.</message>
    </entry>
</save-new-student>

Any ideas on a solution or workaround?

Any plans to update this for Symphony 2.0.7?

Any plans to update this for Symphony 2.0.7?

What needs to change?

What needs to change?

I’m getting an error about line 511 in class.general.php in reference to the getPostData() function which is called from event.section.php.

I’m getting an error about line 511 in class.general.php in reference to the getPostData() function which is called from event.section.php.

Please report if this commit solves the issue. Are you still looking for a solution for the comment posted above?

alpacaaa, thank you very much for the effort! I can’t test your solution yet because I’m launching the site live tomorrow. I’ll follow up with you later this week. Regarding my previous comment, I found a workaround for now. I simply filter each data source and get rid of the duplicate filter error messages with XSLT.

Cheers mate!

If you’ re still interested in find a solution for the previous issue, here’ s how I get it working. The problem should not be related to EventEx. Your code was lacking a bit of logic (at least for 2.0.7), this snippet should do the job. Be sure to change $fieldName accordingly to your section (waiver in your case).

Good luck! :)

alpacaaa thanks for looking into this. It looks like the commit you refer to might break backwards compatibility by no longer adding the post-values back into the event XML. Is this intentional?

alpacaaa thanks for looking into this. It looks like the commit you refer to might break backwards compatibility by no longer adding the post-values back into the event XML. Is this intentional?

Good point Nick, I completely forgot about 2.0.6. Fixed here: http://github.com/alpacaaa/eventex/commit/6573d2bc35a4dc40b9ba3ab344791a3c32cad040

But doesn’t this hide the posted-values for 2.0.7 as well? What I’m asking is why you’ve taken this out in the first place.

Oh, sorry. Yes THAT was intentional. Sincerly, that piece of code doesn’t make any sense to me now, but I guess it was necessary for 2.0.6. However, it duplicates post-values in 2.0.7.

I’m not sure if we’ve hit a development road block with the bug tracker ensemble (Bugaroo) being developed with Symphony 2.0.7. The front end form for adding comments to an issue requires that it also be able to change field values in the parent issues section. This leads me to believe that it will only be possible with the EventEx extension.

In our particular case, backwards compatibility with 2.0.6 is not a concern, but it does appear alpacaaa has covered this. Nick, should we forge ahead with the fix alpacaaa suggests, or should we be looking into another fix to ensure compatibility with Symphony 2.0.7?

In our particular case, backwards compatibility with 2.0.6 is not a concern, but it does appear alpacaaa has covered this. Nick, should we forge ahead with the fix alpacaaa suggests, or should we be looking into another fix to ensure compatibility with Symphony 2.0.7?

I haven’t had time to look into this but I need to look at what these commits are and why they are applied. It’s all very well and good saying they “fix compatibility for 2.0.7” but if they’re not accompanied by a note as to why they work (and indeed why breaking prior compabilibility for 2.0.6 is acceptable) this ain’t going to be accepted as a patch.

Thanks, Nick. That confirms my reservations.

I was thinking it would be good to have an ensemble that works as a demonstration of EventEx and Form Controls, similar to the reference ensemble for the Members extension. I’ll start with Symphony 2.0.6, get it working, then see if I can upgrade it to 2.0.7.