1

We seem to have had several serious instances of loss of functionality when installing newer versions of CiviCRM. A lot of software projects have a list of breaking changes as each new version is released. Without an organized official list, I am afraid the developers might not actually be aware of breaking changes. The main losses (the ACL one filed as a bug) are:

  1. ACLs no longer work with smart groups (this was working for us as of ~4.5.6).

  2. ACLs don't even work with static groups anymore.

3. Bulk email, cron + CivicMail, no longer works. The cli.php cron method no longer works. We had bulk email working as of version ~4.5.6 using cli.php. I spent hours working with wp_cli recently on 4.7.4 and I can't get that to work either.

I would go back immediately to v4.5.6 if I could, but the schema changes to the database prevent this.

Edit: I fixed #3 -- I was missing the 'view all contacts' permission for the cron user.

Improve this question

2 Answers 2

Reset to default
3

CiviCRM does not have a "Known Issues" report per se, and I do not believe I have ever seen such a section in the announcement of a new release. What it has is JIRA (issues.civicrm.org), which provides many tools for tracking problems great and small.

This is where you report and track specific bugs; for example, CRM-17968 scheduled emails not processed is reported to be fixed as of 4.7.4. But you are also given many tools for navigating the issues according to severity, resolution progress, and anticipated correction. You can see planned releases, the Change Log of which fixes were applied to which versions, and recent progress.

Broken functionality is not always detected during pre-release testing. I think if the core development team knew critical functionality was broken, they would fix it rather than include it in a report. Helping test the beta versions, either on your system or on demo.civicrm.org, will help prevent the software from going to release with major unresolved problems.

Related: What should I do if an issue is marked as fixed in JIRA but it is still occurring?

Obligatory lecture: the installation and upgrade guide, for one, emphasizes that you should back up your databases before attempting an upgrade. Your organization should have its own change control protocols for releasing new software to make sure that critical functionality does not suffer, and the system should be tested thoroughly before moving it into production. Your inability to roll back to 4.5.6 is not the fault of the developers.

Improve this answer
7
  • 1
    Partly what I was worried about in posting this was that the idea or onus for breakage would be pushed back onto the users by anyone responding. OMG, "it's your fault for installing an upgrade!" That is what I think you are saying. I am an almost retired software engineer working for a very small non-profit. Personally, I have never been allowed to ship bugs -- really. Backing up the databases 8 or 9 versions ago does not help in the case of CiviCRM. I have made backups every step of the way. By the way, the testing should be done before versions are released -- and not be deferred to users.
    – P a u l
    Apr 6, 2016 at 4:29
  • If "Known issues" is another way of saying breaking changes then so be it. I am challenging the company to up their game.
    – P a u l
    Apr 6, 2016 at 4:37
  • No you are cool
    – P a u l
    Apr 6, 2016 at 4:40
  • 1
    Re: "I am challenging the company to up their game." <humour>Yeah, with those extortionate licensing fees we pay, it should be perfect.</humour> CiviCRM is a community open-source project. There is no large company backing it with a dedicated QA team. It seems subjectively that 4.7 has produced a large crop of bugs and it's a fair question to ask how we can improve the quality before release. But "challenging the company" is looking in the wrong direction: it is a community effort - ie us!
    – Aidan ♦
    Apr 6, 2016 at 18:06
  • 1
    To add to Aidan's comment, there has been a very active discussion on the developer mailing list the last week or so about ways to improve the testing and release cycle. There seems to be general consensus there that improving quality control for future releases needs to be a big priority right now.
    – Allen Hutchison
    Apr 7, 2016 at 5:06
0

One of the challenges of such a large open source software project is that it is in a constant state of flux - this is particularly true of non-lts versions (i.e. for extra stability v4.6.* is recommended). Sadly, breakages do occur. The community definitely recommends having a staging server to test with and taking backups of databases so that you can roll-back if you needed to (as you said you'd prefer to).

"Challenging the company" is less useful than, say, contributing unit tests that test key functionality that you never want to break.

JohnFF

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.