Wes Brown

Are there other location types that we may need to consider? If so, would we want this description to be more general?

Are there other location types that we may need to consider? If so, would we want this description to be more general?

Geographic

Geographic

Is it likely that an ERP system might be the source of truth for this kind of data, rather than OLMIS? I am thinking of a country that wants to use OpenLMIS primarily for the requisition process bu...

Is it likely that an ERP system might be the source of truth for this kind of data, rather than OLMIS? I am thinking of a country that wants to use OpenLMIS primarily for the requisition process but leverage an existing ERP system for inventory-related processes.

Would OpenLMIS be the source of truth for cce or would a monitoring system like NexLeaf?

Would OpenLMIS be the source of truth for cce or would a monitoring system like NexLeaf?

Is bearer tokens the only method that we want to support?

Is bearer tokens the only method that we want to support?

Also, if you add something about smart endpoints/dump pipes, including some detail about what that means in practice would be helpful as well.

Also, if you add something about smart endpoints/dump pipes, including some detail about what that means in practice would be helpful as well.

Given that this was due 9 weeks ago and the associated issue is already marked as Done, I'm going to close this review.

Given that this was due 9 weeks ago and the associated issue is already marked as Done, I'm going to close this review.

Thanks for the detailed explanation! I can understand why you chose composition over inheritance but wonder if it would be helpful to actually use both; define the ExtraDataEntity as you already do...

Thanks for the detailed explanation! I can understand why you chose composition over inheritance but wonder if it would be helpful to actually use both; define the ExtraDataEntity as you already do and then also define the BaseExtraDataEntity (or whatever) with the field and import/export logic already defined for the majority of the classes to use (except Orderable).

I am just looking for ways to reduce the duplication of the field and import/export logic in each domain class and this seems to provide that. I'm open to thoughts about whether this is worth the effort though.

Is there a reason why this isn't being designed as a sub-class of `BaseEntity`? It seems more natural (from an Object Oriented design perspective) for domain objects to be inherit from a base class...

Is there a reason why this isn't being designed as a sub-class of `BaseEntity`? It seems more natural (from an Object Oriented design perspective) for domain objects to be inherit from a base class which contains the appropriate fields. In this case, I would expect that the concrete domain classes that include extra data would simply use this class as the base class.

This extraData field is continuing to get used but the logic (limited as it is) is being copied by each domain/dto object. I think that a BaseEntity and BaseDto subclass should be created with the ...

This extraData field is continuing to get used but the logic (limited as it is) is being copied by each domain/dto object. I think that a BaseEntity and BaseDto subclass should be created with the extraData field and associated logic (import, export, etc) that domain/dto objects could inherit from instead of BaseEntity/BaseDto.

The properties defined in this interface don't seem to have anything specific to do with a FHIR resource and so the name of this interface seems misleading. This interface just represents an extens...

The properties defined in this interface don't seem to have anything specific to do with a FHIR resource and so the name of this interface seems misleading. This interface just represents an extensible (extendable?) entity, which is required for a FHIR resource but not specific to one.

This `extraData` design is in use in a few domain classes with identical annotations. Can this be abstracted into a base class that domain objects can inherit and not have to repeat the definition ...

This `extraData` design is in use in a few domain classes with identical annotations. Can this be abstracted into a base class that domain objects can inherit and not have to repeat the definition each time? Likewise, the importer and exporter interfaces could be extended to include this field.

Are you expecting to reuse this method? It doesn't look like you are currently using it anywhere other than the synchronize method and I'm not sure there is value in moving this small code block to...

Are you expecting to reuse this method? It doesn't look like you are currently using it anywhere other than the synchronize method and I'm not sure there is value in moving this small code block to its own method.

I thought that we were going to look at sharing some of the common settings/configurations in the jenkins files. It seems unfortunate to have to update this for every service when the setting is th...

I thought that we were going to look at sharing some of the common settings/configurations in the jenkins files. It seems unfortunate to have to update this for every service when the setting is the same across them all.

Given this, I'm not going to dig too far into this.

Given this, I'm not going to dig too far into this.