Develop/feature/td 5829 5862 shared architecture and bff 2 #1290

Phil-NHS · 2025-07-30T15:43:18Z

JIRA link

Description

I've created a Shared Project. This project is for the purpose of sharing coding across project in the solution and is intended to in future be used instead of internal model packages. Changes should not affect the App but should allow and encourage future development to share more code resources across projects. It should also ultimately reduce duplication in the code base.

Interface are used, including marker interfaces, for specifying configurations of services being injected, and to allow injected services to be providers for multiple more specific interfaces enabling services to have less knowledge and access to methods and data they do not use.

Settings and other configuration are being split with an interface whilst maintain the current appsettings structure. This is so if only non secure data is needed in a service then only that is injected, which also supports it being useable clientside safely.
E.g. Something like:

		interface IFindwisePublicSettings { string ApiUrl { get; } }
		interface IFindwisePrivateSettings { string ApiKey { get; } }
		IFindWiseSettings : IFindwisePublicSettings, IFindwisePrivateSettings

It seems alot of files have been moved but this is due to them all being connected to the SearchService.

I've included in the Shared Project

But I assume ultimately we would migrate from it to shared but that it would not be achievable to start without it.

I recommending starting with the Shared SearchService, then PublicSettings, then HttpClients

Several recommendations and points of discussions come from this task.

AppSettings be broken into more discrete classes would mean we can inject only configuration data required into services
Chosing libraries that are system based over aspnetcore makes them more shareable where the same functionality can be provided
Comments referring to classes not used via cref results in intellisense adding that using statement. I think this would be better avoided /// The htmlhelper.
Recommendation: Future tasks of unifying code into the shared project. Initially we now have lots of code in Shared that is similar to various other projects code. A task per folder to review opportunities to unify it may be beneficially. E.g. Http, Configuration, Helpers
I had to include cachingservice in the SharedProject to support SearchService, but its kind of infrastructure and makes me feel the have internal api wrappers, which potentially did all the cache and bearer keys would create nice segregation from infastructure.
potential contenders for being shared across more projects IProvider, ResourceAccessHelper, BaseService?, BaseHttpClient
i think the documentation to go with this should have some recommendation of when moving into shared project what should happen to services, my recommendation is review them and use the right libraries and the most specific interfaces to inject, so they are clearly defined especially thinking about if sensitive configuration settings should go into them.

Screenshots

NA

Developer checks

