Create evidence entity

@jonathanshaw

I updated the "Default bundles" list in the IS to add info about fields. Please can you review? At the moment there are two pairs of identical ones, so we could potentially combine them.

These provided bundles are to be helpful, customisation is expected, so let's not overinvest in them. Given that, yes to everything except:

Block staff access to create/edit declarations with evidence type "web".

Better:
- block staff access to create/edit evidence with type 'web'
- block staff access to edit a declaration whose owner is the declarant

I'm seeing some very strange errors

For example admin/gift-aid/evidence-type/add gives

The "default" form handler of the "gift_aid_evidence_type" entity type specifies a non-existent class "Drupal\gift_aid\Form\Evidence\EvidenceTypeForm"

If I call class_exists from drush eval it works. If I call it from a web-page it fails. If I randomly move the file to a different directory then it works.

Similar for admin/gift-aid/evidence/add/

@jonathanshaw Any chance you could try it on your own server when you get a chance please?

Don't worry - it was fixed by a webserver restart.

I have some doubts about usability. With inline-entity-form it could be good - staff ideally won't even notice there are 2 entities.

Without that it seems pretty bad. The evidence entity it hard/impossible to refer to or select. My current implementation has no fields for donor, no declared date, no "record type" because I realise that they would all be duplication of the declaration. Nor does it have a label, and I don't see any sensible way to create one.

Even with inline-entity-form, we are adding complexity. It could be quite a lot simpler if we just let staff upload any file that they like (in other words use a file field). I agree it's a bit of a hack. And it doesn't work so well with the self-declarations, but I guess we could add a different field for those (which doesn't need a form UI because they are generated in code).

So I don't have a clear suggestion, I'm just putting it out for discussion if you feel. I'll have a quick try with IEF.

I recall your caution about IEF and I am reluctant to create a situation where we cannot work without it.

I've had some ideas in a different direction based around a simple series of integrated steps for staff:

1. Staff look up the Donor, or create one if it doesn't yet exist.
2. From the Donor page, select an evidence type using a drop-down, then click the "Add evidence" button.
3. This brings up a page for creating evidence, with the donor ID included in the URL query string. The page includes an "options select" field to choose what action the evidence is for: declare, cancel, change of address, or misc correspondence. When staff click "Create", they are redirected to the correct next page, either editing the Donor, or creating a declaration/cancellation entity.
4. The new page URL includes the evidence ID in the URL query string and also the Donor ID for the cases where we create the entity. The corresponding fields are pre-filled and hidden/disabled in the form.

I will experiment with it. Please let me know any opinions/feedback.

I think we can't get away without depending on IEF at least some of the time. When we have existing evidence and want to allow staff to add more it's the obvious UX.

IEF is generally fine if you don't need to nest one IEF inside another. It's nesting that is especially flaky. And in our case we don't need to do that, so we should be fine.

Given the budget constraints, I think we should go with IEF as the bare minimum working solution to get us to a MVP solution for the module as a whole. Once we have that MVP, we can revaluate what if any problems we have budget to fix.

Nor does it have a label, and I don't see any sensible way to create one.

AFAIK a lot of stuff breaks without a label. I'd use the bundle name as the label for now. The paragraphs module has prior art on autogenerating a text summary from arbitrary fields, but that's unecessary chrome for now.

Staff look up the Donor, or create one if it doesn't yet exist.
From the Donor page, select an evidence type using a drop-down, then click the "Add evidence" button.
This brings up a page for creating evidence, with the donor ID included in the URL query string. The page includes an "options select" field to choose what action the evidence is for: declare, cancel, change of address, or misc correspondence. When staff click "Create", they are redirected to the correct next page, either editing the Donor, or creating a declaration/cancellation entity.
The new page URL includes the evidence ID in the URL query string and also the Donor ID for the cases where we create the entity. The corresponding fields are pre-filled and hidden/disabled in the form.

Youre quite right that using a 2 page form process is a viable alternative approach.

The obvious approach for a declaration is like this:
1. When staff create a declaration, the declaration create form redirect is set to the evidence bundle add page (where they select the bundle)
2. They select the evidence bundle
3. This takes them to the evidence add form. The declaration id from step #1 is persisted through the URl to this point, an the evidence is added to the declaration on submission.

The problem with this approach is that the declaration exists in a weird draft state at first if the evidence is not submitted. In the approach above it doesn't even know if it's oral or not at first. We can get round this by moving the bundle select into the declaration create form, but it doesn't avoid the need for a draft declaration state of some kind, and likely some cleanup of drafts that don't get finished.

For cancellation, change of address etc, your approach had staff choose the evidence bundle first and the action second; I think t's important to reverse that. Staff should be first choosing an action that expresses their goal "cancel", "Change address", etc., before they have to think about evidence.

Overall I suggest seeing how far you get with IEF OOTB. Customising IEF is possible - there are sane ways of doing it, but it can also get hairy fast so I suggest discussing with me before entering that rabbit hole too far.

I already use IEF in my project in myriad ways (!nested!) so the dependency on it here is not scary for me at all.

Overall I suggest seeing how far you get with IEF OOTB.

I think we can't get away without depending on IEF at least some of the time.

Once we have that MVP, we can revaluate what if any problems we have budget to fix.

Great I'll go with IEF.

Your wording suggests you imagine some flexible mixing / interchanging. For me it feels like 2 quite different approaches - IEF or multi-stage. I don't really grasp how one could mix them, or easily change between them. However I don't have so much experience with IEF, so you might be right.

The remainder is explanation of how we could make the multistage work if we later choose to.

When we have existing evidence and want to allow staff to add more it's the obvious UX.

I feel I could make it work with a decent UX. I described how the evidence ID could be passed into the Donor edit form. Declaration/cancellation I had imagined holding just one evidence.

The problem with this approach is that the declaration exists in a weird draft state

Exactly - that's what I wanted to avoid.

Staff should be first choosing an action that expresses their goal "cancel"

Good point. I feel that we could do that, and still create the entities in the simpler order. We could prompt the staff to choose an action type, then an evidence type, then upload the evidence entity, then create the action entity/revision. The action type gets passed through as another query parameter.

AFAIK a lot of stuff breaks without a label.

Yes, I mean we don't have a meaningful label that would usable in an entity reference widget.

IEF works well at first glance and it was very easy to set up. So your remarks in your previous comment make much more sense to me now - if we later stop using it by default then it cost us nothing.

If we rely on IEF, it could save some coding. In the Evidence entity, we could avoid writing code for links, route provides, access control, list builder, views, corresponding CrUD testing, etc. That's in addition to avoiding the explicit extra code for the multi-step with all the query parameters, pre-populated fields, etc.

I am still attracted to have the declare/cancel buttons on the donor which pre-populate the Donor ID by means of a query parameter.