SMM had to do a few of these too. Security is tightened up a bit in 14.x.
We wrote a simple script to assign new people to the old reports.
This happened to us and I didn't quite twig it was inactive records. We have a 'Schedule' User for some of our reports (Membership Update Utility) so we can see the update was by the schedule rather than a specific user. As that is the only thing that record is used for it often becomes inactive. Does this mean that those reports will stop working when this happens?
Was this documented somewhere?
We have been experiencing this issue as well. It makes us look the fool to our promoters who expect these reports and they don't get them. We can only say so many times "Oops. It was a system glitch." before they stop believing us. We also have credit card billing utilities running that aren't charging cards as well. I'm very close to emailing Anna and asking if this is going to be fixed as part of the RAMP upgrades.
There a quite few odd little behaviours like this in v14 that have really caught us out and caused more headaches than a upgrade should.
Kelly, I'm curious, do you have some custom process that automatically inactivates users? We have loads of single purpose accounts like that, but I never worry about them being inactivated.
According to RAMP when I reported this issued for us last week, there was a back up in the queue of "our" report server. We were told it was fixed...but none of our reports and utilities fired this weekend. It wouldn't be so bad if they were just internal reports. But we have reports that are supposed to be going to promoters and we have credit card billing utilities running.
Same, we had to deactivate and recreate all of our Membership Update Utilities (for the consortium).
Nothing custom. That account isn't used very often.
Oh, so someone is coming along and manually inactivating it? I use the "location" field on user accounts to sort them by department, but also use, so I have a "Service" location, and any of my automatic scripts that manage user accounts know to treat "Service" accounts (not to be confused with the new "Service" account type in v14!) differently.
I've also just noticed that one of our scheduled reports in particular hasn't run since our upgrade. It's the New Contributions Report. Looking at its setup in the report schedule, it has fewer parameters than the one in the Development Reports folder right now. I keep wondering if this is an issue for just us, or if I've missed something because we had a super-quick timeframe to upgrade from 12.5 to 14.1.
That happened to me because I didn't notice that a scheduled report had been changed with an upgrade. You'll need to reschedule with the updated report.
It is indeed the fact that there were several security-tightening things in v14.0 that contributed to this. One was that we discovered that inactive users were still able to make REST calls and this was not a good security practice. I will admit that we didn't anticipate that reports schedules owned by an inactive user would fail and this certainly should have been noted in the upgrade notes.
Through digging Anna Wessely found that the issue for us was a stored procedure for the report server wasn't working correctly. I'm not sure if you all are RAMP clients or not. I would reach out in a TASK ticket if you are and ask them if your report server issue is the same as The Smith Center.
If reports scheduled by former employees are deactivated will that cause the report server to fail? Do the report schedules need to be deleted?
ThanksJess LevySan Francisco Opera
Hi Jess,
The other reports didn't fail for me. But we did need those reports scheduled by former employees, so I just wound up reassigning them to me in SQL.