cca / equella_cli Goto Github PK

It seems like when eq is installed globally then the clipboard portion of eq launch doesn't work at all, while if I go inside the project directory and npm link it into place then it does work. Not sure what the the problem is, everything else works so the .equellarc file is being read correctly.

see https://neoconnect.pearson.com/docs/DOC-16826

Real simple algorithm for deriving item's hash bucket from its UUID, could also add an option for where on your server's file system EQUELLA items are stored so you could reuse the command's output in scp or something.

use a typical UNIX syntax with a special hyphen - argument to indicate we need to check stdin such that things like jq .uuid taxonomy.json | eq tax - work as expected

this might be tricky in terms of figuring out when stdin is a file being piped to eq or an argument and then what type of argument (e.g. we accept full URLs, shortcuts, shortcuts plus UUIDs, etc. there are many forms of arguments)

Starting with node 21, punycode is deprecated and you receive a lot of warnings when running eq like this:

(node:67092) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)

requests is the culprit, which is also deprecated. I need to switch to node-fetch.

The current infrastructure for API endpoints is messy. yargs has a nice, clean syntax for creating subcommands with aliases which would let us remove lots of horrible code.

My one question is how it would function alongside rc, whose syntax for arguments and the way it handles a default configuration file I really like and the project depends upon heavily. I'm not sure how easy those features would be to recreate under yargs.

The endpoints documentation is going to be really long, making the readme unmanageable as features are added. Should it be moved to:

• GitHub wiki?
• a separate markdown doc? (slight preference, don't like tying vital dox into GH platform)

Example: `eq tax --name "taxo that does not exist" should exit with a non-zero status. This happens in the findByName helper function.

there's like basically no documentation on the command line right now, not from a --help flag nor for any of the API routes

It might be too complicated but for data that doesn't change very often, like collections and groups (but obviously not items or taxonomies), it would be nice to cache their JSON data on disk so as to avoid HTTP requests. Could cache in ~/.equellacli or a EQ_CACHE env var, have a flag to override the cache, etc.

Since eq admin is no longer relevant, it makes sense to A) remove it from the main help documentation (but leave in the specific eq help admin for people who use it) and B) add a new shortcut command to run the launcher app, similar to my vadmin shortcut script that runs the launcher script in the background and pipes all its output to /dev/null.

One of the more recent releases introduced a second search API https://vault.cca.edu/apidocs.do#operations-tag-Search_V2 to support the new UI. It might be faster than the original but it looks promising in other ways too:

• has an identical set of parameters as the old search API, so we should get very far just copying the original code but replacing /search with /search2
• has a new mimeTypes filter
• has a new musts filter (examples: realthumb:true, videothumb:true, it says these are "search index key/value pairs" but I don't know what the list of those are, from the examples it seems like it is used to construct gallery type search results which require these sorts of preview derivatives)
• has a new /search2/export endpoint which might be the backend implementation of the new search UI's CSV export; if so, this gives us a way to utilize this new feature without needing to switch to the new UI

See https://vault.cca.edu/apidocs.do#operations-tag-Searching you should be able to filter items based on their status (e.g. DRAFT, LIVE, DELETED, etc.) but I haven't incorporated that into the search endpoint yet.

Right now running eq with no flags or arguments sends a request to GET /api/undefined which is obviously not useful, we should print the generic help documentation instead.

This opens up a whole slew of possibilities if it can be reduced to opening a particular URL, and I seem to recall there are query string parameters you can pass to the login page that are filled into the login form automatically. It'd be cool to set this up and allow users to define a login account in their .equellarc file.

After that's in place, could see a whole new command like eq access liu being useful which just opens directly to all the different settings pages (Logged In Users, Diagnostics, Theme Settings, etc.).

I often want to retrieve all taxonomies and it can be done with eq tax --path '?length=500' but that's tedious, we should just expose the length parameter on the CLI.

format: eq access liu opens the "logged in users" settings page, etc. Here's a list of valuable routes:

• liu -> /access/liu.do
• settings -> /access/settings.do
• diag, diagnostics -> /access/diagnostics.do
• theme -> /access/themesettings.do

They're simply converted to GET requests which return no information right now (or possibly throw a JSON parsing error on the empty response body?). Edit lib/req.js to have more conditions to support these and return HTTP header information.