I will only comment on the process. I think in this case, an RFC is not needed. Having key folks from the core team (including yourself) review the proposal is, IMO, sufficient.
If Vince wasn’t on vacation, he’d need to be included too. And documenting results of the review and decisions made in JIRA would be enough.
When they’re done with this, EPAM/Folijet will be ready to work on batch importer. Depending on the nature of their technical design, they will either submit an RFC or request
a review from the key people on the core team and the architects.
Thanks,
-m
From: <tech-council@ole-lists.openlibraryfoundation.org> on behalf of Jakub Skoczen <jakub@indexdata.com>
Reply-To: "tech-council@ole-lists.openlibraryfoundation.org" <tech-council@ole-lists.openlibraryfoundation.org>
Date: Monday, July 23, 2018 at 1:36 PM
To: "tech-council@ole-lists.openlibraryfoundation.org" <tech-council@ole-lists.openlibraryfoundation.org>
Subject: Re: Reviewing EPAM/FOLIJET's technical designs
CAUTION: This email originated from outside of the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Tod and Mike,
Please review Jira tickets listed next to the issues for more detailed information. Those items require a wider review, not limited to the main contributors of mod-login/user and mod-notify. For Password Management, I assume Khalilah and
the team can make the call by reviewing proposed specifications (NIST 800-63B and ISO 27001, HaveIBeenPwned blacklist) with the SIGs and/or following best practices. I think this has limited impact on general FOLIO architecture and modules outside of login
handling. I have not reviewed the impact on SSO mentioned by Tod, though.
As far as E-mail sending and templating is concerned -- mod-notify is not directly applicable here as it targets FOLIO internal notifications. When Heikki and I discussed forwarding select notifications over e-mail (as a potential future
feature) we talked about mod-notify acting as a client to a FOLIO "email sending" module. In fact such "mod-email" module would have potentially many uses across FOLIO -- already mentioned forwarding for select in-FOLIO notifications (mod-notify), but also
Patron Notices (which requires bulk sending capability and templating) or any ad-hoc emailing capability exposed via the workflow engine. mod-email API should be fairly straightforward and I have proposed EPAM takes a stab at it (see UIU-568). What I am not
entirely clear about is the flow -- modules can interface directly with mod-email (probably unavoidable in some cases anyway, like bulk patron notices) or mod-notify is promoted to THE notification API used for both in-FOLIO notifications and external (usually
Patron facing) messaging. The former is less complex, the latter would require repurposing mod-notify API and adding a capable filtering and routing subsystem.
On Mon, Jul 23, 2018 at 6:38 PM Mike Gorrell <mdg@indexdata.com> wrote: