From a recent Slack message, both the auth and requisition service defining a User entity with overlapping fields on the same table. When defined together (during work in to create reference distribution), one of the services wouldn't start because of the conflict. Separating the reference data concerns from authorization concerns is an interesting idea, but we at least need to remove the technical conflict.
The classes are org.openlmis.hierarchyandsupervision.domain.User (requisition service) and org.openlmis.auth.domain.User (auth service)
Assigning to Sebastian for triage as it seems AYIC is working on the auth service.
From a recent Slack message, both the auth and requisition service defining a User entity with overlapping fields on the same table. When defined together (during work in to create reference distribution), one of the services wouldn't start because of the conflict. Separating the reference data concerns from authorization concerns is an interesting idea, but we at least need to remove the technical conflict.
The classes are org.openlmis.hierarchyandsupervision.domain.User (requisition service) and org.openlmis.auth.domain.User (auth service)
Assigning to Sebastian for triage as it seems AYIC is working on the auth service.