Bassa
Bassa copied to clipboard
scorelab
Add Decline Request Button
Added a Decline Request Button to the Requests Section in the Admin Tab, since right now there is no way of declining a request, only for accepting.
fixes #496
@agentmilindu @charithccmc Please review and shed some light on what might be going wrong? :slightly_smiling_face:
I think @malithsen and @vivonk would be the best people to help you on this
Sure, thanks! :slightly_smiling_face: @malithsen @vivonk PS- New additions to AdminCtrl.js and AdminService.js are at line 58 and line 35 respectively, my linting software produced spaces everywhere xD. I will fix that in the final styling commit :slightly_smiling_face:
Hey @vivonk I don't undestand what you meant by "previous cancel".. could you elaborate? Thanks for the help :slightly_smiling_face:
I mean there was already a cancel button where you have added new functionality. A button to cancel sign-up request. Wasn't that working?
I'm sorry Sir, but I don't think there was any old functionality for canceling the request. I merged the develop branch right before starting to code, so I don't think I have missed it. Could you recheck? There is no button for canceling in the Current Develop Branch Admin View either :neutral_face:
Ok my fault, I got mismatched with download request. Sorry. Yup, your works LGTM :smile:
I'm not sure deleting the requests from the db is a good option because it is an irreversible action. What if the admin mistakenly deletes the requests or for some use reason he/she later wants to revoke the signup rejection? This way we can also avoid someone spamming the system with signup requests.
How about we simply change the status of the request. Then have another tab to see rejected requests with the option to revoke?
Thoughts? @agentmilindu @vivonk
@malithsen I agree, but wouldn't that need a change to the entire database? One alternative I can suggest is to confirm the action through an alert to ensure that there is no misclick. If the user genuinely deletes it and then regrets it later, the client can re-register
@malithsen This would require least amount of messing around with other code for achieving that effect I think. Also, we would have to develop a separate section for "requests that were declined but can be restored" or basically a request recycle bin view, which is redundant in my opinion. :slightly_smiling_face:
@anurag deleting data from database if it's important is always a bad practice. Setting a flag makes more sense so that we don't loose any data. Altering table is not a big deal as we are currently developing Bassa not in release mode.
@anuragparida DB already has a blocked column. https://github.com/scorelab/Bassa/blob/master/Bassa.sql#L63
Take a look at /api/user/blocked https://github.com/scorelab/Bassa/wiki/URL-Endpoints
@malithsen @vivonk Oh I didn't see the blocked function. Should I change the code to refer to the blocked function directly?
@anuragparida Yeah simply changing the blocked status to 1 instead of deleting the user should work @vivonk
Okay sure, I'll implement that. But one doubt - Does the ng-repeat get the data only that is not blocked AND not approved? The first condition will be important to delete it from the table view
Not sure what you asking. Check the relavant backend endpoint and change query in that to not get irrelevant data.
@malithsen @vivonk @agentmilindu Done! Please check it out so that I can make final code style changes :smile: (PS: It works great, but the admin table has some more issues, will fix those in new PRs)