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.

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.

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.

I altered the default evidence types slightly:

• Separate PDF from image because they need different widget/formatter settings
• Combine the in-person and remote versions of each type to avoid doubling the number of types (already there are 15 files). The admin can easily clone them, or add a field "in person" if they wish.

Continuing the previous approach, I would like to commit this now please, deferring your review until we have something useable and self-consistent.

Then I will move on to #3512674: Flexible contexts and donors followed by #3505467: Finish the declaration forms and #3505330: Additional information when viewing Donor entity, perhaps something else smaller. That would be the point for review. For sure it won't be feature complete, but at least all the features that are present should be useable, and any known issues be documented.

Thanks that was quick😃