You can load (and are expected to if you intend to use them) an arbitrary number of iteration variable from the iterated table (or the common table shared if you load from different tables) e.g

table T = extend.range(5)
table U[u] = by T.N mod 2
T.N2 = T.N + 2
T.N3 = T.N + 3

T.S = for tn in T.N, tn2 in T.N2, tn3 in T.N3, un in u
  ...
  return ...

JIRA Doc : https://lokad.atlassian.net/browse/LK-7562
Careful as certain options (autocomplete...) can trigger a lot of computations and slow down the dashboard.
If you're looking at a hierarchical selection, consider https://docs.lokad.com/reference/stu/slicetree/

Files tied to a path schema and historized are a pain to manage because as soon as you update the path schema, every script reading the historical files before that modification as a path schema will fail (unless you specifically decided to not read such column in the path schema).

A feature is available from the data dictionnary > stats page to manually create dummy columns matching the modified path schema on past files that have been broken by the path schema modification so that they can still be read by your scripts.

Path schema supports computed columns e.g

export schema '/clean/SalesOrders.ion' with
  schema Schemas.SalesOrders
  NetAmountEUR : number = forex(schema.NetAmount, schema.Currency,"EUR", schema.OrderDate)
  UnitPriceEUR : number = forex(schema.UnitPrice, schema.Currency,"EUR", schema.OrderDate)

This is a nice solution to save some file storage for redundant columns.

It is possible in the IDE to select a show table section, right click and use the "Create schema from show" cmdlet.

Shamelessly copy-pasting an ELI5 from Reddit on how private/public key work. Nothing fancy once explained :)
https://www.reddit.com/r/explainlikeimfive/comments/1jvduu/eli5_how_does_publicprivate_key_encryption_work/
---
The basis is really simple:

Imagine you have a computer program that will allow you to encrypt a text file or digital document by using either one of two passwords, so that once you freely choose any one of the two passwords for encrypting, then decryption can only be performed by using the other password. That is: you can't both encrypt and decrypt by using the same password; once you use one of the two possible passwords for encryption, then you can only decrypt by using the other password you did not use for encrypting.

This is all the technical basis you need.

But why is this technical basis so useful?

If we use intelligently that previous technical stuff, then we can get a nice security system working.

This is the trick: you keep one of the two passwords as a secret password only you know and no one else knows; this is called your "private key". And you let the other password be known by everybody; this will be your "public key".

Thanks to this, you can nicely perform two interesting tasks:

a) You can RECEIVE (not send) information in a secure manner: since everybody knows your public key, then they can encrypt any information they want to send to you by using your public key. Since the information has been encrypted by using your public key, then it can only be decrypted by using your private, secret key; and since you are the only one who knows your own private key, then you are the only person who will be able to decrypt the information that was sent to you. (If you want to SEND information to other people in a secure manner, then you'll have to know those people's respective public keys, and use these public keys for encrypting).

b) you can SEND information in such manner that you can absolutely prove that information was sent by YOU: if you want to send a certain information and you encrypt it by using your PRIVATE, SECRET key, then everybody will be able to decrypt and read that information, because the information will be decryptable by your public key and everybody knows your public key. So your information is not protected against reading, but, since it is decryptable by your public key, then it is a complete proof that the information was encrypted by your private, secret key. And since you are the only person who knows your own private, secret key, then it gets perfectly proven that the information was encrypted by you and no one else. This is why encrypting by using your own private key is also known as "digitally signing" the information you send.

It is crucial to note that editables and the uploads tied to these will only be modified by a dashboard interaction followed by a "Start Run" from said dashboard.
A script has no control over what inputs it will receive when invoked from Runflow, from the IDE, or from the list of projects (basically, anywhere except from the dashboard). It will instead receive the same inputs as the previous run, unless manually overridden (through Runflow options, the “clear uploads” of the Run Details, or setting up dedicated inputs in the IDE).

If you need to reset an uploaded file or clear it altogether, the show upload can be tweaked into

show upload "Please upload File 1" editable:"upload1" with Hash, Name

The hash should be a 32-character hexadecimal hash, such as the one obtained from Files.Hash, and the name should be a valid filename (no forbidden characters), more importantly it should have the proper extension in order to be able to read the file .

If both the hash and the name are "", then that particular line is ignored (meaning, show upload "MyFile" with "", "" will clear the tile).

When using probabilistic lead times in actionrwd.reward, there is a possibility of encountering situations where a previously placed order is simulated to arrive later than the additional potential order considered by actionrwd. In other words, if a purchase order (PO) is in progress, the simulated purchase order generated by actionrwd may not adhere to a first-in, first-out (FIFO) rule in relation to the previous ongoing orders. This is a scenario that makes sense from a realistic standpoint, as purchase orders are not always strictly FIFO. However, from a stock manager/planning perspective, this can result in repetitive and misunderstood purchase suggestions for the user. It is unlikely that conditional lead time logic will be integrated into actionrwd, but this aspect should be addressed in the Monte Carlo reconstruction of actionrwd.
To avoid this pitfall, SCS often resort to using deterministic lead times (e.g., dirac(days)) that preserve the FIFO rule.