Clarify purpose of available_methods in beamline_config.yml

[axelboc]

I'm trying to refactor the ContextMenu component and some of the code relies on the beamline configuration below, so I'd like to understand its purpose a bit better:

available_methods:
  datacollection: true
  characterisation: true
  helical: true
  xrf_spectrum: true
  energy_scan: true
  mesh: true
  ssx_chip_collection: true
  gphlworkflow: true
  test_collection: true

---

This available_methods configuration is first made available to the front-end through the beamline.availableMethod global state, which is used to hide options from the sample view's context menu.

The code that does this is unnecessarily convoluted, but basically it removes any option with a matching key in available_methods that is set to false. So if we have:

available_methods:
  datacollection: false
  ...

... then the context menu action with key datacollection doesn't get displayed. The current logic cares only about "methods" that are set to false and ignores the others (i.e. it's an opt-out mechanism).

---

Now the available_methods configuration is also used in Queue#get_available_tasks(). In this case, it's an opt-in mechanism: each task is made available only if its corresponding key is defined and set to true in available_methods.

Available tasks are made available to the front-end through the taskForm.defaultParameters global state:

When a "method" is set to false (or not set all) in available_methods, the corresponding task no longer appears in the defaultParameters object.

---

Okay, so with all this in mind, I'm curious to know how the available_methods is actually used in practice:

• Can all the "methods"/"tasks" actually be turned off? If I set datacollection to false, for instance, it removes the Data Collection option from the sample view's context menu, but not from the drop-downs and context menus on the Samples page (e.g. Add Task to Samples button) ... in fact it makes those remaining Data Collection options inoperable (error in the console).
• If a custom "method"/"task" has to be defined and set to true in available_methods for it to be exposed to the UI, then isn't this simply incompatible with the opt-out mechanism of the sample view's context menu? Is there a way that I'm not seeing to expose a task but also hide it from the context menu? Is this even a need in practice?

[marcus-oscarsson]

The idea is that a method needs to be set to true in available_methods to be available. It has in most cases little meaning for the standard datacollection and characterisation. Its true that available_methods is not yet respected on the sample list page and that is something we should address. There are probably some details to this that we should discuss to make this a bit more clear, but you are right that the current logic is quite convoluted and the concept only partially implemented. I'll pass by tomorrow and we can have a look at some of this to get the cleanup continued.

[axelboc]

Thanks, okay, so basically:

• Keep the opt-in behaviour (even for datacollection and characterisation)
• Make sure it is respected in the UI (especially on the sample list page)
• Change the logic in the sample view's context menu to also be opt-in rather than opt-out (i.e. show an option when the relevant method is defined and set to true in the config)

I'd also argue that we don't actually need to expose available_methods to the UI, since it's only used by the sample view's context menu and the same information can be inferred from the taskForm.defaultParameters object (if a method is present in this object then it's available). I could make a hook like useMethodAvailable() to abstract this so it's clear in the code.

[marcus-oscarsson]

Thanks @axelboc thats a good and clear summary :). It also a good idea to not expose available_methods, taskForm.defaultParameters would contain the same information.