[caglarpir]

Uploading to an organization needs its ID in --organization_key on every run. This lets users save a name for it in the user profile, the way --user_name names a profile:

# Check the ID, save it as "work" in the profile "me", and upload
mapillary_tools upload DIR --user_name me --organization_key 1234567890 --organization_name work

# From then on
mapillary_tools upload DIR --user_name me --organization_name work

The public Graph API can't look an organization up by name or list a user's organizations, so the names are saved locally.

• --organization_name works with upload, process_and_upload and video_process_and_upload. The saved ID is checked with fetch_organization on every upload, as --organization_key is.
• Names follow the profile name rules (2-32 characters, a letter first, then letters, digits, - and _), so a name is never taken for an ID. They are case-sensitive.
• Saving a name that is saved with another ID replaces the ID, with a warning.
• An unknown name lists the profile's saved names and fails. --organization_key with anything but digits fails and points to --organization_name.
• --organization_key ID alone works as before and saves nothing. It now logs a one-line hint.
• authenticate lists each profile's saved names under it. authenticate --user_name me --organization_name work --delete deletes only that name, without logging in.

Storage: one line per name in the profile's section, e.g. MAPOrganization.work = 1234567890. Names are never written into MAPOrganizationKey, which sends every upload of the profile to that organization. That key works as before, and --organization_name overrides it for one upload. v0.14.7 reads a config with saved names, uploads with it (to no organization), and keeps the names when it re-authenticates.

Config writes: the config is now written during uploads, which may run at once. So it is written to a temporary file in the same folder and moved over the old one, and a reader never sees it half written. If that fails, it is written in place as before. That happens for a folder without write permission, a config file mounted into a container, or on Windows a config another process has open. A symlinked config stays a link, and the file keeps its mode (a new config is created readable by its owner only).

Known limits:

• Two processes saving at the same moment can lose one of the two changes, because there is no file locking. Two authenticate runs already have the same race.
• Abbreviations of --organization_key shorter than --organization_k (e.g. --organization) are now ambiguous.

Tests:

• Unit tests, with fetch_organization mocked: saving then using in a fresh config, through each upload command and into the upload history; the MAPOrganizationKey default; re-authenticating; logging in first when there is no profile; the profile prompt; listing and deleting; the name rules; the config writes (symlink, file mode, read-only folder, fallback, failed write).
• Integration tests that run the CLI against a local stub of the Graph API.