why does upgrade:migrate_plan_org_and_funder change the plan.org_id?

[nicolasfranck]

Please complete the following fields as applicable:

What version of the DMPRoadmap code are you running? (e.g. v2.2.0)

tags/v2.2.1

Expected behaviour:

plan.org_id should remain the same

Actual behaviour:

the migration step bin/rake upgrade:v2_2_0_part2 contains a rake subtask upgrade:migrate_plan_org_and_funder that changes plan.org_id to plan.owner.org_id. See.

Was the selection of the organisation only important (in the past) to preselect guidances?

This step changes 5% of our plans. What was/is the org_id of a plan actually important for?

[briri]

Hi @nicolasfranck you are correct. The only reason the org_id was there in the past was for guidance pre-selection and (on the create plan page) to determine if the plan should be based off of the funder template or an org's customized version of the template (if applicable).

I do not recall under which circumstances exactly would result in a plan with a nil org_id (maybe if they ticked the 'no research org' checkbox on the create plan page)

The org_id has since become important to maDMP functionality. The rake task for this should only be setting the org_id to the owner's org when the plan has a nil for that value next if plan.org_id.present?

[briri]

As part of the future maDMP work, the org_id here will indicate what Org owns/created/manages the DMP when we begin allowing the system to mint DOIs for the DMP.

[nicolasfranck]

@briri now it starts to make sense why org.plans (see https://github.com/DMPRoadmap/roadmap/issues/2724) is not just a list of plans with organisation_id set to that organisation id

[nicolasfranck]

Mm, something related: since migration 20161122152339_new_plan_template_structure.rb, the org_id and funder_id from the previous installation (DMPonline_v4) are gone. The fields are recreated (but not refilled) in migration 20200203190734_add_funder_and_org_to_plans.rb, but, looking at some source code, I'm not sure if that is really necessary:

• a plan's org is implied to be plan.owner.org
• a plan's funder is implied to be plan.template.org if that template's org is a funder

why store it at two places?

Unless you've chosen an org at creation (and so chosen a template for that org), and therefore the funder has nothing to do with the template?

I'm asking because I do not know if I should restore those attributes using the values from DMPonline_v4

[nicolasfranck]

Mm, update: project.funder in DMPonline_v4 was not actually a stored attribute, but used project.dmptemplate.organisation 🙊. So still: plan.funder_id seems not necessary

[briri]

It may not be applicable for your installation and use cases. It becomes relevant when people select a non-funder based template (e.g. the generic DCC one on DMPonline, we have a few in the DMPTool, as well as any created by a University).

The code will auto-set the funder_id to the templates.org_id value (if the org is a funder).

We added the org_id back onto the plans table because we encountered scenarios where the original creator/owner of the plan changed institutions but we still wanted to retain the connection between the plan and the org it was created for (for statistical purposes as well as acess in some situations like when the visibility was organisationally_visible)

It seems like it might be useful for you to restore the values you had in DMPonline_v4 if possible.