Dima_hat
Dima_hat
PostsComments
NNovu
Created by Dima_hat on 9/24/2024 in #💬│support
Workflow settings are not respected
I just noticed it yesterday - not sure when it happened, do not open settings that often and also wasn't paying too much attention to actual workflows mentioned there
13 replies
NNovu
Created by Dima_hat on 9/24/2024 in #💬│support
Workflow settings are not respected
Not the one - checked at least 5
13 replies
NNovu
Created by Dima_hat on 9/24/2024 in #💬│support
Workflow settings are not respected
I cannot check for all subscribers, but all that I have tested for now - see these settings. Both in development and production environment
13 replies
NNovu
Created by Dima_hat on 9/24/2024 in #💬│support
Workflow settings are not respected
If you mean Trigger identifier - it's test-message We have another test-i18n. Maybe it's name will be slightly more unique 🙂
13 replies
NNovu
Created by Dima_hat on 8/12/2024 in #💬│support
Promoting changes results in 500 error
As an additional info to this one - even one single change in InApp step created two changes in the history, so probably not related to changing multiple steps and promoting them all at once
3 replies
NNovu
Created by Dima_hat on 7/15/2024 in #💬│support
Digest do not provide actor data of an event sender
Yes, but the question - for digest would the actor be the same for all digest messages (the first actor who "created"/"triggered" the digest) or will it be actually the proper actor at each event if they would be separate. As there may be different people whi triggered the notification
14 replies
NNovu
Created by Dima_hat on 7/15/2024 in #💬│support
Digest do not provide actor data of an event sender
Sorry, haven't posted my reply here Solved it at that moment by just adding senderName to the payload and calling it a day Not sure what actor would be exactly used if we are going one level above - is it an actor that started digest or it's literally an actor who sent the notification If it will be the actor who sent a notification - it would be a perfect solution in this case, but "there is nothing more permanent than a temporary solution" that we already have in code 🙂 Maybe with next such issue will try approach with {{../actor.firstName}} and let you know afterwards how it went
14 replies
NNovu
Created by Dima_hat on 8/5/2024 in #💬│support
Using nested translation variables
One last question - it's impossible to pass a variable on which string from the translations file should be taken So having in editor: 
{{i18n "login.{{textToTake}}"}} 
{{i18n "login.{{textToTake}}"}}
doesn't work 😦 . Probably I'm getting the templating wrong or it's really not possible It will also provide possibility to decide what message should be taken by the payload, but without exploiting contexts
16 replies
NNovu
Created by Dima_hat on 8/5/2024 in #💬│support
Using nested translation variables
Thanks for the docs, will definitely have a look
16 replies
NNovu
Created by Dima_hat on 8/5/2024 in #💬│support
Using nested translation variables
Thanks! That's already helps a lot! Just trying to understand regarding possibilities Is it possible to have two different separate contexts? That in translation file we have 
{
  "status": "status",
  "status_busy": "busy",
  "status_progress": "progress",
  "welcome_formal": "Hi {{name}}, your status is: $t(login.status)",
  "welcome_informal": "Welcome {{name}}, your status is: $t(login.status)"
}
{
  "status": "status",
  "status_busy": "busy",
  "status_progress": "progress",
  "welcome_formal": "Hi {{name}}, your status is: $t(login.status)",
  "welcome_informal": "Welcome {{name}}, your status is: $t(login.status)"
}
And to somehow pack both different busy | progress and formal | informal contexts together Looks like it's impossible with such approach 
{{i18n "login.welcome" name="Gali" context=payloadStatus}} 
{{i18n "login.welcome" name="Gali" context=payloadStatus}}
And there can be only one context?
16 replies
NNovu
Created by Dima_hat on 8/5/2024 in #💬│support
Using nested translation variables
Hey hey, Thanks for reply. Unfortunately not exactly. For statuses it's also several different translated strings that we want to store in novu, so we need to provide which status exactly should be taken from the translation file 
{
   "status1": "Todo",
   "status2": "In progress",
   "inboxChange": "{{firstName}} has changed the status to $t(conversations.status1 || status2)."
}
{
   "status1": "Todo",
   "status2": "In progress",
   "inboxChange": "{{firstName}} has changed the status to $t(conversations.status1 || status2)."
}
And which one of two statuses to take - we need to provide also as payload variable Is that possible to perform somehow?
16 replies
NNovu
Created by Dima_hat on 3/28/2024 in #💬│support
Is there some cache of the actors data?
Workflow was created and existed long before the creation of the subscribers. I think the steps in our case where 1. Creating workflow and use it for some period of time (not sure if such usage can affect anything) 2. Creating new subscriber using identify. 3. Triggering workflow with this subscriber as an actor. 4. Updating subscriber information using bulk create. 5. Triggering workflow again. And here was still info from the second step and not from the forth. 6. Updating user info using identify seems to fix the issue. Unfortunately right now cannot check if the issue still exists, but I believe these were the steps that we have used
14 replies
NNovu
Created by Dima_hat on 3/28/2024 in #💬│support
Is there some cache of the actors data?
Some of messaged where sent after changing of the subscribers data, when I saw thriugh the UI that data was changed already, but in messages it still arrived empty. Only after calling subscribers.identify - it started working properly. Can it be that there is some difference in behavior of subscribers.bulk and subscribers.identify methods?
14 replies
NNovu
Created by Dima_hat on 3/28/2024 in #💬│support
Is there some cache of the actors data?
But after using bulkUpdate (so when issue was happening) - the web UI showed correct data (not empty strings for firstName and lastName)
14 replies
NNovu
Created by Dima_hat on 3/28/2024 in #💬│support
Is there some cache of the actors data?
After updating information by subscribers.identify - the issue is gone and information of the actor is properly displayed
14 replies
NNovu
Created by Dima_hat on 3/12/2024 in #💬│support
Angular component is showing only 10 notifications
Yes, we downgraded to 0.22 so using it right now 🙂
10 replies
NNovu
Created by Dima_hat on 3/12/2024 in #💬│support
Angular component is showing only 10 notifications
Hey hey are there any news on this one? Maybe some more information is required?
10 replies
NNovu
Created by Dima_hat on 3/12/2024 in #💬│support
Angular component is showing only 10 notifications
Was playing a little bit with the example that you posted. Thanks for that and yes can confirm that it works. But after upgrade of a @novu/notification-center-angular package to 0.23.1 (the version that we are using) can see only the first request and no later requests The last version where everything is working is 0.22.0 and both 0.23.0 and 0.23.1 seems to fail The latest 0.24 version seems also to be broken
10 replies
NNovu
Created by Dima_hat on 3/12/2024 in #💬│support
Angular component is showing only 10 notifications
Literally nothing. There is no second request triggered. I am viewing only 10 notifications and that's it
10 replies
NNovu
Created by Dima_hat on 3/6/2024 in #💬│support
Subscribers with same ids
Just plain node.js package to create subscribers and notifications
6 replies