Redmine

Dear Support:
How to fix it, please help.

thanks
Tomato

Same problem here. Do you use any plugins?

Environment:
Redmine version 6.0.6.stable
Ruby version 3.3.7-p123 (2025-01-15) [x86_64-linux]
Rails version 7.2.2.1
Environment production
Database adapter Mysql2
Mailer queue ActiveJob::QueueAdapters::AsyncAdapter
Mailer delivery sendmail
Redmine settings:
Redmine theme Circle (includes JavaScript)
SCM:
Subversion 1.14.3
Git 2.43.0
Filesystem
Redmine plugins:
redmine_agile 1.6.11
redmine_budgets 1.0.7
redmine_checklists 3.1.26
redmine_contacts 4.4.3
redmine_contacts_helpdesk 4.2.5
redmine_contacts_invoices 4.2.13
redmine_drive 1.2.3
redmine_finance 2.1.11
redmine_messenger 1.0.15
redmine_more_previews 5.0.9
redmine_people 1.6.11
redmine_products 2.2.6
redmine_questions 1.0.7
redmine_reporter 2.0.5
redmine_resources 2.0.5
redmine_xapian 4.0.3
redmine_zenedit 2.0.8
redmineup_tags 2.0.15

I had some problems with locales in 6.0.6 and database dumps… this may be related to the current problem.

This is a remark regarding version 6.0.6:
 “ Additionally, the patch for #38529, initially released in version 5.1.0, is now properly fixed and the locales are limited to those defined by Redmine itself. ”

In my installations, no other languages than English were recognized anymore.
I had to develop a fix so that my plugins which use Bulgarian internally would not crash anymore.

I had to create ./config/initializers/fix_locales.rb

# Fix für Redmine 6.0.6 Locale-Problem
Rails.application.config.after_initialize do
  available_locales = Dir[Rails.root.join('config', 'locales', '*.yml')].map do |f|
    File.basename(f, '.yml').to_sym
  end

  I18n.available_locales = available_locales
end

Then all languages were recognized again - and no crashes would happen with the RedmineUP plugins anymore.

But there is only english as language available at the account page anymore.

One more note on this topic.

I have downgraded from version 6.0.6 to version 6.0.5. I did not install my script. The plugins and all other data were copied from the 6.0.6 installation.

On the now present 6.0.5 version, the errors do not occur. There are no startup crashes due to plugin errors; nor are the installed languages missing from the user master data.

Thus, this is definitely related to the change in version 6.0.6 and the used plugins; because in an initial 6.0.6 installation, all languages seem to be available.

this problem not from redmine, its becuase redmine invoice plugin from redmineup,, im contact with suppourt its will solution it

Holger Just wrote in #note-5:

It seems that you are all using quite a lot of plugins. It is likely that this issue is caused by one of your plugins given that this behavior is fully tested in Redmine. As such, please remove plugins until you can find the one responsible and contact their authors.

As plugins can change anything in Redmine, this is not something we can prevent here.

This isn't just a plugin-specific issue, but from my perspective, it's also a problem with versioning practices and how fixes, patches, and security updates are released by the Redmine development team.

Keywords: Semantic Versioning (Major . Minor . Patch)

Based on a version number of MAJOR.MINOR.PATCH, the individual elements are incremented as follows:
1. MAJOR is incremented when incompatible API changes are released
2. MINOR is incremented when new functionality that is backward-compatible with the existing API is released
3. PATCH is incremented when changes consist exclusively of backward-compatible bug fixes

Redmine was updated from version 6.0.5 to version 6.0.6 - and according to my understanding, this should only contain security fixes and patches that don't have such massive consequences. After all, these plugins were fully compatible from 6.0.0 through 6.0.5!

The root cause of the plugin incompatibility was likely this ticket:

• Defect #42815: Limit available locales to those defined by Redmine itself no longer works

This fix, and potentially others, should have been delivered in a new 6.1.0 release from my perspective.

When you deliver changes like this in a patch version (here 6.0.6), you effectively cut off the entire 6.0.x branch from potential future security patches.

Redmine is certainly used frequently in enterprise environments, as in my case. I can't simply disable a plugin to upgrade to a higher patch release; in this situation, one or more plugins now need to be corrected - which will certainly require time from the plugin developers. Should a critical security patch now be released as 6.0.7, I currently wouldn't be able to install it. My system would be non-functional.

This leaves me with a choice between an insecure system or a non-functional system - not a great choice!

My suggestion would be to deliver such patches not in a new patch version, but in a new minor or major version instead.

This approach would maintain the integrity of semantic versioning and allow administrators to make informed decisions about when to upgrade, especially in enterprise environments where stability and security are both critical concerns.

Well, I disagree for a couple of reasons (but would also like to conclude this discussion with that)

• Redmine is not a code library but a full application. The change was backwards compatible within Redmine. Plugins can patch any internal implementation of Redmine. While there are a couple of internal APIs we try to keep stable (i.e. the various hooks), plugins tend to override arbitrary functionality which can never be stable for the plugins.
• The change in #42815 was a bug fix for an issue which turned up with merging the oauth feature in #24808. The feature to restrict the locales was already part of 6.0.x itself before. It is thus not useful to delay this bug fix to a later release.
• I'm not sure that the redmineup plugins (or any of your other plugins) is doing there given that the standard way to add to locales in plugins still works fine. Thus, they may use internal functionality which we can never guarantee to be stable. It is up to the plugins to ensure that they stay up-to-date with Redmine changes.
• https://xkcd.com/1172/

In any case, please refer to Download for Redmine's release policy.

When you deliver changes like this in a patch version (here 6.0.6), you effectively cut off the entire 6.0.x branch from potential future security patches.

Well, no. An (small) incompatibility between a third-party plugin and Redmine does definitely not constitute a "cut off [...] from potential future security patches".

Should a critical security patch now be released as 6.0.7, I currently wouldn't be able to install it. My system would be non-functional.

Or... you could work with us and the plugin authors to identify the issue and fix it either in the plugin or with the next Redmine release. Bugs will always happen. It's your choice to help work towards fixing them or to just complain to volunteers who donate their free time to others.

This leaves me with a choice between an insecure system or a non-functional system - not a great choice!

See above. Of course, you could also find a company who would be willing to sell you a support contract so that you can outsource this work to someone else. Or you could migrate to a provider of hosted Redmine which will also solve this for you as part of their hosting services.