Candidate Identifiers in LORIS

[driusan]

One of the last pieces of configuration in the config.xml is PSCID/ExternalID configuration. These are also the only 2 types of identifiers that LORIS supports out of the box, and they can’t be managed from the frontend (because they’re in the config.xml). Many projects need more than 2 identifiers and the only way to do that currently is with overrides to add more. (Which is often needed for anonymized data submissions or integration with other software.)

I’m proposing we add a new table of (customizable) identifiers types to the LORIS. When a candidate is created, identifiers for each type are generated for the candidate based on a template string that outlines the structure of the identifier. Each permission would also optionally have a permission required to view the identifier.

The template for an identifier is, rather than a complex XML configuration, a simple string with some variables that can be interpolated. For example (This doesn’t necessarily need to be the syntax if someone has an idea that’s more user friendly, but just for illustrative purposes):

{SITE:ALIAS}{SEQUENCE:4,PADDING=0}

Would be the equivalent of the site alias followed by a 4 digit number padded with 0s used by many LORIS instances.

In the above grammar, the parts between { and } are interpolated. The part before the : is the type of variable (ie SITE and SEQUENCE) and the parts after : are the arguments, comma separated. Anything not in {} is treated as a literal. So, we could also do something like (this example is very contrived for illustrative purposes):

Project-{PROJECT:ALIAS}-MRIAlias{SITE:MRIALIAS}-{RANDOM:6}

which might generate a candidate identifier that would look something like Project-PUMP-MRIAliasMTL-536234on Raisinbread. (Note the MTL comes from the MRI Alias, not the site Alias. They’re the same on RB but can be different on various projects in LORIS.)

Types of variables that I can think of which we would need:

• SITE - The site at the time of the candidate’s registration.
  Arguments: the format to display the site (ALIAS,MRIALIAS or NAME, ID which reference the columns of the same name in the psc table. “ID” references CenterID.)
• PROJECT - The project at the time of the candidate’s registration.
  Arguments: the format to display the project (NAME, ALIAS, ID which reference the columns in the Project table. ID references ProjectID)
• SEQUENCE - An incrementing sequence to insert into the identifier. If there’s a sequence in the template and the identifier calculated for a candidate already exists, the sequence is incremented until a unique identifier is generated.
  Arguments: an integer, the number of digits of the sequence. Optionally PADDING=x where x is a character to pad the sequence with to get the right number of digits.
• RANDOM - A random n digit number. If the calculated identifier already exists, a new random number is generated until finding one that’s unique.
  Arguments: n, the number of digits.
• USER - a string entered by the user.

Initially, there can be at most 1 USER column, SEQUENCE, or RANDOM variable. (This will make implementation easier, and is also a limitation that we currently have since there can only be one generation type in the config.xml. We can lift this restriction later if we think through what a reasonable implementation might look like when there’s multiple..)

Before moving forward, I’d like some feedback on the proposal:

1. Does this proposal make sense?
2. Are there any proposals for a better format for the template strings (either more user friendly, more powerful, more readable, or all of the above..)
3. Is everything covered? Are there any other variables we need?
4. Is there anything else we need to consider?
5. Do you have any identifiers that can't be represented by the above (or an alternately proposed format.)

[ridz1208]

@driusan I'm happy with most of the proposal and okai with the phased approach (one identifier at first then multiple)

I think one detail that is missing is where and how the identifiers show up on the front end (candidate list column? new module? DQT?) And details like can we configure it to be hidden or showing like a GUID or external ID should be hidden vs a project ID that is useful to site staff. This is a inor feature that can be developed later, just making a note of it.

The format defined seems easy and intuitive to me, unless some project wants curly brackets in their IDs (doubt it)

The only improvement I would suggest is the MIN MAX values for numbers. I know its a constraint of some projects that their IDs not contain leading 0s so DCC0001 is problematic but DCC1000 to DCC9999 is fine.

In the case of CBIG the GUID which has a complex generation logic would not be generated by this functionality, I guess it would just be set to USER defined and inserted on creation. we can discuss this usecase later

[driusan]

Just to clarify: you can have multiple identifiers, but each identifier type can only have one type of user/sequence/random variable in it. So you couldn't have an identifier template like: sub-{SEQUENCE:3}-{RANDOM:4} or foo-{SEQUENCE:2}-{SEQUENCE:2} because it's not clear what to do if there's a conflict in that case.

There would be a new module to manage the types of identifiers / configure. That module would also provide a QueryEngine for the DQT that replaces the "Candidate Identifiers" currently provided by the canadidate_parameters QueryEngine and the new module probably would also add widget to the candidate_profile page. I don't think there would be changes to existing modules unless someone updated them.

I don't see any problem adding optional MIN=.. and MAX=... arguments for SEQUENCE and RANDOM.

Wrt "hiding": what's the difference between "hiding" an identifier type and making it require a permission that you don't give to most users?

[ridz1208]

Wrt "hiding": what's the difference between "hiding" an identifier type and making it require a permission that you don't give to most users?

no permissions I guess would to the job

Just to clarify: you can have multiple identifiers, but each identifier type can only have one type of user/sequence/random variable in it. So you couldn't have an identifier template like: sub-{SEQUENCE:3}-{RANDOM:4} or foo-{SEQUENCE:2}-{SEQUENCE:2} because it's not clear what to do if there's a conflict in that case.

makes sense