-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ACP module mode to refer badges to users #19
Comments
This will probably not make it into v1. |
IMO the best way to implement this is to duplicate the user display/addition/removal UI from the group members management panel at the bottom of the badge management page (just below the default badge option). This then keeps everything related to each badge in the same place. Users added / removed through this UI are written to a new to something like $sql = "SELECT b.badge_id, b.badge_label, b.badge_icon_24, bt.badge_type_name
FROM $badge_table AS b, $badge_type_table AS bt, $badge_availability_table AS ba
WHERE (b.badge_default = TRUE OR (ba.badge_id = b.badge_id AND ba.user_id = ' . $this->user->data['user_id'] . '))
AND b.badge_type_id = bt.badge_type_id
ORDER BY bt.badge_type_name"; The "Profile badges" UCP panel could then be renamed to "Badge order" for consistency. This would then also resolve #29. Do you think you could try implementing at least the |
I'm working on something and will report later. |
It was easier to implement the interface for associating badges to users as a new "action". Adding/editing badges is another action. When you set up the options for the badge, i.e. click "add" or "edit", it uses the same action code but in the case of "add" the badge is not in the db yet. This is why it is easier to wait until it is in the db and then go on with another action to add user badges. The icon will disappear for default badges. Currently it will add the badge_id of the selected badge to the user_badges table for the usernames entered in the textarea. I see that we somehow need to distinguish between the badges in the UCP "Select badges" tab where all available badges should be displayed and the "Badge order" tab, where only the selected should be displayed. An alternative to your suggestion of adding another table would be to have a 'badge_selected' column in the user_badges table and filter for badge_selected = TRUE in the visual table of the "Badge order" tab. I would prefer this to keep all user-related badge information in one SQL table. |
The downside of my suggestion is that the user_badges table then contains badge_ids that are not selected by the user. Also, default badges would probably still be deleted from there while those "special" badges stay. It might be better to follow your approach. This can be easily changed in the parts I have written so far and I will change this now and do it like you suggested. Oh and there will be another visual table above the ACP "Username" input that lists the users that are associated with the selected badge. |
Yes, that is indeed the problem. We want to separate the question of "does a user have access to badge type X" from "What badges should be shown for user Y and what order should these be shown". The |
Now implemented as you have suggested. When you add users to a non-default badge via the ACP, it writes the Renamed the other tab to Don't forget to disable & delete when you install the updated extension, the renamed module can cause problems else. |
There are no pending changes/fixes for this feature so this can be closed. |
While this can be done manually in the database and there won't be too many user badges, it makes sense to add an interface for it that supplements the implemented module which has a mode that already handles inserting badge data. This could replicate phpBB's functions in ACP -> Manage users -> -> Add feedback / Attachments or in MCP -> User notes -> Add feedback.
The text was updated successfully, but these errors were encountered: