| TCR-29 - mod-fqm-manager | | - Jeremy Huff trying for intent of requirements when application of the letter of the law is perhaps
- Technically, no consumed APIs, but has an operational dependency on other modules. Should these be declared?
- The criteria was very specifically worded back when there were only APIs. Marc Johnson suggests we say this meets the letter of the law
- Matt Weaver , there's a technical limitation in that eventually if we list everything that we want to consume, there will be circular dependencies.
- Accept this limitation and move on, will be related to the schema issue later.
- Not all APIs are included in the OpenAPI spec
- The team has not had a chance to address this as the problem was only identified last night and noted now.
- Concern was raised about module permissions not being declared. The module exposes other module's data, but permissions to interact with those other modules are not required.
- This overlaps with the cross-module DB access issue (not discussed yet in this meeting)
- Vince: There is a solution which the team is looking at (using permissionsDesired) which would more clearly satisfy this criteria
- Craig: We already run into a similar situation in FOLIO today... If a user has permissions to call orders, and orders gets info from organizations, inventory, etc. The response from the orders API includes data from those other modules even though the user making the request doesn't have permissions to access those module directly.
- Vince: The risk is mitigated in the FQM case since only particular fields are exposed, it's not exposing entire records from these other modules (e.g. the full user record is not included in the FQM response)
- Vince: Views are not created at runtime. The negotiation of what is included in a view happens between developers
- There are several areas where FQM will play an important role in solutions to problems - e.g. bulk edit, record deletion
- Cross-module DB access...
- Jeremy: The data lives in other schemas, even if the views live in the FQM schema
- Vince: The entire purpose of this module is to access/provide data from other modules. FQM does not directly access the other DB schemas, it effectively accesses other DB schemas via views.
- Vince: From FQM's POV, it's just accessing it's own DB schema.
- Vince: Ultimately, it comes down to the point that we NEED this capability in FOLIO to help us not only with lists app, but in several other areas as well.
- Record deletion - design already in place
- Bulk edit - mentioned earlier.
- Data export - ability to filter record set being exported
- Data import - performance improvements in matching BL
- In-app reports - could be improved by using FQM
- Vince: We DON'T want to open this up and allow module developers to do this all over the place. We want mod-fqm-manager to be THE place where this happens in FOLIO.
- Jeremy: I think the creation/mgmt of views should not be FQMs responsibility. Other modules should "opt-in" to this somehow
- Vince: the problem being solved here is that you need to join large datasets from different modules. Without FQM that means pulling down large responses from multiple modules, then finding the intersection/doing the join in BL. Using a DB join allows you to do this in the DB where it makes more sense
- Maccabee: I support the RFC suggestion - It would be great to see a list of pros/cons, risks, etc.
- Marc: What information do we need to make a decision today?
- There's significant political will to get this into Poppy
- There are 3 outcomes... allow, disallow, or run out of time and disallow by default.
- Jeremy: The set of unknowns is unknown. I don't feel comfortable approving this module until we have time to go through the due diligence (RFCs, etc.)
- Vince: There are two things at hand:
- Does this get into Poppy? → The time pressure
- What is the future of this? → If the project decides we don't want this we need to pump the breaks and undo some work which depends on FQM.
- Jeremy: I feel uncomfortable treating a TCR as a way to make an architectural decision. The TCR fails the evaluation criteria.
- Craig: There is some precedence for separating architectural concerns from a TCR – mod-settings for example.
- Julian: mod-settings has solve permissions problems where this module has not yet solved.
- Maccabee: We have in the past given a pass on certain criteria we thought is outdated, or unfair. In this case it's different.
- Craig/Marc: Another option is to vote on conditional acceptance
- Owen: that would allow this to go into Poppy, but we need to be cautious... This is underlying some other development. Conditional approval does not reduce the risk for that work.
- Vince: We should also think about why we would be rejecting the TCR... could be:
- We're being sticklers and this criteria isn't met.
- We don't like how this played out - we would have liked it if the TC was involved earlier, etc.
- We don't like this from an architectural perspective – <there was more here but I missed it>
- Tod: From my perspective this seems like the direction we want to head (a central cross-domain broker for these types of things)
- Vote for unconditional approval failed with 6 against
- Vote for conditional approval passed with 5 for, 4 against.
- Conditions being: We will proceed with RFCs and depending on the outcome, mod-fqm-manager may need to be changed.
- Craig will draft a statement about why the TC approved this even with failed criteria. He will post to tc-internal and then update TCR if there aren't any objections to what is being said.
|