Introduction

For operations that require modifications of objects like Create, Delete and Update early warning needs to be provided to the user so they know the container is locked and being used. Ideally this information should include the GitHub login name and function that has the container in question locked.

Implementation notes

1. Pull in GitHub user name and place it into the lock file to inform another user who has the container locked.
2. Pick apart the name of the lock file to present to the user what process currently has the container locked.
3. Add information into the lock file that points to the operation being performed.
4. To support 1 & 3 it will likely be easier to create a small JSON that captures this information.
5. 1, 3 & 4 will likely be in a separate issue, but capturing here for completeness. When the second issue is created it will be placed here.
6. The implementation should be in a common resource for CLI operations like env.js

Introduction

When creating non-public companies the initial set of the name does not take and instead reverts to the default of Unknown. This results secondary impacts, notably the helper URLs for Google maps, Google patents and Google news are also set to Unknown.

Perform extra steps to make key parts of the API doc work better.

• Create an automated build
• Add search into the doc
• Figure out how to create a tutorial or additional document for the CLI
• Add branding for mediumroast

Introduction

When using the interaction add_wizard there is no link created for a company, but the interaction is linked to the company.

Introduction

Since it is possible to ingest 1:N files in a directory the revised approach is to remove the feature of specifying a single file and instead only allow for a directory to be specified.

Implementation notes

• The implementation has been changed to focus on only a directory including the code to retry if the directory name is wrong or it is not a directory. This is ready for initial testing.

Introduction

Calling the logo_server should enable the storage of an icon from a company's website. The results aren't coming back correctly. Confirmation should be made that the data is returning correctly and if so then we need to understand why the data isn't coming back in the right format.

Implementation notes

• The present implementation relies on an approach that is a layer on top of axios. This may not be optimal as it adds unnecessary complications. The suggestion is to convert into an approach that merely uses axios directly thus simplifying calls to the service.

In the setup CLI linking to the default study should be eliminated. We will pursue more complete study implementation in the Alpha 3 project.

? Your company's name is? ProductPlan
? What type of company is this? Private
Set the company's type to [Private]
? What role should we assign to this company? Competitor
Set the company's role to [Competitor]
? What region is this company in? North, Meso and South America (AMER)
Set the company's region to [AMER]
Attempting to automatically discover company firmographics.
? No company matching [ProductPlan] found, try again? Yes
? Your company's name is? ProductPlan
? No company matching [ProductPlan] found, try again? No

No matching company found, starting manual company definition...
? What's the description? ProductPlan is a platform for product managers to align their teams, collaborate on their roadmaps, and measure the
impact of their work.
? What's the website? https://www.productplan.com/
? What's the street address? 836 Anacapa Street Suite 944
? What's the city? Santa Barbara
? What's the state or province? CA
? What's the country? USA
? What's the zip or postal code? 93101
? What's the phone number? 805-618-2975
? What's the wikipedia url? Unknown
? What's your industry search string? computer
? Please choose the most appropriate industry Computers and Computer Peripheral Equipment and Software
file:///usr/local/lib/node_modules/mediumroast_js/src/cli/companyWizard.js:576
const [status, msg, [lat, long]] = await this.getLatLong(fullAddress)
^

