Tech Debt: Refactor report version access middleware
- Dominant language
- No language data
- Stars
- 0
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
#### Description of the Tech Debt
We have a `withRuleHasRegisteredOperation` middleware that queries the API on every request, whether a user has access to the reporting module (if it has a registered operation) and that tries to extract a report version to check against.
This is basically an extra request to ask the API "is the request I'm about to make legit, and how is it going to fail?"
We could instead refactor how the server responds, if we could use either HTTP codes, a { redirect: ... } key in the ninja schema, or a combination of things between the python API and the `actionHandler()` method
There is a bit of exploration needed here, to see what would be the most effective and if there are NextJS best pratices
#### Tech Debt Triage
The purpose of our technical debt triage process is to analyze technical debt to determine risk level of the technical debt and the value in tackling that technical debt.
#### Risk Value Scoring:
| Level | Value |
| ------ | --------------------- |
| High |
| Medium |
| Low |
| Technical Debt - Risk Types | Level | Value |
| ----------------------------------------------------------------------------------------------------------------------------- | ----- | ----- |
| Business Area Risk - Risk of business area visibility / damage to user experience | 0 | 0 |
| Developer Fault Risk - How likely will this tech debt cause a future error related to coding on top of it | 0 | 0 |
| System Fault Risk - Risk of system errors or application downtime | 0 | 0 |
| Time Scale Risk - Compound risk effect if left alone. How much more difficult to fix or dangerous will this become over time? | 0 | 0 |
| Time Sink Risk - How much will this tech debt slow the development process down | 0 | 0 |
|
#### Development Checklist:
- [ ] Checklist item
- [ ] Checklist item
- [ ] Checklist item
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by tracing the withRuleHasRegisteredOperation middleware and actionHandler() entry point, then inspect how the Python API currently reports access and report-version failures. Compare the possible HTTP-code or redirect responses with relevant NextJS practices. Done means the team has selected and documented a response approach that avoids the extra API request while preserving the required failure behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- nextjs, python
- Domain
- api, backend-api-design
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100