Fix issue of user not being able to submit assignment when logged in root account

[suhaibabsi-inst]

refs: MBL-18064
affects: Student,Teacher
release note: Fixes issue of user not being able to submit assignment when logged in root account

What's changed

The main point of change of this PR resides in files:
AppEnvironmentOverride
CourseTabUrlInteractor
Router

This is to provide a clean way to pass a modified AppEnvironment with the correct baseURL that fits the current tab user is sitting at, which in this case is Course > Assignments

The rest are a consequence of those changes, which is basically to make sure views and classes are respecting what ever AppEnvironment instance is passed to them.

Test Plan

See ticket description.

Also, made testing for ordinary accounts for following use cases:

1. View Assignment details
2. View Submission details
3. New text and file assignment submission.
4. New text and file submission comment.
5. View submission comments, especially those with comments.

Also, testing for the following scenarios:

1. Tapping on external link.
2. Tapping on an internal link for an assignment, making sure submission work as well for both of cases.

Screen Record

demo_consortia.mov

Checklist

• Follow-up e2e test ticket created
• A11y checked
• Tested on phone
• Tested on tablet
• Tested in dark mode
• Tested in light mode
• Approve from product

[inst-danger]

	Warnings
⚠️	One or more files are below the minimum test coverage 50%
⚠️	The total test coverage is below the minimum 90%

Release Note:

Fixes issue of user not being able to submit assignment when logged in root account

Affected Apps: Student, Teacher

MBL-18064

Coverage	New %	Master %	Delta
Canvas iOS	89.98%	90.05%	-0.07%
Core/Core/AppEnvironment/AppEnvironmentOverride.swift	32.76%	--	--
Core/Core/Planner/CalendarMain/ViewModel/PlannerViewModel.swift	0%	0%	0%
Core/Core/Planner/CalendarMain/Model/CalendarWeek.swift	0%	0%	0%
Core/Core/Extensions/CGSizeExtensions.swift	0%	0%	0%
Core/Core/Planner/CalendarMain/View/Calendar/CalendarCardInteractionState.swift	0%	0%	0%
Core/Core/Planner/CalendarMain/Model/PlannablesInteractor.swift	0%	0%	0%
Core/Core/Search/Model/SearchSupportButtonModel.swift	0%	0%	0%
Core/Core/Planner/CalendarMain/View/Calendar/ViewPreferences.swift	0%	0%	0%
Core/Core/Planner/CalendarMain/Model/CalendarDay.swift	0%	0%	0%
Core/Core/Courses/SmartSearch/View/CourseSmartSearchViewsProvider.swift	13.64%	13.64%	0%

Generated by 🚫 dangerJS against ec8b11e

[inst-danger]

Student Build QR Code:

[inst-danger]

Teacher Build QR Code:

[suhaibabsi-inst]

@vargaat

I updated the code to use the Router's CourseTabUrlInteractor object to tweak all URLs pointing to internal course pages, regardless of their source.

For the point of API tweaking, when attempted I had to face the issue of this property access on LoginSession:

AppEnvironment.shared.currentSession?.baseURL.host

Which is very common place in code, and it is sometimes used to authenticate API requests, which would make the tweak of the baseURL on the API level a very missy and uncontrollable step.

If we were to go this route, we must guarantee that the value of this property on LoginSession is the same as the value on API whenever they accessed in the same context, and that would be impossible without fixing the dependency injection of AppEnvironment through whole the app. That's because changing this value would require passing information about the called endpoint, which is a dependency as well.

That's why using AppEnvironmentOverride, to me, can provide the framework to do so gradually.

Places where you can find such access:

canvas-ios/Core/Core/API/API.swift

Line 244 in 014347f

if let authorizationHeader = task.originalRequest?.value(forHTTPHeaderField: HttpHeader.authorization), request.url?.host == AppEnvironment.shared.currentSession?.baseURL.host {

canvas-ios/Student/Widgets/GradesWidget/Model/Routes.swift

Line 22 in 014347f

private var host: String? { AppEnvironment.shared.currentSession?.baseURL.host }

[rh12]

I think we usually pass in the primary data/model first which is the main subject of the whole type.
Then the secondary ones.
And in the end we pass in the dependecies, like interactors, env, router, etc.
Maybe this is only me, but it would make sense to me to keep this ordering.
May look like nit, but I would rather call this out now, at the beginning of this approach.

The same stands for all the other places where we inject env in this PR. cc @vargaat for thoughts

[vargaat]

Yes, I agree, that bloated environment object is definitely not a primary dependency. I didn't notice this during my review but let's keep the priority order in the future.

[vargaat]

QA+1, I was able to submit to both consortia and my regular account various ways. What I noticed and I'm not sure if this can cause any issues or not is that when submitting via the share extension the file upload request still goes to the root account while the submission goes to the child domain. This is because the file upload logic for the share extension fetches the base url for its own but only for the last API request. On the image the non-selected rows are from the share extension and bottom ones from the app.

I also managed to make the app crash two times during submitting files from the app. I couldn't reproduce it with Xcode and for some reason the crash symbolication didn't succeed so let's keep an eye out for this while testing the RC.