feat(7369): authentication

[javier-perez]

feat(7369): Authentication

Description

Full authentication stack to the admin-tool. This included four new services (LocationService, SessionService, ChtDatasourceService, AuthService), an AppRouteGuardProvider for route-level permission checks, and an [mmAuth] directive for template-based conditional rendering. The app config was updated with an APP_INITIALIZER to run session.init() on startup, and routes now declare required permissions via a withGuard() helper. Browser compatibility for @medic/cht-datasource required adding a process shim in polyfills.ts and webpack/karma fallbacks for Node built-ins (os, zlib, http, https). The sidebar was updated to use the auth directive to conditionally show nav links based on user permissions. M2 shipped with 150 tests and 100% function coverage.

Code review checklist

• UI/UX backwards compatible: Test it works for the new design (enabled by default). And test it works in the old design, enable can_view_old_navigation permission to see the old design. Test it has appropriate design for RTL languages.
• Readable: Concise, well named, follows the style guide
• Documented: Configuration and user documentation on cht-docs
• Tested: Unit and/or e2e where appropriate
• Internationalised: All user facing text
• Backwards compatible: Works with existing data and configuration or includes a migration. Any breaking changes documented in the release notes.
• AI disclosure: Design by humans, written by Claude based on the webapp application

License

The software is provided under AGPL-3.0. Contributions to this project are accepted under the same license.

[dianabarsan]

This looks like it just duplicates webapp services in the admin-tool. We would ideally not do this.
Can we experiment with just requiring the services from webapp directly?

For example, by adding this in admin-tool/tsconfig.json:

{
  "compilerOptions": {
    "paths": {
....< admin tool paths > ....
      "@mm-actions/*": ["../webapp/src/ts/actions/*"],
      "@mm-components/*": ["../webapp/src/ts/components/*"],
      "@mm-directives/*": ["../webapp/src/ts/directives/*"],
      "@mm-effects/*": ["../webapp/src/ts/effects/*"],
      "@mm-environments/*": ["../webapp/src/ts/environments/*"],
      "@mm-modals/*": ["../webapp/src/ts/modals/*"],
      "@mm-modules/*": ["../webapp/src/ts/modules/*"],
      "@mm-pipes/*": ["../webapp/src/ts/pipes/*"],
      "@mm-providers/*": ["../webapp/src/ts/providers/*"],
      "@mm-reducers/*": ["../webapp/src/ts/reducers/*"],
      "@mm-selectors/*": ["../webapp/src/ts/selectors/*"],
      "@mm-services/*": ["../webapp/src/ts/services/*"]
    }
  }
}

I had to make some other minor changes, like fixing polyfills, but the app builds with imported webapp services and directives.

unfortunately I can't push my changes to your branch, but I will push them to another branch: 71040b8

[javier-perez]

This looks like it just duplicates webapp services in the admin-tool. We would ideally not do this. Can we experiment with just requiring the services from webapp directly?

For example, by adding this in admin-tool/tsconfig.json:

{
  "compilerOptions": {
    "paths": {
....< admin tool paths > ....
      "@mm-actions/*": ["../webapp/src/ts/actions/*"],
      "@mm-components/*": ["../webapp/src/ts/components/*"],
      "@mm-directives/*": ["../webapp/src/ts/directives/*"],
      "@mm-effects/*": ["../webapp/src/ts/effects/*"],
      "@mm-environments/*": ["../webapp/src/ts/environments/*"],
      "@mm-modals/*": ["../webapp/src/ts/modals/*"],
      "@mm-modules/*": ["../webapp/src/ts/modules/*"],
      "@mm-pipes/*": ["../webapp/src/ts/pipes/*"],
      "@mm-providers/*": ["../webapp/src/ts/providers/*"],
      "@mm-reducers/*": ["../webapp/src/ts/reducers/*"],
      "@mm-selectors/*": ["../webapp/src/ts/selectors/*"],
      "@mm-services/*": ["../webapp/src/ts/services/*"]
    }
  }
}

I had to make some other minor changes, like fixing polyfills, but the app builds with imported webapp services and directives.

unfortunately I can't push my changes to your branch, but I will push them to another branch: 71040b8

@dianabarsan , we normally keep the application code separate from external dependencies, if we need to do so we install a shared library instead of referencing external code

1. what if we need to add new methods to the services that are only available for the admin tool? should we add it to the webapp?

2. We were wondering if instead you would prefer the admin-tool pages to live inside the webapp and we control access with an auth guard and roles?

Also, what if we need to add new methods to the services that are only available for the admin tool? should we add it to the webapp?

[dianabarsan]

@dianabarsan , we normally keep the application code separate from external dependencies, if we need to do so we install a shared library instead of referencing external code

1. what if we need to add new methods to the services that are only available for the admin tool? should we add it to the webapp?
2. We were wondering if instead you would prefer the admin-tool pages to live inside the webapp and we control access with an auth guard and roles?

Also, what if we need to add new methods to the services that are only available for the admin tool? should we add it to the webapp?

Thanks so much for the quick reply @javier-perez !

1. what if we need to add new methods to the services that are only available for the admin tool? should we add it to the webapp?

In this case, a new service that extends the webapp service should be added in the admin-tool.

2. We were wondering if instead you would prefer the admin-tool pages to live inside the webapp and we control access with an auth guard and roles?

This has the potential of creating huge merge conflicts once the two codebases progress. I know @jkuester suggested this, but I don't see any definitive advantages. If reusing webapp code is impossible somehow, that this would be preferred to duplicating code.

[javiertekdatum]

@dianabarsan , we normally keep the application code separate from external dependencies, if we need to do so we install a shared library instead of referencing external code

1. what if we need to add new methods to the services that are only available for the admin tool? should we add it to the webapp?
2. We were wondering if instead you would prefer the admin-tool pages to live inside the webapp and we control access with an auth guard and roles?

Also, what if we need to add new methods to the services that are only available for the admin tool? should we add it to the webapp?

Thanks so much for the quick reply @javier-perez !

1. what if we need to add new methods to the services that are only available for the admin tool? should we add it to the webapp?

In this case, a new service that extends the webapp service should be added in the admin-tool.

2. We were wondering if instead you would prefer the admin-tool pages to live inside the webapp and we control access with an auth guard and roles?

This has the potential of creating huge merge conflicts once the two codebases progress. I know @jkuester suggested this, but I don't see any definitive advantages. If reusing webapp code is impossible somehow, that this would be preferred to duplicating code.

Thank you @dianabarsan , my concern is having a hard dependency from one app to the other one, are you using this approach in other areas in the monorepo?

I think extending the services is good for now, ideally a shared library approach could resolved the requirements( DRY, rapid development, avoid circular depencencies, inadvertent coupling )

[dianabarsan]

Thanks for the suggestion @javiertekdatum

I believe we are completely fine with having hard dependency on Webapp, because it makes it easier to maintain this code and this has been the pattern of how these two apps co=existed.

[github-actions]

This PR is now marked "stale" after 30 days without activity. It will be closed automatically in 10 days unless you add a comment, push new changes or remove the "stale" label.