Change installation Google tracker setup

[raycarrick-ed]

At the moment we plant 2 google trackers: one for the installation and one for the user's organisation. The planting of the user tracker is keyed off the org but the installation is keyed off an abbreviation which gets set in the config (config/initializers/_dmproadmap.rb). But the problem is that abbreviations are not unique. So the fact that it is working is chance.

We need to change away from using the abbreviation to specify the google tracker for the installation's institution. The easiest way to do this would be to simply specify the tracker code in the config instead of the abbreviation and then plant that.

This has the flaw that if the installation's google tracker code gets changed it will need to be changed in the config as well. In reality, that will not be likely to happen very often.

An alternative approach is to find a different way to specify the installation org e.g. by name but that is error prone because of spelling by org id but that is clumsy and relies on unchanging ids in the db by being the first org in the table?? is that true - will the installation org always be the first?

So given the options above planting the code in the config seems easiest for now. Unless someone else has a better idea.

[gjacob24]

Hi @briri, @raycarrick-ed and I just had a conversation about this and concluded that there are two possible solutions to this:

1. to insert the tracker code directly in the config file. However that might not be the best option since the tracker code will then be in two places and might make it difficult to change in the future, if necessary.
2. use the instance org's ID instead of the abbreviation, which seems like the better option as the org id is unlikely to change.

Let us know if you are okay with this change or if you have any other suggestions. Thanks.

[briri]

How are you planning to fetch the instance org ID? Do you both think it would make sense to add a new column to the table, 'orgs.is_default'? If we do that it might be good to add a validation on the model that ensures that there is only one default.

There is also a helper method on the Org model def self.default_orgs that will should be updated. It currently returns an array which is confusing (and likely that way because of the possibility that the abbreviation is not unique).

We would have to let people know that this needs to be set in the release notes of course.

[gjacob24]

Based on our discussion, I believe the instance org ID would be inserted in the config file (similar to how it works currently with the abbreviation). I'm not sure if this way of doing it is better than what you have suggested, so will wait for @raycarrick-ed's response regarding that.

[gjacob24]

Hi @briri, based on your suggestion we think the following can be done:

• do a migration task and add a new column is_default
• add validation on model as suggested
• set the instance org's value in the column to 'true', by matching the organisation's abbreviation from config (will have to add a check to confirm that only one org uses said abbreviation) This will set the instance org as the default org in the column.
• def self.default_orgs will have to be changed to refer to the column, not the abbreviation, to find the default org.

Finally, if there is no instance org, the Organisation Details page will include a checkbox which would allow a super admin to set that org as the instance org (a one-time only action).

Let us know what you think and if you have any other suggestions. Thanks!

[briri]

That sounds like a good approach. Thanks @gjacob24!

If time permits I would suggest replacing the old def self.default_orgs with def self.default which returns an Org instead of an Array and then update the places where its used appropriately. A def default? instance method might also be a useful addition. For example:

  def self.default
    Org.find_by(is_default: true)
  end

  # alias so that the model can be asked `org.default?`
  alias_attribute :is_default :default

If you could also create a ticket titled 'Rails 6 upgrade - general cleanup' we can add a task of removing the old config value at a later date once everyone has run the task to set the value in the DB. We can then ad onto that ticket over the next few months as we find things that are no longer necessary.