Skip to content

Conversation

@kleintom
Copy link
Contributor

@kleintom kleintom commented Oct 20, 2025

Remaining TODOs:

  • DwC occurrence rows for anatomical parts
  • is_material cleanup: shouldn't be able to edit it in descendants; validate CO can only be is_material, etc
  • Add is_material validation for containerized APs
  • Add soft validation for uri

`rails g scaffold AnatomicalPart name:text uri:text uri_label:text is_material:boolean`
Previously it showed only originOf options (or vice versa) in the select, even when you flipped the direction.
This would be setting a new precedent - no other OR types currently allow creation in this form.

The issue is: e.g., there is no association between CO and AP. Instead we have an origin relationship betweeen the two. (We probably don't want to maintain two lists?)
Quick forms can, by design, only be used to create new association objects. So technically we can't have an AP quick form slice since APs are (rails-)associated with no models.

So this is a compromise we may or may not want to proceed with. Currently the alternative would be to create the new AP from a New AP task or from the data New AP task, then search for that new AP in the AP search form on the quick form for Origin Relationship on a CO.
…4407

Means we don't have to remember to add a new type in 3 extra places everytime we want to add a type to observables.
Now New BA should auto-update BA subject/object options whenever a new BA type is added in rails.
…4407

This might still need work: only the 'new' table can be reordered, but keeping separate 'old' and 'new' lists with 'list = old + new' kind of breaks the expectations of `useSlice`.

Also the existing way of updating position is broken in some cases (probably in other components as well) due to the way acts_as_list works when you add an item that has the same position as an existing item.
taxonomic_origin_object is the root of the chain that must exist from every AP back to a taxonomic (via otu) object.

In turn, every taxonomic_origin_object determines a tree of descendant APs and optional leaf endpoints of origin relations with AP origin.
Necessary for validation. Also means you can't create an AP as origin object in quick forms (at least not without also requiring taxonomic_origin_object to be specified, which I don't think we want to do).
Constant on `old.object_type + new.object_type`. Maybe too much??
It's a little painful to have to click through the origin relationship modal like 4 clicks to get to 'New AP'.
Nice! I thought this was going to be trickier.
If we were expecting large spreading graphs then the original was probably better. We are not expecting that.
Time-costly oversight (to debug) of AI-added code :(
Thanks to ai for pointing me to `OriginRelationshipDestroyContext < ActiveSupport::CurrentAttributes` (same way `Current` works) when I/we couldn't get `destroyed_by_association` to work in this context.

I changed destroy on AP to be disallowed unless it's the *terminal* object of the chain. It seemed like deleting an AP with child and Extract or Sequence would be a bad thing.

You can now delete APs from the graph using the navigator menu, and it will stay on the updated graph. (Otherwise you'd have to search for each object of the chain and delete one at a time.)
@kleintom
Copy link
Contributor Author

kleintom commented Oct 20, 2025

  • Publish Hookaido and change gemfile to use published gem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants