# Bug JIM-261 - Custom field values are silently dropped when a type's form configuration changes in the same request or job

Project: Stream Jira to OpenProject data Migrator
Status: closed
URL: https://community.openproject.org/work_packages/JIM-261

## Open points

_No work packages_

## Details

| Attribute | Value |
| --- | --- |
| Date |  |
| Priority | Medium |
| Module | Integrations / Jira |
| Target versions | 18.0.0 |
| Observed in versions | 17.9.0 |
| Sprint |  |
| Backlog bucket |  |
| Bug found in version (deprecated) |  |
| Requires doc change | No |
| Accessibility | No |
| Pull preview |  |
| List |  |
| Labels |  |

## People

| Attribute | Value |
| --- | --- |
| Assignee |  |
| Accountable |  |
| Product manager |  |
| Developers | Andrej Sandorf |
| Designer |  |
| Ordered by |  |
| Signed off by |  |
| Interest by |  |

## Planning

| Attribute | Value |
| --- | --- |
| Relevance |  |

## Costs

| Attribute | Value |
| --- | --- |
| Votes |  |
| Work |  |
| Labor costs |  |

## Description

### Steps to reproduce

1.  Log in as an administrator
    
2.  In Jira, have one project with one issue type and a _Text Field (multi-line)_ custom field on it
    
3.  Create issue A of that type and leave the text area empty
    
4.  Create issue B of the same type and fill the text area, for example `This is *bold* text.`
    
5.  In OpenProject, run the Jira migration for that project. Issue A has to be imported before issue B, which is the case when it was created first
    
6.  Open the work package imported from issue B
    

### What is the buggy behavior?

*   The custom field is created with the correct name and the correct format, and it is added tothe type's form configuration
    
*   The work package shows the field, but its value is empty (`""`). The imported content is lost
    
*   No error is raised, nothing is written to the log, and the import reports success
    

### What is the expected behavior?

1.  A change to a type's form configuration takes effect for work packages handled later in the same request or job
    
2.  In the reproduction above, the work package imported from issue B carries  
    `This is **bold** text.`
    

### Important note

The root cause is in the work package custom field machinery, not in the importer:

*   `WorkPackage.available_custom_fields` memoises its result in `RequestStore` under `work_package_custom_fields_<project_id>_<type_id>` (`app/models/work_package.rb`). Nothing invalidates that entry when a form configuration changes
    
*   `WorkPackages::SetAttributesService#set_custom_attributes` selects assignable attributes with `work_package.respond_to?(key)`. That resolves through `acts_as_customizable`&#x27;s `respond_to_missing?`, which consults the stale cached list, so the attribute is discarded instead of reported
    

In the Jira import the two meet: the per-project job adds a custom field to the type when it reaches the first issue carrying a value for it, but `app/workers/shared_job_setup.rb` clears `RequestStore` once per job rather than per issue, so the list cached while creating the first work package of a type is reused for every later one.

### Environment information

**OpenProject installation type**

*   [x] All

**OpenProject version**

v17.9

**Operating System**

*   [x] All

Not applicable.

**Language**

*   [x] All