Uploaded image for project: 'mod-orders-storage'
  1. mod-orders-storage
  2. MODORDSTOR-213

Illegal cross-module *_mod_finance_storage.fund access on migration

    XMLWordPrintable

    Details

    • Template:
      Standard Bug Write-Up Format
    • Sprint:
      ACQ Sprint 110, ACQ Sprint 111, ACQ Sprint 112
    • Story Points:
      2
    • Development Team:
      Thunderjet
    • Release:
      R1 2021 Bug Fix

      Description

      Overview:
      data-migration/11.0.0/po_line_sync_fund_code.ftl contains this sub-select:

      SELECT jsonb -> 'code'
      FROM ${myuniversity}_mod_finance_storage.fund
      WHERE jsonb ->> 'id' = distrib ->> 'fundId'
      

      mod-orders-storage violates the module separation by directly accessing ..._mod_finance_storage schema.

      The FOLIO architecture mandates that cross-module communication goes through HTTP APIs only.

      Some deployments (for example GBV multi-tenant installation) use database ROLEs with access restricted to the current schema. They fail when running this migration script.

      If one module requires that some other module exists it must list that other module's interface in its ModuleDescriptor "requires" section.
      mod-orders' Module Descriptor has a "requires" section that lists

            "id": "finance.funds",
            "version": "1.3"
      

      and

            "id": "orders-storage.po-lines",
            "version": "9.4"
      

      https://github.com/folio-org/mod-orders/blob/v11.2.0/descriptors/ModuleDescriptor-template.json#L731-L767

      This makes mod-orders a suitable place to run the migration using API calls.

      mod-orders-storage doesn't have a "requires" section in its ModuleDescriptor - this is correct to comply with the FOLIO architecture where each storage module stands on its own.

      Steps to Reproduce:

      # in first shell console
      # checkout mod-orders-storage with any
      # commit >= version 11.1.3, for example HEAD of master
      mvn clean install
      java -jar target/mod-orders-storage-fat.jar
      
      # in second shell console
      curl -s -D - -H 'Content-type: application/json' -H 'x-okapi-url-to: http://localhost:8081' -H 'x-okapi-tenant: diku' -XPOST -d '{ "module_to": "11.1.2" }' http://localhost:8081/_/tenant
      
      psql 'postgresql://username:password@localhost:6000/postgres' -c 'ALTER ROLE username NOSUPERUSER'
      
      curl -w'\n' -s -D - -H 'Content-type: application/json' -H 'x-okapi-url-to: http://localhost:8081' -H 'x-okapi-tenant: diku' -XPOST -d '{ "module_from": "11.1.2", "module_to": "11.1.3" }' http://localhost:8081/_/tenant
      

      Expected Results:
      The last curl upgrade POST succeeds.

      Actual Results:
      The last curl upgrade POST fails with a 400 error. This is the error log entry in the first console:

      PostgresClient trying to execute:  UPDATE diku_mod_orders_storage.po_line SET jsonb =     (       SELECT jsonb_set(jsonb, '{fundDistribution}', jsonb_agg(jsonb_set(distrib, '\{code}', coalesce((SELECT jsonb -> 'code' FROM diku_mod_finance_storage.fund WHERE jsonb ->> 'id' = distrib ->> 'fundId'), distrib -> 'code', '""'))))       FROM jsonb_array_elements(jsonb -> 'fundDistribution') distrib     ) WHERE jsonb_array_length(jsonb -> 'fundDistribution') > 0
      PostgresClient ERROR: relation "diku_mod_finance_storage.fund" does not exist
        Position: 188
      

        TestRail: Results

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                Andrei_Makaranka Andrei Makaranka
                Reporter:
                julianladisch Julian Ladisch
                Votes:
                0 Vote for this issue
                Watchers:
                7 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved:

                    TestRail: Runs

                      TestRail: Cases