Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CRM-16395 Installation with localized default settings (more generic implementation) #8538

Closed
wants to merge 11 commits into from

Conversation

samuelsov
Copy link
Contributor

@samuelsov samuelsov commented Jun 8, 2016

New patch for CRM-16395 that replace #7322
Done the new way as proposed by @totten with SystemInstallEvent event.
Next step is to create the l10n/LANG/settings.default.json for each language in l10n

To test, copy the file provided settings.default.json.txt and copy it as l10n/YOUR_LOCALE/settings.default.json
and change the values as needed before starting the installation. In the installation process, choose the locale corresponding to the file.


@mlutfy mlutfy changed the title CRM 16395 generic CRM-16395 Installation with localized default settings (more generic implementation) Jun 8, 2016
@JoeMurray
Copy link
Contributor

@omarabuhussein would you be interested in reviewing this PR?

@JoeMurray
Copy link
Contributor

@jlillyreed would you able to look at this PR as well?

@omarabuhussein
Copy link
Member

@JoeMurray yes sure ... I will make my best to review it by tomorrow

@JoeMurray
Copy link
Contributor

@omarabuhussein Wonderful! Thanks!!

// disable every language that is not in the given list
$params['is_active'] = 0;
}
civicrm_api3('OptionValue', 'create', $params);
Copy link
Member

@omarabuhussein omarabuhussein Jun 25, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The logic in this method is heavy on the database , you're calling the database through this API method maybe more than 100 times , I would disable all languages first with a single API call (or a database call => using executeQuery) , and then loop through the languages from the configuration file and enable them one by one . (I believe users will not define more than two to three languages in the configuration file ) .

By the way ,, If we have the freedom to use PDO or mysqli direclty .. this logic could be replaced with a single SQL query :

UPDATE civicrm_option_value cov LEFT JOIN civicrm_option_group cog ON cov.option_group_id = cog.id SET cov.is_active = CASE WHEN cov.name IN (Langagues_list) THEN 1 ELSE 0 END WHERE cog.name = 'languages' ;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For me, the performance is not really a concern in this context because it's done only once when CiviCRM is installed. I prefer avoid direct queries when i can. I will see if we can inverse the logic by disabling all first as you suggest.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know what others may think ... but I believe that we should care about installation speed because every time someone add some heavy stuff like this we will end up with installation take very long time... also put into your account that some people may install civicrm on shared servers with limited plans so this would affect them ... ( but maybe I am wrong anyway :) )

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally, the API would support batch operations. Perhaps a short-term compromise would be to add a BAO helper function?

class CRM_Core_BAO_OptionGroup {
  /**
    * Set the given values to active, and set all other values to inactive.
    *
    * @param string $optionGroupName
    *   e.g "languages"
    * @param array<string> $activeValues
    *   e.g. array("en_CA","fr_CA")
    */
  public static function setActiveValues($optionGroupName, $activeValues) {
     CRM_Core_DAO::executeQuery(
       /* ...Omar's suggested query, with escaping for $optionGroupName and $activeValues... */
     );
  }
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, i have done as suggested by totten.

@omarabuhussein
Copy link
Member

omarabuhussein commented Jun 25, 2016

Hey @samuelsov ... Sorry for being late in reviewing this I was a busy in the previous days ... I left some notes , I think the first one is the most important where the other two are minor ...

@samuelsov
Copy link
Contributor Author

@omarabuhussein thanks for the review ! i will comment each of your note.

if (isset($settings['defaultCurrency'])) {
self::updateCurrencies(array($settings['defaultCurrency']), $settings['defaultCurrency']);
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like we're mapping 'settings.default.json into the Settings, but with exceptions. Taking a new look at this, I'm wondering about those exceptions.

  1. If setting languageLimit during installation is a bad idea, then wouldn't we just omit it from settings.default.json? (There's probably 100 settings which are irrelevant/bad-ideas for a localization package... but we don't need to blacklist all of them.) Any special reason to blacklist this one?
  2. For languageOptions, this seems to be preventing you from configuring other languages. (For example, in the screen Administer => Localization => Languages, wouldn't it hide a number of options?) Wouldn't this make it harder to setup multilingual? (Example: An NGO in France installs with the French language-pack, but it has branch-offices in Moracco, so it wants to enable multilingual with Arabic. But Arabic was disabled by the French language-pack.)
  3. Is updateCurrencies() something unique to installation process... or would it apply anytime you try to change defaultCurrency? If should apply anytime you update defaultCurrency, then perhaps it should be triggered this way:
diff --git a/settings/Localization.setting.php b/settings/Localization.setting.php
index e375d92..3b7eac6 100644
--- a/settings/Localization.setting.php
+++ b/settings/Localization.setting.php
@@ -142,6 +142,9 @@ return array(
  'defaultCurrency' => array(
    'group_name' => 'Localization Preferences',
    'group' => 'localization',
    'name' => 'defaultCurrency',
    'type' => 'String',
    'quick_form_type' => 'Select',
    'html_type' => 'Select',
    'html_attributes' => array(
      'class' => 'crm-select2',
    ),
    'default' => 'USD',
    'add' => '4.3',
    'title' => 'Default Currency',
    'is_domain' => 1,
    'is_contact' => 0,
    'description' => 'Default currency assigned to contributions and other monetary transactions.',
    'help_text' => NULL,
    'pseudoconstant' => array(
       'callback' => 'CRM_Admin_Form_Setting_Localization::getCurrencySymbols',
     ),
+    'on_change' => array(
+      'CRM_Foo_Bar::onChangeDefaultCurrency',
+    ),
   ),

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@totten I'm looking at your comments again and :
2. You are right... disabling preferred languages prevents user from selecting them in the localization admin page. I think we should always have the full list of localizable languages in admin/settings/localization. Also, it might be a good idea to ensure the available languages are always in preferred language (using the on_change event you mentioned).
3. Very nice. I have done as you have proposed and it fixes an inconsistency between the UI and the api at the same time - i.e. ensure the default currency is always in the enabled currencies.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Oh, no, you can enable language that are not in the list of available preferred languages. But the label is lost in the admin localization setting page - so you get es_ES instead of Spanish and it gets to the bottom of the list. I have fixed this bug.
  2. Except that there is no settings for currency_enabled. I have to manually initialize to the same as default language. The logic applies only in the installation process. So i guess i need the code after all. To avoid duplication of code, I have moved it to CRM_Admin_Form_Setting_Localization. We might want to have an simple api call for updating currency_enabled but it's not in the scope of this issue.

@JoeMurray
Copy link
Contributor

Heh guys, what is the status of this PR? Could we get it ready for review in a week as part of 4.7.10? Currently it's not on the list of i18n / l10n issues https://issues.civicrm.org/jira/secure/RapidBoard.jspa?rapidView=28&view=planning

Also, would you be able to help out in that group (or another one) this coming month? If so, please signup in https://docs.google.com/document/d/1UAFOy0gXar_ouzWgOpCdbMA2r6_sIyO_KPiZey9jVDE/edit (we haven't figured out how to do that in JIRA yet).

@samuelsov
Copy link
Contributor Author

@JoeMurray : Yes i should be able to work on this next week.

@totten : regarding your comments:

  1. in fact, it might be a good idea to add support for multilingual but if we do, we have to do more than just changing the setting i believe. Most of the settings are harmless and they only change value in the database but multilingual can break the database if not done correctly. That's why i just make an exception for it until i feel confident enough to support it.
  2. For languageOptions, the goal is to disable choices for the preferred language (http://dmaster.demo.civicrm.org/civicrm/admin/options?gid=79&reset=1). It won't impact the choices for locale or multilingual language. I will double check but i'm pretty sure those two are unrelated.
  3. Sure, i have taken some code from the admin setting page but yes, it should definitively be better like that. And i think this method can be applied to multilingual languageLimit if it's not the case. So maybe it could solve the 1.

@colemanw
Copy link
Member

@samuelsov can you give an update on this please?

@samuelsov
Copy link
Contributor Author

@colemanw I need to rework the patch and i haven't got the time to do so yet, unfortunately. I might be able to do so next week.

@samuelsov
Copy link
Contributor Author

I still need to work on @omarabuhussein performance concern...

@samuelsov
Copy link
Contributor Author

All right. I think the PR is ready for another review / testing.

// get labels for all the currencies
$options = array();

$currencySymbols = \CRM_Admin_Form_Setting_Localization::getCurrencySymbols();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure the \ is needed here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, an unfortunate copy/paste

}

$dontCare = NULL;
\CRM_Core_OptionGroup::createAssoc('currencies_enabled', $options, $dontCare);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

likewise

@samuelsov
Copy link
Contributor Author

@seamuslee001 it's fixed and i have removed some unnecessary duplicated code.

@eileenmcnaughton
Copy link
Contributor

@omarabuhussein @seamuslee001 looks like a lot of work has gone into this commit - including on the review side. Do you feel it's ready to merge?

@mlutfy
Copy link
Member

mlutfy commented Jun 16, 2017

new PR in #10517

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants