CDR Tickets

Attachment SPECS For Board Meeting Tracking Report.docx has been added with description: Specs for Board Meeting Recordings Tracking Report

BZDATETIME::2010-07-20 14:33:24
BZCOMMENTOR::Volker Englisch
BZCOMMENT::1

From the specs document:

"The report will generate a list of documents created within the
date range selected."

I'm not sure what the "documents created" means here.
Are we looking at versions created (possibly publishable versions), the date a recording had originally been stored, the last time the document has been stored, or are we just looking at the DateCreated element in the Media document?

BZDATETIME::2010-07-20 15:03:46
BZCOMMENTOR::Volker Englisch
BZCOMMENT::2

From the specs document:

"Path: - All board meeting recordings have a <Category> value
of ‘Board meeting’
Media/MediaContent/ContentDescriptions/’Board meeting’"

Is it correct that you would rather want the selection to pick from the free text field ContentDescription than from the LOV field Category='Meeting Recording'?
If so, would you only want to include the value
Board Meeting
or should we also include
CAM Board Meeting
Screeing and Prevention Board Meeting Recording March 24, 2010
Screening and Prevention Meeting Recording January 27, 2010
or would these existing values still need to be updated?

BZDATETIME::2010-07-20 15:14:42
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::3

(In reply to comment #1)
> From the specs document:
>
> "The report will generate a list of documents created within the
> date range selected."
>
> I'm not sure what the "documents created" means here.
> Are we looking at versions created (possibly publishable versions), the date a
> recording had originally been stored, the last time the document has been
> stored, or are we just looking at the DateCreated element in the Media
> document?

Using versions will do. For example, using the date the first version (any version) was created will be fine but I was thinking more in terms on when the user first saved a Media document that was a meeting recording. That is, the date the CDR ID was assigned.

BZDATETIME::2010-07-20 15:27:44
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::4

(In reply to comment #3)
> From the specs document:
>
> "Path: - All board meeting recordings have a <Category> value
> of ‘Board meeting’
> Media/MediaContent/ContentDescriptions/’Board meeting’"
>
> Is it correct that you would rather want the selection to pick from the free
> text field ContentDescription than from the LOV field Category='Meeting
> Recording'?

Sorry about the confusion. I am not referring to the free text. I am referring to the <Category> of the Media Content element with the following path. So the path should be:

Media/MediaContent/Categories/'Board Meeting'
The Board Meeting value is a pick list.

> If so, would you only want to include the value
> Board Meeting
> or should we also include
> CAM Board Meeting
> Screeing and Prevention Board Meeting Recording March 24, 2010
> Screening and Prevention Meeting Recording January 27, 2010
> or would these existing values still need to be updated?

I couldn't see the LOV field. Could you give me the path ?

BZDATETIME::2010-07-20 15:34:30
BZCOMMENTOR::Volker Englisch
BZCOMMENT::5

(In reply to comment #4)
> Media/MediaContent/Categories/'Board Meeting'
> The Board Meeting value is a pick list.

No, it is not a value from a pick list but there is the category (from the pick list) that's named 'Meeting Recording'
This is what I have used for the change of the last media tracking report changes as well.

> I couldn't see the LOV field. Could you give me the path ?

That exactly was my point: There doesn't exist a LOV for the content description but you've already answered my questions to use the category value instead.

BZDATETIME::2010-07-20 15:51:18
BZCOMMENTOR::Volker Englisch
BZCOMMENT::6

(In reply to comment #3)
> I was thinking more in terms on when the user first saved a Media document
> that was a meeting recording. That is, the date the CDR ID was assigned.

That's not a problem as long as the users are aware that they might not be able to see the date that's displayed anywhere else.

BZDATETIME::2010-07-20 17:20:42
BZCOMMENTOR::Volker Englisch
BZCOMMENT::7

From the specs document:

"When multiple processing statuses exist, display the most recent
processing that which will be the one on top of all the others."

Since the status is not being displayed I'm assuming that this sentence is a left-over from a previous requirements document.

If assumption is correct the report can be reviewed on MAHLER.

BZDATETIME::2010-07-21 11:24:03
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::8

(In reply to comment #7)
> From the specs document:
>
> "When multiple processing statuses exist, display the most recent
> processing that which will be the one on top of all the others."
>
> Since the status is not being displayed I'm assuming that this sentence is a
> left-over from a previous requirements document.
>
> If assumption is correct the report can be reviewed on MAHLER.
I initially included a display column for processing status but removed it since it will not be useful for this report and I forgot to take the requirements out.

I reviewed the report in Mahler and it looks good.

I had requested a default start date of 2010-03-01. Is it possible to do it? Is it also possible to have a default end date which will always be the current date? If not or if it will take too much time to do, don’t worry, they are only for our convenience

BZDATETIME::2010-07-21 11:40:39
BZCOMMENTOR::Volker Englisch
BZCOMMENT::9

(In reply to comment #8)
> it also possible to have a default end date which will always be the current
> date?

Done.

BZDATETIME::2010-07-21 11:44:15
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::10

(In reply to comment #9)
> (In reply to comment #8)
> > it also possible to have a default end date which will always be the current
> > date?
>
> Done.

Verified on Mahler. Thanks! Please promote to Bach.

BZDATETIME::2010-07-21 13:49:58
BZCOMMENTOR::Volker Englisch
BZCOMMENT::11

The following files have been copied to FRANCK and BACH:
MediaReports.py - R9800
RecordingTrackingReport.py - R9800

Please verify on BACH and close this bug.

BZDATETIME::2010-07-23 14:32:53
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::12

(In reply to comment #11)
> The following files have been copied to FRANCK and BACH:
> MediaReports.py - R9800
> RecordingTrackingReport.py - R9800
>
> Please verify on BACH and close this bug.

Verified on Bach. Thanks!

Issue closed.