TypeError: object null is not iterable (cannot read property Symbol(Symbol.iterator))
at AddCompany.doAutomatic (file:///usr/local/lib/node_modules/mediumroast_js/src/cli/companyWizard.js:576:33)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async AddCompany.wizard (file:///usr/local/lib/node_modules/mediumroast_js/src/cli/companyWizard.js:755:21)
at async file:///usr/local/lib/node_modules/mediumroast_js/cli/mrcli-company.js:230:19

Introduction

The default naming of the application should follow the following pattern <company_name>_discovery to signify that this is a repository for discovery artifacts.

Implementation notes

• This will be a destructive change and will follow several improvements to the initial installation experience for the user. This will cover the improvements to the GitHub Application, improved installation instructions, removal of study linking in the setup script, etc.

Introduction

This was encountered when trying to create Airtable who has a wikipedia page, but is not a public company. This means the code path should be evaluated to see what is going on.

Data from company_dns for Airtable

{
  "code": 200,
  "message": "Only Wikipedia data has been detected for the company [Formagrid, Inc.].",
  "module": "Query-> merge_data",
  "data": {
    "description": "Airtable is a cloud collaboration service headquartered in San Francisco. It was founded in 2012 by Howie Liu, Andrew Ofstad, and Emmett Nicholas.  Airtable is a spreadsheet-database hybrid, with the features of a database but applied to a spreadsheet. The fields in an Airtable table are similar to cells in a spreadsheet, but have types such as 'checkbox', 'phone number', and 'drop-down list', and can reference file attachments like images.  Users can create a database, set up column types, add records, link tables to one another, collaborate, sort records and publish views to external websites.",
    "wikipediaURL": "https://en.wikipedia.org/wiki/Airtable",
    "type": "Private Company",
    "industry": [
      "Unknown"
    ],
    "name": "Formagrid, Inc.",
    "country": "Unknown",
    "city": "San Francisco, California, US",
    "website": [
      "https://airtable.com/"
    ],
    "isin": "Unknown",
    "cik": "Unknown",
    "exchanges": [
      "Unknown"
    ],
    "longitude": -122.41966,
    "latitude": 37.77712,
    "address": "Unknown",
    "googleMaps": "https://www.google.com/maps/place/San%20Francisco%2C%20California%2C%20US%20Unknown",
    "googleNews": "https://news.google.com/search?q=Formagrid%2C%20Inc.",
    "googlePatents": "https://patents.google.com/?assignee=Formagrid%2C%20Inc."
  },
  "dependencies": {
    "modules": {
      "edgar": "https://github.com/miha42-github/company_dns",
      "wikipedia": "https://github.com/miha42-github/company_dns",
      "wptools": "https://pypi.org/project/wptools/",
      "geopy": "https://pypi.org/project/geopy/"
    },
    "data": {
      "sicData": "https://github.com/miha42-github/sic4-list",
      "oshaSICQuery": "https://www.osha.gov/data/sic-search",
      "wikiData": "https://www.wikidata.org/wiki/Wikidata:Data_access"
    }
  }
}

Related issue(s)

• #58

Observations

The following behaviors have been observed on MacOS and Linux (Ubuntu 22). Checking on WinOS has yet to be performed at this time.

• Updates to the progress bar are sluggish
• Format on Linux via the MacOS terminal are off
• The number of elements in Linux vs MacOS could be different and platform oriented. This manifests as needing to subtract 1 from the length of items on MacOS and not on Linux.

Unable to run mrcli setup:

Error messages states: "Cannot find package 'json2csv'". Even after installing json2csv, the error persists.

Discovered on Ubuntu 22.04.3 LTS.

john@medici:~$ npm --version
10.2.4

john@medici:~$ node -v
v21.4.0

john@medici:~$ mrcli setup
node:internal/modules/esm/resolve:853
throw new ERR_MODULE_NOT_FOUND(packageName, fileURLToPath(base), null);
^

Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'json2csv' imported from /usr/local/lib/node_modules/mediumroast_js/src/cli/output.js
at packageResolve (node:internal/modules/esm/resolve:853:9)
at moduleResolve (node:internal/modules/esm/resolve:910:20)
at defaultResolve (node:internal/modules/esm/resolve:1130:11)
at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:396:12)
at ModuleLoader.resolve (node:internal/modules/esm/loader:365:25)
at ModuleLoader.getModuleJob (node:internal/modules/esm/loader:240:38)
at ModuleWrap. (node:internal/modules/esm/module_job:85:39)
at link (node:internal/modules/esm/module_job:84:36) {
code: 'ERR_MODULE_NOT_FOUND'
}

Node.js v21.4.0

Introduction

To ensure that we aren't unintentionally uploading duplicates a hash should be created that checks to see if an existing interaction exists by the same file_hash. There are multiple reasons for the this and the most important is that there is no need to cause the creation of duplicates. Users should strive to reuse existing content and be prevented during ingest from adding duplicated interactions.

Implementation notes

• A new attribute of file_hash was created to store a SHA265 hash
• There's a new method called findByHash that is specifically for Interactions
• When the check occurs should a duplicate be found a boolean flag is set that determines if the file was a duplicate or not
• Progress bars were added for additional cases where we have skipped files and special files like . and ..

The @category and @subcategory options in source might be helpful to better organize the documentation.

Introduction

As we only want to have unique companies a check is required to verify that users do not enter the same name of the company again thus creating a duplicate.

Implementation notes

• This is being accomplished through a simple findByName() call and then a return back to the main CLI.

Introduction

Attributes for each object must be able to be updated by the user via the CLI.

Current status

While this basic implementation already exists in github.js it is not implemented in gitHubServer.js nor reflected or implemented in the CLI. Implementation of this feature must be done for the implementation of the interactions wizard as linking to companies mandates company object updates.

Implementation steps

Both general and specific implementation notes are provided to consider how to carefully and correctly implement the this feature. As the implementation proceeds additional notes for each object type will be added.

General implementation notes

• Updates require that the entire JSON file containing all objects is read in, the relevant objects updated, and then persisted. In this way it will use createObjects in GitHub.js. Again this is partially implemented but needs confirmation. This suggests for object updates the complete cycle that includes lock, branch, write and unlock is needed.
• Updates only for select String and Numerical type attributes generally this means lists and objects are excluded.
• Modification date must be updated when the object is updated, and therefore this attribute cannot be updated.
• JSON will be passed from the CLI and interpreted as required, note that interactions will be treated differently because of the status update capability.
• Study objects are excluded for this phase of the project and the CLI for updates will remain disabled.

In the package JSON add links for GitHub, Homepage and possibly API doc, so that users are able to reach these locations.

• Github
• Homepage
• API doc
• CLI doc

Introduction

While improvements have been made to the company reporting some of the linking and usability needs to be updated. Additionally, there are some generic improvements that should be considered for the CLI to enable a better overall experience.

Assumptions and Implementation Thoughts

Assumptions

1. TBD

Specific Implementation Thoughts

Add the following a per company compared to:

• Ideally link of the document name or ID to a section containing the description, key metadata and abstract for each of the most/least similar documents
• Add a bubble chart to visualize the competition

Generic Implementation for all CLI elements

• Consider adding page numbers
• Consider adding a table of contents
• Consider how to add a cover page

Introduction

Bridging from the user functions in GitHub.js implement mirroring CLI operations starting with reads/gets. This information is needed for interactions creation, and in the future will be required for the purposes of synchronizing permissions, user info and access controls to the backend.

CLI Improvements

At this time the following steps are recommended for operationalizing the user CLI

• Implement get all users including creating the appropriate output table
• Implement get my user to obtain all information about me
• Implement a way to return an incomplete CLI parsing object in env.js
• Implement argument removal in env.js
• Implement argument additions in user CLI

Implementation Notes

• While get all is relatively straight forward getting my user info will require a little different approach to the CLI. Specifically, we need to see if it is possible to return an incomplete CLI switch object that can be amended or we need to move generating the CLI switches to the user CLI.

For the initial release the CLI for studies should be disabled.

An improvement to the current CLI wizard for interactions need to be implemented. Essentially the following steps should be pursued:

• Prompt the user for automatic or manual interaction creation
• For manual follow the current code path
• For automatic develop a new code path that somewhat mirrors what the company automated code path performs

Steps for the automated code path include:

• Prompt for the file to be added to the interaction, this should include some configuration for the target bucket
• Upload the file to the targeted bucket
• Fetch all companies from the backend and provide a checkbox for the user to select which company the interaction belongs to
• Link this interaction to the selected company
• With the company selected populate key information from the linked company into the interaction object. This will largely be geographic data, linking information, phone number, etc.
• Fetch all studies from the backend and provide a checkbox for the user to select which company the interaction belongs to
• With the study selected populate key information from the linked study to the interaction object this is particular to the linked_study property
• Link this interaction to the selected study
• Prompt the user for the balance of the properties to set
• Register the object in the backend

Much of the logic primitives are already available to do this.

Test the creation of owning companies by:

1. Installing mediumroast_js via rpm i -g mediumroast_js
2. After installation run mrcli setup and follow all required steps
3. Once the CLI completes check out /tmp for company.json to see if your updates were stored

Variation 1

Perform the test with a public company like IBM or Hitachi

Variation 2

Perform the test with a non-public company having a wikipedia page like Cerebras

Variation 3

Perform the test with a non-public company having no wikipedia page like Mediumroast, Inc.

Introduction

The company Id used for the comparison property appears to not match the actual company Id. This needs to be remedied for the purposes of client correctness. Otherwise components, clients and using this data will present the incorrect data to the user.

Problem detail

Given the following company Ids in the system:

• Savonix Id: 3
• Precivity Id: 4
• uMETHOD Id: 1
• Neurotrack Technologies, Inc. Id: 2

When these ids are found in the comparison section for uMETHOD the key for the object is incorrect and doesn't match the system. There could be many reasons for this, but possible this is due to the system not having persistent identifies upon an object restore. It means that when a backup and a restore is done the object ids can change, and it is therefore unsafe to rely on the keys in the comparison property. A better approach would be to lookup the company id by name and then obtain the id. Since the name is the only consistent property across backups and restores this will be the preferred implementation and clients should focus on this behavior.

{
  '2': {
    name: 'Savonix',
    similarity: 0.7193503975868225,
    role: 'Competitor',
    most_similar: { name: 'Science - Savonix', score: 0.8715741634368896 },
    least_similar: {
      name: 'Bayer Selects Savonix Digital Cognitive Assessment Platform to Validate the Effects of Multivitamin Supplement Berocca in Malaysia | Business Wire',
      score: 0.7110357284545898
    }
  },
  '3': {
    name: 'PrecivityAD',
    similarity: 0.758750319480896,
    role: 'Competitor',
    most_similar: {
      name: 'C₂N Data Release for New Blood Test Combining p-tau217 Ratio with Amyloid beta 42:40 — PrecivityAD™',
      score: 0.8071120381355286
    },
    least_similar: {
      name: 'ApoE_Genotyping_Physician_FAQ',
      score: 0.5041195154190063
    }
  },
  '4': {
    name: 'Neurotrack Technologies, Inc.',
    similarity: 0.6818479299545288,
    role: 'Competitor',
    most_similar: {
      name: 'Life Insurance Industry Invests In Cognitive Health To Tackle The Future Of Aging',
      score: 0.8111998438835144
    },
    least_similar: {
      name: 'Lets Talk Neurotransmitters - Neurotrack',
      score: 0.5499856472015381
    }
  }
}

Problem resolution

In the CLI first lookup the company by name and then the interaction by name as well. This way there is no ambiguity.

Introduction

The present implementation of chart.js produces images from static data. Therefore the aim will be to connect chart creation to real data sources served from the backend. In some cases the backend may need to be updated to include new data sources for a complete implementation.

Considerations/Steps

There are two major steps needed to completely make charts live in the dashboard, both are explained below.

Make Dashboard creation incrementally more live

• Rewrite chart.js to be a module rather than a standalone app
• Create a dockerized image of the echart_server and run on the same server as minio
• Update dashboard.js to call chart.js with the appropriate data sources as they are available
• Open the appropriate port for the echart_server
• Keep the quality chart initially as a mockup until after the second step is complete

Implement quality on the backend and the CLI

Ultimately, the model for quality that is surfaced for the radar chart is simpler than what was thought up here. A more generic model and a mapping of types of content to the generic model was created. This could suggest that a drill-down report into what's included in the general model is warranted. More thought is required. The items below have been updated to accommodate the more generic approach and a parking lot matter has been added to the alpha project.

• Add a table for quality that defines the model per industry
• Consider how to normalize industries or build an industry lookup table potentially by SIC?
• Determine how to compute quality for both homogenous and heterogeneous sets of companies

Refactor wizard into smaller more maintainable modules

Currently the mr_setup utility creates the right config file, but cli.js won't read that setting. This needs to be fixed.

• Fix the code in cli.js
• Test the fix to look for the version in the config file and not the default set in cli.js

Introduction

With the emphasis on moving the basic backend to GitHub interactions must be updated to account for the change. Updates will cover interaction object creation and upload, CLI cosmetic and presentation changes, module documentation changes, and so on. For this phase only creation and unfiltered object gets will be pursued.

Basics

Necessary steps to make the CLI operational.

• Follow the template in study or company CLI to get authentication, authorization, etc. working
• Look at the guardrails in other CLIs to ensure that only the workable functions operate

Object creation

Implement what it will take to create one or more interactions.

• Move file uploads from S3 to GitHub
• Implement catch/release logic to enable a consistent flow for operations that require the container to be locked
• Implement readBlob to get file content data in base64 encoded format
• Implement links from Companies to Interactions per interaction
• Implement links from Interactions to Companies per interaction
• Update the interaction prototype to pick up company information
• Reimplement how we pick the interaction type to follow the APA style
• Externalize the choices for the interaction type
• Prompt per interaction to capture the type and associated information like author and so on

Cosmetics

Things that are going to just improve the CLI associated modules, etc.

• Change the file upload to follow the progress bar approach in backup/archive
• Change the CLI version
• Change the Process type, etc to match other CLIs
• Remove extraneous module imports
• Move and remove functions that are redundant in other modules or no longer needed

Implementation notes

• It will be important to implement a new locking mechanism that starts the lock, uploads the interactions' contents to GitHub, uploads the interaction objects to GitHub and then releases the lock. Otherwise it will be necessary to lock and unlock as each content is uploaded. This will take a long time leaving the locks in place too long. The open question is to see if there is some way to add to the GitHub module or just implement in interactions.
• When we write an object's contents to GitHub the associated URL and SHA are likely to be needed for retrieval and certainly an update. In particular the URL must be correct to be able to download the object's content, but the readObjects method may very will provide a clue.
• There are improvements in the thinking and construction of interactions in the node backend. These need to make their way into the interaction prototype for the interactionWizard.
• The URL for the object will be the repository name, directory name, and file name. We don't need an explicit URL for the object at this time. This is something we should research a bit more to see if that's right.
• Issue #51 is needed for the implementation of linking interactions to companies and potentially studies, but for the purposes of this initial implementation we will not link to or discover studies to link to interactions.
• Investigate gathering user information for the purposes of aligning creator information for the interaction.
• Note that URL for octokit or GitHub RESTful is the file name and the associated path to the file
• Updating the links for a Company requires that upodateObject be implemented. As we do this it is important to think about who can update the link for the interaction and company. If we allow the user to do it then it should be some kind of simple prompting and response. We need to also think about reviewing things.

Introduction

The installation instructions should report to the user the URL of the GitHub application such that they are able to have it installed in their organization.

mrcli company --output=csv

If ~/Documents is missing, mrcli will not generate a warning or error yet will return 0 as if nothing is wrong.

Introduction

Create a restore function for the purposes of capturing objects and enabling the restoration process.

Break things up into correct and smaller modules to enable better maintainability.

Introduction

With new data available for the comparison checking in caffeine some reporting is needed to enable the user to see the results.

Assumptions and Implementation Thoughts

Assumptions

1. Company is created and caffeine run has finished with the data made available.
2. Improvements will focus on not producing a chart/graph of the results, but adding discrete tables, prose, etc.
3. When possible we'll also see general improvements and refactoring to the reporting logic making it easier to understand.
4. When possible we will reuse existing components to limit development.
5. Consider adding boiler plate prose that explains the section(s)
6. Each company will have a separate section

Specific Implementation Thoughts

Add the following a per company compared to:

• Company firmographics need to be added per company
• Table of most and least similar scores including document name
• Ideally link of the document name or ID to a section containing the description, key metadata and abstract for each of the most/least similar documents

Generic Implementation Thoughts

• Consider adding page numbers
• Consider adding a table of contents
• Consider how to add a cover page
• As a stretch target add the bubble chart

Description

I believe that there is a potential bug in node.js filesystem module. This file is needed because otherwise the actual final of the two images that needs to be inserted into the docx file won't load. If we create a scratch file then it will. Essentially something is off with the last file created in a series of files, but the second to last file appears ok.

Obviously more testing is needed before we approach the node team with something half baked. Until then here are some observations:

1. Unless the file of a given name is present, even if zero bytes, the image data will not be put into the file. If the file name exists then everything works.
2. Again the last file in a series of files appears to be corrupted and cannot, for some odd reason, be read by the docx module and be inserted into a docx file. Yet when we look at the file system object within the file system it can be opened without any problems.

TODOs

1. Create a separate program that emulates what is done in the mrcli dashboard
2. Try on multiple OSes
3. Clearly document the steps and problem encountered
4. In the separate standalone program try using with and without axios use default http without

Introduction

In at least the CLI report, there are references to study, company and interaction objects. To ensure that there's coupling between the front end and at least the CLI generated report active links to these objects should be created. Additionally, there are links in the document to various locations these need to be verified and tested.

Links to the web_ui

Implementation assumes that the web_ui has links for these objects available and they are operable. Additionally, as the report logic is moved out of the CLI only and into the web_ui, the report should carry the same features there too.

Verify the in-document links

There are links to reports and to/from various sections. This needs to be verified and tested.

To help with consistent readability create common output formatting for the CLI related to items and sub items. The image below provides an example for formatting.

Notable ideas:

• Smarter slicing of strings to account for strings that are equal to or smaller than limit
• Set limit as a variable
• Create a function in commonWizard for all to use
• Investigate if we can add tabs to inquirer or not
• Enable coloring as a variable

Introduction

While the code operates it is not as clean and maintainable as it should be. There are functions that are in the wrong module, implementation of return codes and methodologies is variable, and so on. The aim of this issue is to capture various improvements and cleanup the code such that someone else can more easily consume it.

Implementation notes

• Return methodologies and codes: In some cases the returns are consistent with the following structure [<boolean_success>, {status_code: <code>, status_msg: <msg>}, <result_object>]. While in other cases the approach is inconsistent. The return structures should be made consistent as much as possible. The general rule is that anything returned to a caller from outside of the module should receive the structure listed above.
• Scattered implementation: There's no real philosophy for where the implementations of more complex GitHub interactions belong. The general rule should be github.js should have basic functions like readObjects, writeObjects, and so on. This would leave more complex functions like catch, create and release for githubServer.js. Further in some cases the implementation of these more complex functions is in the wizard instead of one of these two modules. A good example of this is interactionWizard.js that implements a bespoke create function for an interaction due to the fact that an interaction consists of both a JSON object and a file system object. This should be relooked at to see if everything could be moved into githubServer.js or not. Perhaps the best example of this are the delete and update functions that are well structured, but wrongly placed.
• In github.js the updateObject function should be simplified and follow the deleteObject approach. In github.js the createObject function should be simplified to follow deleteObject. In both cases the implementation should move to githubServer.js.

Introduction

Add functionality to mr_interaction to ingest contents from a directory. This assumes that all contents are associated to a specific company. Additionally, an option for creating a single interaction from a single file in the file system will be supported.

Assumptions

1. Relevant company is already registered (print warning about this) via mr_setup
2. The directory and contents are readable by the executing user
3. The file names will become the interaction names
4. We can reconstitute the bucket name from the related company name
5. All interactions associated to this company will be added to the target bucket and linked to the company
6. The company will be linked to the interactions
7. A default study will be linked to the interaction

Tests

The following tests must be performed to declare this issue completed and associated branch closed.

• Multiple files in a directory - In this scenario multiple interactions should be created when a directory exists with multiple files within. Each file will turn into an independent interaction where key data is merged with an associated company.
• Single file in a directory - Here a user will need to specify a single file name which will be transformed into an interaction.
• Fully manual case - At present this code path may not be reachable, but if possible we should attempt to test a scenario where a manual add is required.

mrcli c --add_wizard

file:///usr/local/lib/node_modules/mediumroast_js/src/cli/companyWizard.js:46
this.env.DEFAULT.company_dns ? this.companyDNS = this.env.DEFAULT.company_dns : this.companyDNS = companyDNSUrl
^

TypeError: Cannot read properties of undefined (reading 'company_dns')
at new AddCompany (file:///usr/local/lib/node_modules/mediumroast_js/src/cli/companyWizard.js:46:26)
at file:///usr/local/lib/node_modules/mediumroast_js/cli/mrcli-company.js:232:23

Node.js v21.4.0

The backup process works for mr_backup, but not the restore

• Solve the generic restore process
• Enable the user to pick from a version to restore from
• Use the file name to provide a user with which versions are available, by date, to restore from
• Test the restore process
• Document the restore process

Add developer documentation and create the appropriate GitHub pages configuration for the developer doc. This will be done with JSDocs. The prototype has already been developed, but need to add:

• Search tab

The documentation for the CLI is incomplete and should be finished.

• Add mr_setup
• Finish the company CLI doc
• Find a way to publish with JSDocs

Scope of change

1. Link the company wizard creation process to mr_setup, this will likely need to include an override for defining the registered company as the owning company, this cannot be a choice for the user as they are registering a company
2. As a part of the registration process create a bucket to store interactions for the registered owning company

Change considerations

• Setting the role property for the company may not follow the standard in the wizard you'll need to take a look at this, but perhaps we can merely directly set it. A little look into interaction.js will pay dividends.
• As much as possible a little refactoring should be considered to enable an easier time at maintaining the code. The refactoring should consider common CLI and the company wizard steps.

The application on GitHub has been updated with a new description and appropriate URLs. It is not yet listed on the market place. That will be a separate step.

Test initial user creation by:

1. Installing mediumroast_js via rpm i -g mediumroast_js
2. After installation run mrcli setup and follow all required steps
3. Once the CLI completes check out /tmp for user.json to see if your updates were stored

Introduction

The output of the authorization artifacts is challenging to read and handle. Therefore improvements need to be made to ensure users are able to more easily pick the URL and the code out from the command line.

Current output

If your platform supports this, opening your browser. Otherwise, navigate to the URL below in your browser.

                        	Authorization URL: https://github.com/login/device

                        Type or paste the code below into your browser and follow the prompts to authorize this client.

                        	Device authorization code: CE44-9B64

This is both hard to parse and read. Ideally the improvements should make it clear with coloring what needs to be copied and used from the CLI to achieve the intended outcome of authorization.

Proposed change

Improve the output logic to put the key items into a table and make the message a little easier to understand. The new output format is provided below in a screenshot.

Add the GitHub user details to the object definition like GitHub login, etc.

Introduction

For completeness object deletion needs to be built in. Given the state of Alpha_2 deletion will focus on Interaction and Company objects only. Deletion of Study objects is out of scope for Alpha_2 and deletion of User objects is completely out of scope since that is the domain of the GitHub admin.

Implementation progress

The following steps are captured based upon the implementation notes to help drive towards conclusion.

General

This will cover the simple use cases for Interactions and Companies plus prepare the way for Studies in the future.

• Follow update in structure and implement a general delete for Interactions and in the future Studies. Additionally, this will be used for simple Company deletes that leave orphaned Interactions which are unlinked.
• Simple deletion should be smart enough to delete an object and not unlink if there are no linked objects.
• We should prompt the user with the steps about to be taken and confirm they are ok with the process.
• A complete report of the actions performed should be surfaced to the user so they know the operation was successful.
• The --delete switch should take an object name

Companies

An implementation specific to Companies in gitHubServer.js.

• In mrcli-company.js we need to convert it to a similar structure as mrcli-user.js to add specific command line switches. Specifically a new option called --allow_orphans which will enable simple deletion will be created.
• When orphans are not allowed, the more complex deletion will be used that first deletes the Company and then follows up by deleting the associated Interactions.
• Interaction deletion should cleanup the actual content in the repository leaving no trace of the Interaction. This means if the user wants to maintain the interaction they must specify the --allow_orphans command line switch.
• We should prompt the user with the steps about to be taken and confirm they are ok with the process.
• A complete report of the actions performed should be surfaced to the user so they know the operation was successful.
• The --delete switch should take an object name

Interactions

The following are needed to completely remove an interaction.

• Implement a removeBlob function to completely remove the interaction contents.

Implementation notes

• Objects can only be deleted one by one, batch deletes will not be supported.
• When an Interaction object is deleted the link in the company for that object must be deleted and the modification time of the Company must be updated.
• For Company objects the situation is more complex. Essentially the decision is to delete all associated interactions when a company is deleted unless the user wants to maintain the actual orphaned interactions. There could be a use case for this where a company is acquired and then the interactions will be relinked to another as yet to be created or existing company. For clarity Mass reassignment of Interactions to an alternative company won't be supported at this stage.
• Since Study objects will need to also be supported in the future a generic version of this will be implemented in github.js while a specific version for Companies will be implemented in gitHubServer.js.

Introduction

Implement find_by_x and find_by_name for the general case to ensure the user can filter outputs with specific focus on what they are looking to see. Note that find_by_name is just a special implementation in the API for find_by_x where the attribute is name and the value is the name of the object in question.

Specific tasks

• Implement find_by_x
• Implement find_by_name
• Uncomment and enable both in mrcli-company
• Uncomment and enable both in mrcli-study
• Uncomment and enable both in mrcli-interaction
• Uncomment and enable both in mrcli-user

Implementation notes

• It may be possible to implement in mrcli-user, additional investigation is needed to confirm if this will or will not work. If it works then hopefully the implementation will be the same for the user CLI, but that remains to be seen.
• For interactions we will want a special implementation for find_by_status which will help us as we are trying to reset the status of particular types of interactions. This will help with an iterative test with caffeine as we are testing different LLMs with differing interaction types. UPDATE: By implementing a specific instance of find_by_x and get_by_name in the Users class this was feasible.

Status

This is now ready for testing.

Presently the table in the main company's section doesn't match the similarity chart. This should be aligned.