d3admin would either automatically build a pkg putting the .app into /Appliations, or perhaps ask the user for a target folder and build a pkg putting it there.

An empty receipt file causes hard-to-trace errors.

NoSuchItemError shouldn't prevent changes with d3admin edit.

d3admin edit package_name-1-5
An error occurred: JSS::NoSuchItemError: No JSS script with id '1234'

This could potentially allow us to not use the DB at all, although reporting would be limited due to speed issues. (unless the API eventually allows better querying)

When a receipt is frozen, the admin name and time should be recorded in the receipt, and that info available in d3admin reports and list-details on the client.

Potentially also store and report similar info about when the receipt is thawed.

If you run d3 install something-123-1 --freeze and that edition is not installed yet, then the right thing happens. However, if that edition is already installed, the command exits without freezing. Having the same edition already installed should not be considered an error.

Allow an installed package to have a firm expiration date, on/after which it will be removed no matter what. This date should accepted either as a specific date in the future, or a duration in days.

When exiting d3, make a backup of the rcpt file if it isn't empty.

Currently to use d3admin, the user must provide two usernames and three passwords, which are stored in the keychain.

API => user/passwd
SQL => user/passwd
MasterDistPoint => passwd

Devise a method for securely storing enough data in the JSS, accessible via the API, limited to the d3admin, to get the other passwords as needed.

Then store only the API username/passwd in the local keychain, possibly with one other key, for decryption.

Possible with ideas based on: https://github.com/jamfit/Encrypted-Script-Parameters

See ruby-jss, issue #8 PixarAnimationStudios/ruby-jss#8

It might be useful for, esp WRT issue #3, to pre-cache packages. either just for puppy-installs, or optionally for any package, or just packages with a 'cachable' setting.

d3 should fail to install, with a warning, and d3admin should allow you to edit the pkg to remove the offending group from the pkg settings

https://github.com/PixarAnimationStudios/depot3/wiki/Setup-add-first-package

d3admin show
An error occurred: ArgumentError: Usage: d3admin action target [options]
Action, must be one of add, edit, live, delete, info, search, report, config, help

d3admin s yields desired behaviour

what's installed does not match https://raw.githubusercontent.com/wiki/PixarAnimationStudios/depot3/d3.conf.example

Currently, you can only supply one path for an expiration, which means that it's not possible to set expirations for cases when you install multiple apps with one package, such as with Microsoft Office. Being able to comma-separate paths in the expiration path field would be great, so you can still set an expiration that resets if any of the listed apps has been used.

Package method update_master_filename not implemented in edit module

d3 makes no attempts to go find patches and updates out on the web. Integrate autopkg (https://github.com/autopkg/autopkg) to do that.

It would be great if there was a per-basename, per-host notes field, where administrators could leave a short text note for other admins. This comes up, for example, when someone has frozen a basename on a host. Often another admin will wonder, "Why was this frozen 3 weeks ago? Should I unfreeze it?" Allowing a notes field would let you explain why you froze something.

Proposed usage:
% d3 -n <message> <basename>
Sets the note message for the given <basename> on this host.
If <message> is the empty string, the note is cleared.

% d3 -n <message> [other actons]
Sets the note message for the given basename on this host in addition to doing [other actions]

For example:
% d3 -n "no upgrades until Sally returns from her overseas trip" freeze some-app

The list-* actions should display the note (if any) for each basename.

develop a method for offsite access to d3 data without using theMySQL database,which might be behind a firewall (the API will be exposed if Casper is)

Currently a failed d3 install or d3 freeze command exits with a 0 status code, which makes it hard to write a reliable shell script that uses d3.

Repro:
sudo d3 install somethingbogus && echo success
sudo d3 freeze somethingbogus && echo success

Documentation is incorrect for current PKG version:

Make a copy of the ruby-jss.conf.example file.

• If you installed d3 with the .pkg it will be in /etc/

ruby-jss.conf.example was not stored in /etc/ it was stored in the gem.

Currently the expiration feature uses a single path to an executable to determine if the installed item has been "used" lately. But some d3 packages install multiple executables, any one of which count towards "use" (e.g. if you install Microsoft Office as a single package).

By storing "expiration_paths" as an array of Pathnames, rather than "expiration_path" as a single Pathname we can accomodate this.

It will require reworking all parts of d3 that deal with expiration paths to

• handle input as comma-separated String, Single Pathname, or Array of Strings or Pathnames
• Store the package/receipt attribute as a (possibly empty) Array of Pathnames
• Store the pkg attribute in the DB as a comma-separated string
• Deal with the Array when performing expiration checks.

When a new Version of a package is introduced, the Revision number keeps it's inherited value rather than resetting. For instance, if a given package was previously at Version 2, Revision 5 and it's Version number was changed from 2 to 3, it's Revision number would remain at 5 instead of resetting to 1.

lq is parsed correctly, list-queue is not.

d3 lq
# There are no puppies in the queue

d3 list-queue
An error occurred: ArgumentError: Unknown d3 action: list_queue. Use -H for help 

d3 -H | grep list-queue
  list-queue      lq                    - Pending puppy (logout) installs

During an interactive --walkthru edit or add, when Expiration Path is changed to none, d3admin produces the following error and loops until a non-blank Expiration Path is set. "Sorry: Expiration Path must be a full path starting with /., Try again."

give d3 an 'update-receipt' action, to update a specific receipt from its matching package on demand