GNM_RCS_Content_History_TS

• 1. .Introduction

     1. Purpose

The document GNM_RCS_Content_Processing_FS.docx is the functional specification that describes what business functions RCS supports in relation to processing published content.

This document is one of a set of technical specifications that provide details of how those functions are implemented in RCS.

• 1. Scope

This document focusses on contributors’ Content history in RCS. Separate documents deal with all other aspects of content processing in RCS, including print & web content processing, matching, searching, specials, and AV products.

This document is intended as a high-level technical document outlining how the relevant business functions are implemented in terms of software modules.

Importantly, this document does not aim to provide the level of detail that would be required in a programming specification in areas such as program structure, detailed business rules, data integrity, validation, locking considerations, data security, and calls to/from other software modules, performance considerations, and so forth.

For details of program logic and coding, the reader should refer to the program files themselves.

• 1. .Content history screen

The Content history screen shows the content that has been published and matched to commissions and contracts for a selected freelance contributor.

The Oracle Form is called rcs_cpro_030_pc.fmb, and is accessed from this menu option:

Content → Content history

On entry to the screen the user chooses the contributor they are interested in from a list of values. The screen then opens showing the last 12 months of content for the chosen contributor in reverse order of publication date:

• 1. Changing search criteria

To query back a different time period the dates in the bottom left corner of the screen can be modified, and pressing the “Find” button with re-execute the query.

The user also has the choice of showing Single uses or All uses: a single use query might just list a picture that was published in print, whereas an All uses query might show the print and web uses of the same picture.

• 1. Generating a report

Pressing the “Show report…” button generates a PDF report using the same search criteria used in the screen. The user is asked whether they want a detail report or a summary report.

• 1. Viewing the content

Pressing the “Show content…” button navigates the user to the web page for the item of content, or opens a PDF document showing the content if the content was published in print.

• 1. Rights

The “Rights…” button shows the rights GNM has acquired in the content i.e. the rights profile of the matched commission or contact..

..

• 1. .Content history report

As described above, a Detail or Summary report can be requested. The layouts of these reports are shown below:

• 1. Detail report

• 1. Summary report

The Summary report is based on the same data, but only displays a single line of headline or caption data, rather than allowing it to wrap. This tends to reduce the length of the report by about 50%. An example page is shown below:

.

• 1. Technical complexities

     1. Database view

The screen and report are both based on the same database view called CONTENT_HISTORY.

This view is complex in structure in that it is a union of all matches made to commissions, lineage contracts and non-lineage contracts, and each of those queries joins a number of tables.

• 1. Contributor context

Furthermore the view is restricted to a single contributor by joining to a packaged function contributor_context.get_id

This function returns the ID of the contributor being queried; however this means the contributor context must be set prior to any query on the view. The context is set by the screen: when the user selects the contributor from the list of values the packaged procedure contributor_context.set_id is called passing in the internal ID of the record in the CONTENT_PROVIDERS table. This ID is stored in a package level variable, and consequently persists for the rest of the current session or until it is changed. The function contributor_context.get_id is called in the view definition and returns the value held in that package variable and thereby limits the content queried to that of a single contributor.

Therefore, because the screen and the report query the same view, and because both queries will pick up the same contributor context, the screen and the report will both return the same data.

• 1. Single vs. All uses

Where a single uses query is requested sibling content is supressed. This is done by a POST-QUERY trigger in the Form and by a frame format trigger in the Report. In both cases sibling content is identified by searching for the bundleid for text, and the PicDar URN for images.

End of Document