Created on 11 February 2025, 13 days ago

Problem/Motivation

  • Choose charity with drop-down rather than auto-complete
  • Shorten some very long field labels, instead putting information into the description (E.g. "Is this an enduring declaration that covers all donations within a period of time?")
  • Avoid using technical jargon such as entity in UI menu/ page title, e.g. "Declaration type entities" => "Declaration types"
  • Combine the 2 Commerce sub-modules? People might forget to enable both.
  • Put entity links on declaration listing
  • Commerce pane improvements. Give information. "Thank you already covered". "Sorry not eligible". "£XX.XX of your order is eligible". Maybe these supersede the when options? Allow to configure the data parameters of the declaration?
  • Fix deprecation notices in test results
  • In GiftAidDeclaration::submitPaneForm(), set the Declaration date to match order date
  • Associate declaration with User rather than Order if available, then can drop second half of code in GiftAidRelatedContextsSubscriber. This should be much better performance and more intuitive.
  • Change some cases that are currently invalid declaration, into required fields?

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

🌱 Plan
Status

Active

Version

1.0

Component

Code

Created by

🇬🇧United Kingdom adamps

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @adamps
  • 🇬🇧United Kingdom jonathanshaw Stroud, UK

    Choose charity with drop-down rather than auto-complete
    Shorten some very long field labels, instead putting information into the description (E.g. "Is this an enduring declaration that covers all donations within a period of time?")
    Avoid using technical jargon such as entity in UI menu/ page title, e.g. "Declaration type entities" => "Declaration types"

    All sound good, maybe a UI cleanups issue.

    Put entity links on declaration listing

    Very likely makes sense. Maybe we should have a listing issue, as you point out it should have more work to enhance auditability, but this is not the thing to tackle first.

    Commerce pane improvements. Give information. "Thank you already covered". "Sorry not eligible". "£XX.XX of your order is eligible". Maybe these supersede the when options? Allow to configure the data parameters of the declaration?

    Interesting. Would need more discussion in its own issue. I wonder if its necessary in the 95% use case.

    Fix deprecation notices in test results

    Great

    In GiftAidDeclaration::submitPaneForm(), set the Declaration date to match order date

    Maybe. I'm not sure quite when/if it matters. But it makes me think we should have an issue "Ensure compliance if an admin checkouts an order for a donor" as that scenario raises all kinds of hairy compliance questions.

    Associate declaration with User rather than Order if available, then can drop second half of code in GiftAidRelatedContextsSubscriber. This should be much better performance and more intuitive.

    We lose quite a lot of audit information about the context of the declaration. Maybe that doesn't matter. I have an attachment to the way we currently do it, but I think you are probably right.

    Change some cases that are currently invalid declaration, into required fields?

    Worth considering.

  • 🇬🇧United Kingdom adamps

    Thanks for the replies, good points. For the moment I have been hesitating to create tons of new issues for things we might never do. This issue is somewhere I can dump my (sometimes quirky) ideas with minimum effort so I don't forget.

    I feel that the next step is for you to do some triage/prioritisation and pick some topics for me to work on. Potentially I could then create the issues at that point?

    I added 3 new bullets to new IS.

  • 🇬🇧United Kingdom jonathanshaw Stroud, UK

    Yeah, I figured this was a notepad of sorts. See 🌱 [META] Roadmap Active for priorities.

Production build 0.71.5 2024