Add ability to add independent resources from the remote side of a one-to-many relationship.

[benanhalt]

e.g. Adding collection objects to an accession from the accession form.

This is complicated because it is actually mutating the collection objects, not the accession.

[benanhalt]

The record selector widget was supposed to be able to do this, but there were issues so I disabled that in 5525150

[maxpatiiuk]

In cases such as adding associated collection objects to Accessions, the add button should be brought back. It was previously taken out because of how buggy it was, but it's kind of an important feature and it's probably a good idea to look into it.

[grantfitzsimmons]

Somewhat addressed by #2377

@tlammer and I are of the belief that having the ability to add collection objects on the form is important functionality in Specify for instances like accessions or collecting events.

In our opinion, ideally adding collection objects to the form should not be associated until the entire record is saved (a la Specify 6 behavior).

As a compromise, having the ability to instantly associate them after the record has been created can work as well.

I asked Ben his thoughts on this-

Me: for Accessions and Collecting Event records, there is no way to add COs to them from the form. In Specify 6 this is supported. What is blocking that ability?

Ben: When you're using the Accession form the save button implies you are changing the accession, but if you are adding COs to an accession, that is changing the CO and not the Accession. I don't know how Max has changed things, but the frontend code that I had developed couldn't handle that discrepancy in meaning.

It's also confusing from a UX perspective. When you add COs that way should the save button even become active? Or should the COs be added immediately? If they aren't added immediately the system is keeping track of the changes COs and only saving them when you click save on the Accession form which would ordinarily be saving the Accession.

I think it would be better to make them work like other interactions, or save it to be part of batching editing of Collection Objects since that is what is actually happening.

[grantfitzsimmons]

@melton-jason @acwhite211 Can we discuss this as a priority to consider in the next few months?

This will enable things such as

• Allow interactions to work correctly
  • Accession, Exchange In, Exchange Out, Disposal, etc. require this to add COs to the form. Currently you need to remake the entire record from scratch...
• Containers need this to allow adding children

Can we consider making these instances read-only if that makes it easier? We don't need to support editing these records in this view, just adding them.

The difficulty is that it is updating the independent resource rather than the record currently being edited. Maybe we can defer to Specify 6's handling of this or we can make the change to the linked records immediately after saving. There is a lot to discuss in this implementation.

[maxpatiiuk]

@grantfitzsimmons This is a front-end-only feature. I don't think it will require any back-end modifications

[melton-jason]

Well, in case the backend implementation turns up again (and may be beneficial), I have actually been looking into a similar solution regarding accessing the remote side of relationships for extending deletion blockers in #1694.
I have a working solution which is albeit a little hacky currently (hence why I am probably not going to include it in #1694 until it is refined further).

However, I can still look into implementing this on the frontend.

[melton-jason]

I am not sure how the importance of this compares to extending the workbench functionality, but this is probably more important than refactoring business rules, so I could tackle this soon™. Perhaps concurrently with workbench changes

[grantfitzsimmons]

@melton-jason For now, let's focus on extending the WorkBench by solving #2331.

This issue has a lot of gimmes if we fix it. As I mentioned, better interactions, containers, and unlocking many independent resources from the remote side all across Specify. I think fixing this should be a high priority but don't let it derail your current plans. Thank you!

[maxpatiiuk]

Even though this is high priority, I would suggest delaying the fix until the front-end ORM is rewritten (we plan to do that as soon as Jason is done with business rules refactor). That will make this task simpler. Otherwise, there would be wasted effort

[grantfitzsimmons]

This was reported by UMich again today as an important issue to resolve.