Hi i'm actually working on a report system for my social network, i want to achieve something like : if a user is reported 5 times it will update a field on the user table to deactivate the user.
So if 5 row of reports is created i want to update the "activated" field
The thing is i'm working with GraphQL and Vue for the first time, my backend is in Symfony with ApiPlatform.
Should i try to query all the reports with the userId who is reported to count if there is 5 row when a user is reported and then mutate the user object to deactivate it or can i achieve this more easily on the backend side ?
So anything of importance should be done on the backend. The frontend is easily hacked and while it's good to stop normal (good) users from seeing something they're not supposed to, it's not a blocker to anyone who has even rudimentary web coding ability.
Seeing as you're talking about someone being reported, I'd recommend doing it on the backend and then make sure the frontend reflects that gracefully.
Hum it seems that the answer is that i need a reportListener and i need to listen the postPersist event, then inside this function i can check how many report there is for a user using the ReportRepository->findBy function, then i can count the row of the array return by the function and if the count is > 5 then i edit my user, persist and flush.
Related
I have set up two referral credit rules.
All acting users get 7 default credits every time they trigger the event mq_app_open
Referred acting users get 10 default credits every time they trigger the event mq_app_open
mq_app_open is a custom event that I am recording on app open.
I can see that rule 1 is getting applied but can never get rule 2 to be applied.
What actually does "Referred acting users" actually mean?
I think the issue probably relates to the fact that when I open the app from a (universal) deeplink I see two events
open
mq_app_open
For each of Session Referring Branch Link ID, Session Referring Click ID and Session Referring Link URL are all null.
Oddly, when I let the app go into the background and then the foreground again I see the following events
open
referred session
For these two events Session Referring Branch Link ID, Session Referring Click ID have values but Session Referring Link URL is null.
I am not sure why any of these values are null when it would seem they should all reference back to the link url that was clicked on.
Alex from Branch.io here:
Referred acting users is a rather confusing way to say 'users who take action and open the app after clicking on a Branch link'. We should probably adjust our terminology to make this a bit clearer. For most purposes, you can think of this as Referred users.
I am actually not certain why rule 1 is working but rule 2 is not. Possibly there is some conflict with having two rules applying to the same user from the same event — you could try refactoring the rules so that Referring users get 7 points and Referred users get 17.
Those session parameters should be coming back with values, assuming a link was clicked. We probably need to do a bit more debugging to see what's going on — would you mind submitting a ticket to the Branch integrations team so that we can dig into the code and the backend config of your specific app?
I am using HP Project and Portfolio Management(PPM) tool and I am adding a custom field in my request type which has date as value. Now my requirement is to send the email notifications to the users once the date mentioned in the custom field crosses the system date.
I had tried to set the notification for field level from Notification tab but not getting the custom fields in the list. All the fields, which is available, are pre-configured fields.
So, can anyone suggest me how to implement this requirement? And also where the changes need to be done If any required to implement this?
Please answer in detail and also reply soon.
Thanks in advance!!
PPM notifications can be configured on pre-defined events, like a certain transition, or timeout etc...
One possible solution for this scenario is to have timeouts on your decision step. Time out goes to an execution step, which checks for the date condition. If the condition is met it fires the notification. Else it just returns to the original decision step.
The downside of this work around is that there will be transaction details added once daily. Also the last update date of the request keeps updating daily, which is not ideal if you want to track what was the last time an end user update the request.
It is a workaround cause of the restrictions around notification events.
And if you have a large workflow, I would not recommend this work around.
I have a weird problem - I'm working on a portfolio site built in Expression Engine that has a number of clients who all obviously need to log in to access their portfolio.
I've been asked to see if there's a way that a user could login once, and then somehow, from then on, be able to bypass the login screen when they return to the site - the main client is keen on a unique URL, and I can't see how this would be done. I'm a bit of a novice with Expression Engine, so if anyone has any tips I'd love to hear them!
Cheers in advance.
You would need to build an add-on with a module and extension to do this. Many steps involved, but doable.
create a new table to hold some sort of unique ID, a member_id, and probably an expiry date
insert a new action when your module is installed, and have a corresponding method which will handle logins in your module
use the member_member_login_start extension hook to insert a new row into this table, and then to generate an email which is sent to the member's email address which contains an action URL built using the unique value you just inserted (e.g., http:/mysite.com/?ACT=XX&unique_id=XXXXXX)
Something like that.
I'm wondering to know if I can have a event or some way to know when the user deletes my App, so I can delete him from my Database. Is it possible?
First; Just because the user deleted the app on one device doesn't mean they don't have it installed on others - or won't install it on others.
To your question; Apple doesn't give you a way to do this. Perhaps you could use some sort of "expiration" window - e.g.: if they don't start the app within 90 days, expire the records from your database?
The short answer would be NO, since the user can delete your app without even starting it.
What you could do is send a message to your server every time the user starts the app and get an approximation of how active the user is. Very little activity -> delete the user from DB.
Nope, chuck testa. Otherwise people could abuse this feature with alerts and crap like that!
I'd been looking at using the Rally API to create an app to do some simple auto-ranking stories based on specific criteria (at the request of / to help out a couple of our Product Owners) in a drag&drop workspace.
I did this by adjusting the "Rank" properties of the sequence of stories (I made sure to keep the rank values within the same overall min / max range as prior to the auto-reorder). I made a call to the API to update each story's rank individually (in quick succession).
Testing the app, I found that sometimes after running the auto-ranking app, some screens (such as the kanban board) would tell me that "drag and drop re-ranking is disabled for manual rank workspaces" (and the kanban would no longer let me drag & drop, although other screens such as the backlog would still let me drag & drop, and the workspace settings were still set to drag & drop). Deleting the stories, or reordering them on the backlog screen would return things back to normal.
After trying a few ideas to solve this, I figured perhaps if I was updating the Rank on a number of stories in quick succession, the back-end might be getting confused with these (potentially several / concurrent) requests. Introducing a delay between each story's API call has seemed to avoid the problem, and to speed things up, I now update a story's rank in the API only after the previous story's rank update has invoked the "updateComplete" function.
Do the assumptions in the last paragraph above make sense based on the backend ranking? Is there any Javascript API call to update multiple stories at once? (Otherwise I'm quite happy with the solution of only calling the API "update rank" after the prior API "rank update" call has returned ok).
That sounds like you discovered a possible issue with the backend ranking. The warning you were getting stems from the board trying to figure out which type of workspace you are in (manual or dnd rank). Since that setting is not currently available via WSAPI the board tries to figure it out based on its data and sometimes gets it wrong.
Currently there is no fully supported/documented way to adjust the ranks of items via WSAPI. The Card Board component in the App SDK uses special rankAbove and rankBelow query string parameters during update calls (which you can see in Firebug or the Chrome dev tools).
How are you currently setting the Rank values?