| Issue Number | 3644 |
|---|---|
| Summary | [Summaries] Module attributes - need to identify all modules (including stand-alone summaries) |
| Created | 2013-08-16 08:58:50 |
| Issue Type | Improvement |
| Submitted By | Juthe, Robin (NIH/NCI) [E] |
| Assigned To | Kline, Bob (NIH/NCI) [C] |
| Status | Closed |
| Resolved | 2013-09-03 08:48:25 |
| Resolution | Fixed |
| Path | /home/bkline/backups/jira/ocecdr/issue.112016 |
We would like to implement a way to identify documents that are designed to be used as both modules and stand-alone summaries. The current attribute on summary modules ("ModuleOnly=Yes") is only used when the document is NOT intended to be published as a stand-alone document. We may need to add a second attribute, but this needs more discussion to determine the best solution.
CDR Developer Discussion: This was given story points = 2 to (a) decide (with the users) which attribute change(s) to make, and to actually make the change(s).
I propose that we add a top-level optional attribute AvailableAsModule="Yes" as the safer of the approaches to this request, since we wouldn't have to search for all the software which uses the existing ModuleOnly attribute to find out what would need to be changed if we replaced it with an attribute which could identify all three possibilities in a single attribute (for example, Module with values "Always," "Optional," and "Never"), which would introduce extra work and risk. We don't have a separate issue for a report to show the different types of summaries, but that should be easy to handle with an ad-hoc query, which wouldn't need a separate ticket, nor coordination with CBIIT.
Does this proposed approach work for everyone?
To clarify, are you suggesting this new attribute in addition to ModuleOnly=Yes?
That's right. Leaving the existing attribute alone avoids the risk that we'll inadvertently break something that depends on it.
Margaret and I just discussed this and we think this is a good approach. The two attributes ought to give us enough flexibility to identify docs that can be used as modules but are not only modules.
We may want to make some changes down the road to limit SummaryModuleLink elements to only allow links to documents with this new attribute (rather than any summary). We may also want to take another look at the summaries reports that we just modified in OCECDR-3575 to determine whether we should revise the logic that adds "(Module)" after anything that has ModuleOnly=Yes.
Attribute installed on DEV.
Verified new attribute in summary document on DEV. I added the new attribute to the Peutz-Jeghers module (CDR0000738176).
We will need to modify our publishing document since the current SQL query for selecting summaries to be published will exclude Peutz-Jeghers due to its ModuleOnly=Yes attribute.
Peutz-Jeghers should be excluded if it has ModuleOnly=Yes. The new attribute only says it can be used as a module. Doesn't say anything about whether it can be published as a standalone summary.
So, for Peutz-Jeghers to be published as both, a stand-alone summary
and a module the ModuleOnly=Yes attribute would be
removed and AvailableAsModule=Yes would be added, right?
I had thought the current setup - both attributes set to Yes - should
indicate both publishing options.
There are three logical possibilities:
1. In the most common case, neither attribute is set. Such as summary cannot be used as a module, but is intended for standalone publication only.
2. ModuleOnly=Yes means the document cannot be published by itself, but only included in another summary. This attribute implies AvailableAsModule=Yes (though it would be cleaner for such documents to have both attributes set.
3. AvailableAsModule=Yes means the document can be included as part of another document. If the ModuleOnly attribute is not present, the document can also be published standalone.
Verified the schema on QA.
Verified the schema in production.
Elapsed: 0:00:00.001747