@DStrine @Ejegg we only grab fiscal due to MG requirements - we could add calendar year when we add extras for MG?

@CCogdill_WMF I just put up a patch for review but it will require you to add 2 new fields to Silverpop

@MBeat33 so per my email 'Email' is a custom field - the correct field is 'Primary Email' & in fact it isn't case sensitive - odd.

Thanks heaps!

@hashar do you have a sense of when - ie. is this something that might happen next quarter or is that unrealistic?

@MBeat33 I just gave the 'Donor Services Management' role 'Administer CiviCRM' permission - see how that looks

@CCogdill_WMF @MBeat33 this data should be up to date now

@MBeat33 ok - that was weird - I just cleared caches & it came back but I haven't seen that happen before - the dashlets I'm just looking at. You mean report dashlets on the front page? If so I think @CaitVirtue will be pleased to know you care about them since they sponsored work to make them work behind a firewall a couple of years back - without htat you wouldn't have them

@MBeat33 @Ppena @Jksamra We have populated cancel_reason & payment_processor_id into the civicrm_contribution_recur table & you can view the results in the report - what else do you need here

@CCogdill_WMF yes it is - probably a few more days - we have about 1.2 m contacts this way

@Reedy @hashar -our live server was recently upgraded so it's using php 7.0 so it would be good to get our tested onto it so we can start using different php syntax & have our tests run on the same version as live. So yes, ideally the 2 jobs you mention would be on php 7.0 as soon as is practical

@Ejegg @Jksamra just looking into end dates vs cancel dates. I believe that we are not winding up with recurrings with an end date but no cancel date now. Historically we have quite a few

@DStrine - that's pretty much what the lists are at the bottom of that page - I feel like we use/add them reliably when it's an upgrade to Civi - but perhaps not when it's an ops upgrade that affects Civi - which might be a gap

We have now populated cancel_reason for those recurrings historically cancelled via payment processors and are recording information as it comes in now. The ones we backfilled from historical data have the work 'backfilled' in the text. You can see the results in this report

@CCogdill_WMF So the way they can be later identified is they are added to a group within Civi called 'Silverpop imports' (id = 310) - the underlying assumption is that any contact imported from Silverpop is an RML because they only get into Silverpop via Civi (in which case they have a contact id) or by being an RML contact

@MBeat33 is this all good now?

@CCogdill_WMF I think the silverpop group was maybe created for this purpose? IE. we can only ask Silverpop to send us a group of contacts by using a group ID from silverpop & from previous comments it seems that was the group for the purpose. I believe the logic is that anyone without a contact ID is by definition an RML & hence in that group until they get imported into civi

@CCogdill_WMF I think the way it works is we are retrieving a group of contacts in silverpop with no civi contact id. Once they are in civi they will have a contact ID & I think that means overnight they will be removed from the group in silverpop - ie the silverpop group is 18468760

@CCogdill_WMF before I schedule this it would be good to double check with you if the remembered logic above is right

OK - I see why - for some reason our schema is missing a change

@NNichols So for some reason when you created those fields the db field is_locked was set to true - I've changed that & you can proceed but I'll try to figure out why

All done

We actually have this

@MBeat33 We deployed an update

@CCogdill_WMF OK this is coming back to me - the idea is that we grab contacts in group - 18468760 - which looks like maybe about 2258700 contacts are in it based on the row count in the downloaded csv. These then have a contact id & that is uploaded to silverpop - at which point they are no longer in the group 18468760 in silverpop - does that sound correct?

Just looking I find this group has 434091 contacts

Checkbox now added - we can add logging during the outage

@CCogdill_WMF it looks like Ops Do have another outage need so this should be able to be done then - @cwd @Jgreen hopefully this is on your radar

@CCogdill_WMF I would open that as a new task or subtask to make sure it doesn't get missed

I am going to a sprint in June where Tim (civi core team who wrote this) will be there - would be good to get this done in May so I can poke around & discuss any issues with him

these have stopped. Could be a number of reasons (incl server updates & civi updates) - closing as I think we are 'present-focussed' on failmail errors

also it we make changes we should keep @Ppena informed based on recent emails

@LeanneS is this good to close

@LeanneS is this good to close

@LeanneS @NNichols -good to close?

I did some work on this already - getting the hover & the modified date (or was it the created date) into prominence on the merge screen. I have been tinkering a bit with other ideas on the url-generator screen as it's easier to work there than to edit the core screens & all sorts of limits disappear in that context

I just pulled this into the sprint as I started working on it when I was moving around last week & I have something to try testing on staging. I also have used the same page to test ideas for 'upgrade dedupe merge screen' as it's easier to develop ideas on a new page than to hack the existing page as the code is pretty hard going.....

This is now deployed - if you want to search for one of our public benefactors 'The Montgomery Family Foundation' you should now just search for 'Montgomery Family Foundation'

@LeanneS I fixed that report - I also added a fix so we should see this stop happening.