openlmis-ref-distro

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
OLMIS-4531: Updated version of openlmis-nginx to 5
OLMIS-4531: Updated version of openlmis-nginx to 5
I have changed the solution here, away from inheritance, to composition. Now each notifier (NearExpiryNotifier and StockoutNotifier) constructs the map and passes it (as well as the notification su...

I have changed the solution here, away from inheritance, to composition. Now each notifier (NearExpiryNotifier and StockoutNotifier) constructs the map and passes it (as well as the notification subject and content) to the StockCardNotifier, which is a separate component.

okay, my bad. We do this for email (only the important flag) but only because we check if a user email address has been verified and for important messages, this check can be skipped.

okay, my bad. We do this for email (only the important flag) but only because we check if a user email address has been verified and for important messages, this check can be skipped.

Shouldn't that be checked somewhere up the stream?

Shouldn't that be checked somewhere up the stream?

incorrect classes

incorrect classes

why we don't check allowNotify and important flags here?

why we don't check allowNotify and important flags here?

OLMIS-6040 Add SMS integration
OLMIS-6040 Add SMS integration
It means that the valuesMap contains information related to an individual message (each message can inform about the different program and so on). Notifiers, on the other hand, are responsible for ...

It means that the valuesMap contains information related to an individual message (each message can inform about the different program and so on). Notifiers, on the other hand, are responsible for sending multiple messages with different parameters, describing it with program property might be misleading as we don't have separate StockCardNotifier components for each program.

About the updating the map, let's imagine that we have the following situation. First call updates the map, then the second call updates the map, then the first call gets the map, the values are different than intended as the first call is using values of the second call. We don't have a Notifier that might cause this situation but someone might add such notifier and encounter this issue, which will be difficult to find.

Thus, passing the map as a parameter to the notifyStockEditors make it proof to such cases and makes the notifier decoupled from the specific messages.

Ah, makes sense. https://review.openlmis.org/static/ogdo0b/2static/images/wiki/icons/emoticons/smile.gif

Ah, makes sense.

Sorry, I'm not sure I understand. What do you mean by "property doesn't describe the whole component but each of the individual messages"? Also, how would a map update affect a previous get?

Sorry, I'm not sure I understand. What do you mean by "property doesn't describe the whole component but each of the individual messages"? Also, how would a map update affect a previous get?

This logic is getting all expiring lots on that date, and not past that date. So each lot should only get one notification, since they only have one expiry date.

This logic is getting all expiring lots on that date, and not past that date. So each lot should only get one notification, since they only have one expiry date.

If I understand correctly, this means that the daily notification will include information about all the products that are past the "expiration date - 6 months" threshold even if they passed that t...

If I understand correctly, this means that the daily notification will include information about all the products that are past the "expiration date - 6 months" threshold even if they passed that threshold a few days ago, is that correct? If so, I'm a little concerned that this notification might get annoying really fast for the users (e.x. getting the same notification for 6 months about a product that you can do nothing about).

I'm a little concerned about this one. I think this should be passed as a parameter to the notifyStockEditors method as this property doesn't describe the whole component but each of the individual...

I'm a little concerned about this one. I think this should be passed as a parameter to the notifyStockEditors method as this property doesn't describe the whole component but each of the individual messages. Also, it might introduce some issues related to racing if we ever specify a notifier that updates the map for a new message before calling the getValuesMap for the previous message.

OLMIS-3186 Add notification of near expiry
OLMIS-3186 Add notification of near expiry
OLMIS-5989: Updated info about building documentation
OLMIS-5989: Updated info about building documentation
I was added intentionally because it can be moved to another directory or updated and the link would be invalid but I can change it to master if you really want.

I was added intentionally because it can be moved to another directory or updated and the link would be invalid but I can change it to master if you really want.

Is it okay that we use commit id (oefdc844...) instead of master branch in the URL?

Is it okay that we use commit id (oefdc844...) instead of master branch in the URL?