Wishlist: Check certain files in a folder against different policies according to filename matching

[iamdamosuzuki]

Related to #176, but for the GUI version. Allow the using to run multiple policies on a single folder, but checking specific files on the folder against specific policies using character or extension matching. For example, within one folder:

files containing "_pm.mkv" are checked against the "MKV Preservation Copy" policy
files containing "_mz.mov" are checked against the "MOV Mezzanine Copy" policy
files containing "*_am.mp4" are checked against the "MP4 Access Copy" policy

[kgrons]

+1

[retokromer]

+1

[dericed]

I think this may be possible to accommodate with the or policy types, but would require the tests to add a contains or ends-with function, so it'd be like

<policy type="or" name="Does this get Morgan's approval?">
  <policy type="and" name="Valid Preservation?">
    <rule name="Is preservation thing?" value="filename" operator="ends-with">_pm.mkv</rule>
    <...other rules...>
  </policy>
  <policy type="and" name="Valid Mezzanine?">
    <rule name="Is mezzanine thing?" value="filename" operator="ends-with">_mz.mov</rule>
    <...other rules...>
  </policy>
  <policy type="and" name="Valid Access?">
    <rule name="Is access thing?" value="filename" operator="ends-with">_am.mp4</rule>
    <...other rules...>
  </policy>
  <policy type="and" name="Valid GB file?">
    <rule name="Is it an mxf thing?" value="filename" operator="ends-with">_ohyeah.mxf</rule>
    <...other rules...>
  </policy>
</policy>

[retokromer]

I think this could be a good solution!

[iamdamosuzuki]

I'll give this a shot, thanks!

[JeromeMartinez]

I'll give this a shot, thanks!

Don't try, it will not work (Dave said "would require the tests to add a contains or ends-with function").

[JeromeMartinez]

OK, let's try to see technically what we need.
I see 3 parts:

• Adding operators related to string manipulation
• Result in case none of the name checks fits
• Merging policies from one "super-policy"

---

Adding operators related to string manipulation:

Same as Dave idea about contains or ends-with functions.
Dave, is it possible in XSL to have such string manipulation operators?
I have concerns about long term, as we may have more and more requests about string manipulation in the future, how far can we go with such increasing list of operators?

Result in case none of the name checks fits

What is the expect outcome in case none of the name checks fits?
IMO it should de customizable, one may want "Fail", another one may want "Pass", and (related to another ticket) another one may want "N/A".
How could we define the result in case none of the name checks fits?
I don't see obvious metadata to put at an obvious place in the XML (and in the UI).
With Dave proposal, it is "Fail", can not be changed.

Merging policies from one "super-policy"

An issue I see for some time is when we need to rely on other policies, no need of such complex request, e.g. we can have a "Is NTSC" policy in the public policies list, and people could reuse it without wanting to have to change all copies of the policy merged in private policies in case there is an update to this policy, we should be able to "import" a policy, e.g.:

<policy type="or" name="Does this get Morgan's approval?">
  <policy type="and" name="Valid Preservation?">
    <rule name="Is preservation thing?" value="filename" operator="ends-with">_pm.mkv</rule>
    <policy import="MKV Preservation Copy" />
  </policy>
  <policy type="and" name="Valid Mezzanine?">
    <rule name="Is mezzanine thing?" value="filename" operator="ends-with">_mz.mov</rule>
    <policy import="MOV Mezzanine Copy" />
  </policy>
</policy>

(note: I don't like to rely on the policy name, we may have to add also an UMID per policy)

technically, I think it is only doable when we load the XML, before the policy is applied (XSL), because the XSL processor has no clue about external policies, and it is not complex (I catch the "import" attribute, and replace the element by the other policy).

[retokromer]

In my opinion, XSLT should allow such string manipulation.