(Leave tasks unticked if they haven't been appropriate for your ticket.)

I have:

Run the IDE auto formatter on all files I’ve worked on and made sure there are no IDE errors relating to them
** Ran style cop code clean up one, it changed every single file in the project and broke loads of stuff what do we ussually do for this??**
Written or updated tests for the changes (accessibility ui tests for views, tests for controller, data services, services, view models created or modified) and made sure all tests are passing
Manually tested my work with and without JavaScript (adding notes where functionality requires JavaScript)
Tested any Views or partials created or changed with Wave Chrome plugin. Addressed any valid accessibility issues and documented any invalid errors
Updated my Jira ticket with testing notes, including information about other parts of the system that were touched as part of the MR and need to be tested to ensure nothing is broken
[x ] Scanned over my pull request in GitHub and addressed any warnings from the GitHub Build and Test checks in the GitHub PR ‘Files Changed’ tab
Either:
Documented my work in Confluence, updating any business rules applied or modified. Updated GitHub readme/documentation for the repository if appropriate. List of documentation links added/changed:
- doc_1_here
- Will once confirmed
  Or:
Confirmed that none of the work that I have undertaken requires any updates to documentation

JIRA link

TD-5862
**I pulled a more recent version of RC, i dont know if i should be pulling on the recent rc into 5829, first at the moment alot of the changes are from RC version mismatch between first and second task **

Description

OpenApi and SearchService are affected this is actually due to merge conflicts with TD-5829

The main thrust of this task is creating a same site cookie authenticated bff to enable api calls that would go through the internal apis that are getting removed to go through instead.

There are appsettings changes as well.
The bff wont be in use until we use it with Blazor or if we want to use it for other calls.
There is discussion of the BFF in the confluence and further information in the ticket.
Some meeting notes and discussion of architecture

I have created a task that may or may not be done in future depending if it is needed. We use a same site cookie with Authentication on the BFF this keeps security concerns server-side rather than having tokens in client storage for example.
It is same site so safe it is like how csrf? on forms work. We do have on the openapi a policy for unauthenticated there are solutions to navigate this if we find we cannot hit them via the bff due to the bff refusing the initial request. (I have not confirmed any limitation of the same site cookie and there are multiple approaches to solutions so it is a little out of scope for now)

Another complexity is I believe that the apis return 3xx response that are automatically redirected by the base apihttpclient which is fine for MVC but not for blazor where it is a component post not a page post. The blazor version of the httpclient will be expected to handle this. The correct way to handle it will have options.

Screenshots

N/A

Developer checks

(Leave tasks unticked if they haven't been appropriate for your ticket.)

I have:

Run the IDE auto formatter on all files I’ve worked on and made sure there are no IDE errors relating to them
Written or updated tests for the changes (accessibility ui tests for views, tests for controller, data services, services, view models created or modified) and made sure all tests are passing
Manually tested my work with and without JavaScript (adding notes where functionality requires JavaScript)
Tested any Views or partials created or changed with Wave Chrome plugin. Addressed any valid accessibility issues and documented any invalid errors
Updated my Jira ticket with testing notes, including information about other parts of the system that were touched as part of the MR and need to be tested to ensure nothing is broken
[x ] Scanned over my pull request in GitHub and addressed any warnings from the GitHub Build and Test checks in the GitHub PR ‘Files Changed’ tab will do
Either:
Documented my work in Confluence, updating any business rules applied or modified. Updated GitHub readme/documentation for the repository if appropriate. List of documentation links added/changed:
- doc_1_here will do
  Or:
Confirmed that none of the work that I have undertaken requires any updates to documentation

… into as first code to become shared.

…ributeScreen-AccessDenied TD-5727-Fix for Full user who is not a catalogue editor/admin can access My contribution page by navigating to the link directly

…ursetray-Reorder-resource-tabs TD-5700-Reorder resource tabs on LH home page

Phil-NHS · 2025-07-30T15:44:55Z

LearningHub.Nhs.Shared/Configuration/PublicSettings.cs

+    /// that secure or private configuration data is not inadvertently exposed to clients.
+    /// </para>
+    /// </summary>
+    public class PublicSettings : IPublicSettings


If Settings was broken up into more classes/objs in the appsettings we could inject just the bits we are using, -> least knowledge and interface segregation. But I expect there would be alot involved in doing this so I am expect appsetting will stay the same and we will inject PublicSettings and have PublicX per obj, (public may be the wrong word choice).

@binon Do you agree with this approach?

Indeed, naming PublicSettings might be misleading if it implies exposure to external clients; it’s important to be very explicit about who “public” means in this context to avoid confusion among developers. Adapting more granular approach is better.

Agreed, theyre not really public theyre just not secret because they get exposed so they need some naming to signify "Do not put Sensitive Information Here" or something. i couldnt think of anything better

agreeing with binon's opinion-it can create confusion. can we use some FrontendConfig or some other names ?

So I want a consistent word so that i can do Settings : ISettings, IPublicSettings
So that we know whenever we use settings it can provide the implementations to either. so repeating the original name of the interface with an additional word to signify a subset of it I think is frontend ... in the previous meeting it was suggested we can rely on the comments to enforce not putting sensative data where it shoudnt be. But a word that really communicates it i think would be ideal.

FrontendConfig i dont think is right because though the front end does prefer not to expose it actualy the service is being given far more scope that it wants. So frontend i dont think is right.

Config I like better if it was Settings: ISecretSettings, IConfigSettings
but i dont think we will split it like this i think we will be leaving ISettings the same and then interfacing to capture a subset of the same values, (for convenience no other reason).

Other options

Settings: ISettings, IExposableSettings <-- this is my favourate so far?
Settings : ISettings, INonSensitiveSettings
Settings : ISettings, IUnsecuredSettings

Settings: ISettings, IExposableSettings <-- -I think we can go ahead with this naming convention

Phil-NHS · 2025-07-30T15:45:30Z

LearningHub.Nhs.Shared/Helpers/ResourceAccessLevelHelper.cs

 {
    using LearningHub.Nhs.Models.Enums;
-    using Microsoft.AspNetCore.Mvc.Rendering;


If we are not using this, it is only for comments here, i think we shouldnt include it. Or use System.X libraries so we don't pull through unneeded dependencies which arn't support in blazor for example, but generally more generic, more framework-neutral options are better for compatibility.

@AnjuJose011 I would like a meeting about this i think there isnt enough seperation we have infastructure and presentation concerns in models etc the shared project i think needs to be agnostic, no aspnetcore.asp

@Phil-NHS this is what discussed in today's meeting and seems a real blocker .you can please create a subtask and add more details in that ticket

Phil-NHS · 2025-07-30T15:45:56Z

LearningHub.Nhs.Shared/Interfaces/Configuration/IPublicSettings.cs

+        /// </summary>
+        public string LearningHubApiUrl { get; set; }
+
+        public IFindwiseSettingsPublic FindwiseSettings { get; set; }


This is so we map the reduced FindwiseSettings and get just what we have defined as safe. My preference would be not putting PublicSettings into SearchService but inject two separate interface with just the information it needs. this may not be correct.

@binon do you think this is okay, i would continue this naming with everything, do you think its okay?

Injecting two separate interfaces with only the needed information is more in line with the Interface Segregation Principle and results in better encapsulation. I am not sure how many more interfaces we need to add. So be mindful that injecting many small interfaces can also increase complexity in dependency management, so it’s important to find a balance.

However, bundling multiple settings interfaces (like FindwiseSettings inside IPublicSettings) into a single larger interface can lead to unnecessary coupling — it forces consumers to depend on more than they actually need.

Everywhere we inject settings, i think we should inject just the setting group we need ... e.g. findwise, if that means injecting findwise and apiGroupEg then thats fine. So more grouping of appsettings would be great but i am not going to push for it because i know its disruptive. but what will need to happen is for every group there is then a public interface should be created (as needed) because why inject what we dont need, and the private stuff should only be needed in specific places anyway.

looked at this again this is mirroring the existing settings class. which is why it has the nested interface. So this is to mirror current implementation. So agreed but this is the context behind why it is as it is.

However, bundling multiple settings interfaces (like FindwiseSettings inside IPublicSettings) into a single larger interface can lead to unnecessary coupling — it forces consumers to depend on more than they actually need.

we can rename the public setting class name to avoid confusion. agreeing here with binon- bundling multiple settings interfaces can lead to unnecessary coupling and also can increase the complexity .in the current implementation we are using a setting class(Setting.cs) that contains all related nested classes(findwisesetting.cs)

i didnt introduce the findwisesettings

looked at this again this is mirroring the existing settings class. which is why it has the nested interface. So this is to mirror current implementation. So agreed but this is the context behind why it is as it is.

-answering to this comment from your end -findwisesettings is the current setting class file we are using in Leraning Hub .interfaces you have created looks good .but i have the same opinion here with binon regarding coupling .

I agree i dont know what to do about things like this though in term of them being concidered for tasks. let me pm you coz there are few thing i think could be considered but they are not to do with the pr.

Phil-NHS · 2025-07-30T15:46:17Z

LearningHub.Nhs.Shared/Interfaces/Http/IAPIHttpClient.cs

+        /// <summary>
+        /// Gets the base URL of the API.
+        /// </summary>
+        string ApiUrl { get; }


Other versions of this functionality in other project dont have APIUrl this comes from the baseHttpClient

Phil-NHS · 2025-07-30T15:46:40Z

LearningHub.Nhs.WebUI/Services/BaseHttpClient.cs

@@ -20,7 +21,7 @@
    /// <summary>
    /// The abstract api http client.
    /// </summary>
-    public abstract class BaseHttpClient
+    public abstract class BaseHttpClient : IAPIHttpClient


This will allow blazor to inject clients into services in the same way MVC does by using the interface.

Phil-NHS · 2025-07-30T15:47:44Z

LearningHub.Nhs.Shared/Interfaces/Http/IOpenAPIHttpClient.cs

+    /// It may be extended in the future with user-specific functionality or properties.
+    /// </para>
+    /// </summary>
+    public interface IOpenApiHttpClient : IAPIHttpClient


The introduction of marker interface is so we can standardised the apis. This allows the blazor client and other projects share them and implement them differently. However another facade has been introduced, for openapi, during these tasks being created. it is probably worth at this point whether we should (i think so) we standardised and define the apis, and interfaces and how they are hit. or if its all already thought through share the outcome.

Phil-NHS · 2025-07-30T15:48:28Z

LearningHub.Nhs.WebUI/Configuration/BFFPathValidationOptions.cs

@@ -0,0 +1,25 @@
+namespace LearningHub.Nhs.WebUI.Configuration


this is the configuration file for mapping appsettings which as a test example looks like this
ive included the line above so you can find where it sits in appsettings
"SupportUrlExcludedFiles": "https://localhost/resource/excludedfiles",
"BFFPathValidation": {
"AllowedPathPrefixes": [
"search/",
"catalogue/",
"Resource/GetArticleDetails",
"Resource/GetAudioDetails",
"Resource/GetFileTypes"
],
"BlockedPathSegments": [
"Admin",
"User/Delete",
"Sensitive"
]
},

Phil-NHS · 2025-07-30T15:48:48Z

LearningHub.Nhs.WebUI/Configuration/BFFPathValidationOptions.cs

+        /// <summary>
+        /// Gets the section name for BFF path validation options.
+        /// </summary>
+        public const string SectionName = "BFFPathValidation";


i like this and how it removes hard coding in service mapping, i'd even consider interfacing it or something, unsure how it would work with nesting etc but i like i

This is a neat and clean approach

Phil-NHS · 2025-07-30T15:49:13Z

LearningHub.Nhs.WebUI/Controllers/Api/BFFController.cs

+            ILearningHubHttpClient learningHubClient,
+            IUserApiHttpClient userAPIClient,
+            IOpenApiHttpClient openAPIClient,
+            IOptions<BFFPathValidationOptions> bffPathValidationOptions)


I didnt put the name public in the interface. i didnt know i should in the other pull request i wanted to use interfacing to split appsettings into public and not. this is consumed serverside so is fine but i am unsure if it should signal public or not ...

Phil-NHS · 2025-07-30T15:49:34Z

LearningHub.Nhs.WebUI/Controllers/Api/BFFController.cs

+         if we are redirected the client may not handle it as it isnt the token holder so we need to continue using the bff until we get the outcome
+         if the BFF caller is not expecting redirects but only data they should handle the 302 response and redirect themselves.
+         E.g. A compontent that uses the BFF to fetch data may not be appropriate for redirecting to a specific page so the consuming client may need to have a way of handling page redirects.
+        */


the comments: Would like any points of view on this

Phil-NHS · 2025-07-30T15:49:55Z

LearningHub.Nhs.WebUI/Controllers/Api/BFFController.cs

+        /// Validates the path against allowed and blocked segments.
+        /// </summary>
+        private bool IsPathAllowed(string path)
+        {


black list and white list may have cracks but seemed a sensible start. specifically defining all endpoints getting used is not very flexible. it seems a good approach but would be swayed by any strong opinons on it.

Phil-NHS · 2025-07-30T15:57:57Z

LearningHub.Nhs.WebUI/Startup/ServiceMappings.cs

@@ -81,6 +85,7 @@ public static void AddLearningHubMappings(this IServiceCollection services, ICon

            // Config
            services.Configure<OpenAthensScopes>(configuration.GetSection("OpenAthensScopes"));
+            services.Configure<BFFPathValidationOptions>(configuration.GetSection(BFFPathValidationOptions.SectionName));


I like doing it this way, we may want to then nest stuff. but seems nice maybe could interface or something make this a norm?

@binon should we as standard make our classes have a section name attrinute?

…s/TD-5856_reload_moodle_user Develop/fixes/td 5856 reload moodle user

Phil-NHS · 2025-07-31T10:35:55Z

Hi @AnjuJose011 I pulled from ivory i dont understand why i have conflicts at all, i cant seem to resolve them in the editor.
@model MoodleCourseResponseModel does not seem to be in the branch once pulled. Please may my PR go next it touches alot of files so is likely to require merge conflict resolution when every ivory is updated

Phil-NHS · 2025-07-31T14:18:07Z

To build i had to update to 0.5 models but its not available yet this should stop failing once models update package relaseed

Phil-NHS · 2025-08-01T11:42:11Z

https://hee-tis.atlassian.net/wiki/spaces/TP/pages/4939153413/LearningHub.Nhs.Shared
Started putting some notes here too but needs to be agreed

Phil-NHS · 2025-08-01T11:50:52Z

please can we discuss whether we should be using httpfactories, they seem vestigial in the base controllers, facades or just the clients

binon

If LearningHub.Nhs.Shared is intended for use across multiple solutions, have you considered versioning it to improve dependency management? How are we going to manage dependencies effectively?

binon

Everything looks good overall. Just one suggestion: since each third-party interface (IOpenApiHttpClient, IUserApiHttpClient, ILearningHubHttpClient) involves the use of HttpClient, it might be cleaner and more maintainable to consolidate the configuration into a single, shared HttpClient handler or factory where appropriate. This would help avoid duplication and promote consistency.

Also, just a note—Findwise appears to have a slightly different configuration approach, so we may want to handle that separately or explicitly document the deviation.

binon · 2025-08-05T13:57:11Z

@Phil-NHS, could you pleas check the conflicts?

Phil-NHS · 2025-08-05T14:16:07Z

If LearningHub.Nhs.Shared is intended for use across multiple solutions, have you considered versioning it to improve dependency management? How are we going to manage dependencies effectively?
@AnjuJose011 @kevwhitt-hee
I dont know.
This is a good point.

I liked the centralisation approach.
The unit tests i dont think keep us safe because if they dont all pass then your not tracking when they start failing

I started thinking about this here
https://hee-tis.atlassian.net/wiki/spaces/TP/pages/4939153413/LearningHub.Nhs.Shared

And i am starting to think out architecture needs to be better to do what were doing here. And we need much better separation. - i am going to try and rewrite search as an example i think, just to tease out infastructure stuff i can and mvc presentation stuff. Ive interfaced and stubbed some stuff but i am now thinking it needs more. And that DTO and Buisness Services should be the only things in it, or application services but good interfaces for what they orchestrate?.

Phil-NHS · 2025-08-05T14:17:46Z

@Phil-NHS, could you pleas check the conflicts?

Ive previously resolved them they just appear as new thing join ivory i think ... the current ones are now because i am using the not yet released models package version, i dont understand why this is an issue seeing i needed it to resolve the previous clash.

So I am not going to until i know i am merging because i keep having to keep up, and also i dont know how to resolve it until the package is released

…ISCUSSION ONLY

…ge we plan not captured by the PR

Phil-NHS · 2025-08-11T10:30:56Z

If LearningHub.Nhs.Shared is intended for use across multiple solutions, have you considered versioning it to improve dependency management? How are we going to manage dependencies effectively?

I don't know. Centralisation will help. And I havent considered versioning LearningHub.Nhs.Shared I think i'd need someone else to lead that discussion as i think the pros and cons would be very much based on experience of the difficulties of doing or not doing this and experience of the consequences in the past in terms of when and how issues caused by this are detected.

AnjuJose011 · 2025-08-12T14:38:33Z

LearningHub.Nhs.Shared/Configuration/PublicSettings.cs

+    /// that secure or private configuration data is not inadvertently exposed to clients.
+    /// </para>
+    /// </summary>
+    public class PublicSettings : IPublicSettings


agreeing with binon's opinion-it can create confusion. can we use some FrontendConfig or some other names ?

AnjuJose011 · 2025-08-12T14:39:46Z

LearningHub.Nhs.Shared/Helpers/UtilityHelper.cs

please correct the name space

Do you mean because we wont be moving it in the scope of this release or that utility helper wouldnt be shared at the top level?

Apologies, in your local branch, the namespace for the utility helper class is currently: namespace LearningHub.Nhs.WebUI.Helpers However, it should be namespace LearningHub.Nhs.Shared.Helpers ?

Ah yes good catch! (didnt see it in chat part of pr but clear in the code bit :) )

AnjuJose011 · 2025-08-12T14:51:51Z

LearningHub.Nhs.Shared/Interfaces/Configuration/IPublicSettings.cs

+        /// </summary>
+        public string LearningHubApiUrl { get; set; }
+
+        public IFindwiseSettingsPublic FindwiseSettings { get; set; }


we can rename the public setting class name to avoid confusion. agreeing here with binon- bundling multiple settings interfaces can lead to unnecessary coupling and also can increase the complexity .in the current implementation we are using a setting class(Setting.cs) that contains all related nested classes(findwisesetting.cs)

AnjuJose011 · 2025-08-12T14:57:48Z

OpenAPI/LearningHub.Nhs.OpenApi.Models/Configuration/MoodleConfig.cs

all this files are came from ivory release branch i think .no issues if we are merging these change into LHKentila branch .as per our release pipeline Lh Kentia is after Ivory release

I expect some of them, i think alot of this is moving commonly used file to the shared folder results in lots of services and some helpers needing to be updated so they know where to find the classes they need now theyre in a new location.

AnjuJose011 · 2025-08-12T15:01:44Z

LearningHub.Nhs.Shared/Models/Search/SearchRequestViewModel.cs

can we remove ////qqq comment from here or can you please add a meaningful message?

Yep good catch its because its not going into production. but this is a mistake you may see again if i dont tidy up after myself its how i rememember to comeback to things. here is it is there to mark the breaking library.

AnjuJose011 · 2025-08-12T15:21:45Z

@Phil-NHS me and @ArunimaGeorge reviewed this PR As per today's discussion, the plan is to merge structure changes only for the initial scope right , which is LearningHub.Nhs.Shared (containing only folders and empty implementations). Given that, shared concept-related changes—considering future implementation—looks ok . I agree with binon’s comments regarding coupling of multiple interfaces and the complexities involved; Also we need to treat findwise settings separately. these can be addressed in a later version when we complete our first view component implementation.

Phil-NHS · 2025-08-12T16:10:34Z

@Phil-NHS me and @ArunimaGeorge reviewed this PR As per today's discussion, the plan is to merge structure changes only for the initial scope right , which is LearningHub.Nhs.Shared (containing only folders and empty implementations). Given that, shared concept-related changes—considering future implementation—looks ok . I agree with binon’s comments regarding coupling of multiple interfaces and the complexities involved; Also we need to treat findwise settings separately. these can be addressed in a later version when we complete our first view component implementation.

Yes. And thanks very very much for going though it

I'm less familiar with the branching process so as i understood it.

We merge this into the other blazor branch (I will do some of what was mentioned where relevant first ... more as reference as we are not taking everything across initially)
Then I need to do something like
- new branch off LHKentia (which is our blazor release branch? just checking)
  - This new branch i do a merge with no commit flag for what we have PR'd
    - I dont stage models, config, services (will require minor changes) related to the search transistion for now
    - I do stage blazor infastructure changes, so servicemapping, program.cs, layout, blazor client, shared top level, shared, bff webui level
    - I implement some other PR bits etc (e.g. use a production telblazor package ref as my dependency not local)
    - then this is PR'd against LHKentia ... which should be super easy because weve done it all now and know what want
    (I will keep a copy of what we have now so we can use it when we do get to doing the search stuff but having tried it has been very informative and resulted in agreeing config, finding package issues and various other things :) )

…ure/TD-5888-Make-LH-able-to-Host-Blazor Develop/feature/td 5888 make lh able to host blazor Merging so against one task branch which we will take only certain files from anyway

AnjuJose011 and others added 12 commits July 3, 2025 08:33

TD-5700-fix

3343656

TD-5727

20ca42e

TD-5727

19d6cfc

TD-5829: Introduced Shared Project refactored code shared with Blazor…

247ef8f

… into as first code to become shared.

Merge pull request #1283 from TechnologyEnhancedLearning/TD-5727-Cont…

2db7358

…ributeScreen-AccessDenied TD-5727-Fix for Full user who is not a catalogue editor/admin can access My contribution page by navigating to the link directly

Merge pull request #1286 from TechnologyEnhancedLearning/TD-5700-Reso…

a8c26db

…ursetray-Reorder-resource-tabs TD-5700-Reorder resource tabs on LH home page

TD-5862 Squash following merging RC changes

aa9a1a5

bit of moodle refactoring and reload the moodle user

bcd5659

Rolling back Models to 48 to fix the build

60f1317

TD-5862 restoring interface

230a260

TD-5862 reopen pull request

78709c7

TD-5862 Merge in to new branch

dcca696

Phil-NHS requested review from binon and AnjuJose011 July 30, 2025 15:43

Phil-NHS self-assigned this Jul 30, 2025

Phil-NHS commented Jul 30, 2025

View reviewed changes

TD-5829 was missing configuration of bff

99fc2b6

Phil-NHS commented Jul 30, 2025

View reviewed changes

Merge pull request #1289 from TechnologyEnhancedLearning/Develop/Fixe…

6242cfd

…s/TD-5856_reload_moodle_user Develop/fixes/td 5856 reload moodle user

Phil-NHS added 2 commits July 31, 2025 11:42

TD-5829 Ivory updated

c800d32

TD-5829 Updating to accomodate changes to Ivory

3279ef6

Phil-NHS added 2 commits August 1, 2025 09:59

TD-5888 adding blazor serverside and TELBlazor package ref

bcdff4b

TD-5888 Builds, requires httpclient and comments tidying

ce07ada

binon reviewed Aug 5, 2025

View reviewed changes

binon approved these changes Aug 5, 2025

View reviewed changes

Phil-NHS requested a review from kevwhitt-hee August 5, 2025 14:31

Phil-NHS added 2 commits August 6, 2025 15:38

TD-5888 Working when not using shared project

8167a97

TD-5888 tidy up client registration

edd96ee

Phil-NHS requested a review from ArunimaGeorge August 8, 2025 10:18

Phil-NHS added 2 commits August 8, 2025 15:00

TD-5888 NOT FOR PRODUCTION UNTIL SQUASHED AND REVISED PR FOR REVIEW D…

f06621f

…ISCUSSION ONLY

TD-5888 Adding in WebUI Shared because its quick and its the one chan…

e8943a6

…ge we plan not captured by the PR

AnjuJose011 changed the base branch from release-v2.6.1-Ivory to LHKentia August 11, 2025 13:56

TD-5888 Just adding middleware for completeness

5505e8d

AnjuJose011 reviewed Aug 12, 2025

View reviewed changes

Phil-NHS and others added 2 commits August 13, 2025 11:56

TD-5888 implementing some PR renaming publicconfig

1217fba

Merge pull request #1314 from TechnologyEnhancedLearning/Develop/Feat…

15f02cf

…ure/TD-5888-Make-LH-able-to-Host-Blazor Develop/feature/td 5888 make lh able to host blazor Merging so against one task branch which we will take only certain files from anyway

Phil-NHS mentioned this pull request Aug 22, 2025

Develop/feature/td 5930 blazor implementation integration lh #1348

Open

5 tasks

		@@ -0,0 +1,25 @@
		namespace LearningHub.Nhs.WebUI.Configuration

Develop/feature/td 5829 5862 shared architecture and bff 2 #1290

Are you sure you want to change the base?

Develop/feature/td 5829 5862 shared architecture and bff 2 #1290

Uh oh!

Conversation

Phil-NHS commented Jul 30, 2025

JIRA link

Description

Screenshots

Developer checks

JIRA link

Description

Screenshots

Developer checks

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AnjuJose011 Aug 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Phil-NHS Jul 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

AnjuJose011 Aug 12, 2025 •

edited

Loading

Phil-NHS Jul 30, 2025 •

edited

Loading

Phil-NHS commented Jul 31, 2025 •

edited

Loading

Phil-NHS commented Aug 1, 2025 •

edited

Loading

Phil-NHS commented Aug 5, 2025 •

edited

Loading