Add ACP module mode to refer badges to users

[ghost]

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.

ghost commented 6 years ago

This will probably not make it into v1.

pchote commented 6 years ago

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 openra_badge_availablility table (with columns for badge_id, user_id) and exposed in the "Default badges" UCP panel (which would be renamed to "Select badges") by modifying https://github.com/matjaeck/OpenRAUserAccounts/blob/ef708d213cd7ddd13d57c6294c91a7ee4f5aa267/ucp/useraccounts_module.php#L402-L406

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 badge_availability table and UCP parts of this before we deploy the first version? This would save us from having to do a messy database migration in the future with real user data.

ghost commented 6 years ago

I'm working on something and will report later.

ghost commented 6 years ago

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.

ghost commented 6 years ago

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.

pchote commented 6 years ago

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 openra_badges and my proposed openra_badge_availability tables address the first question for default and admin-granted badges respectively, and then the openra_user_badges table addresses the second question.

ghost commented 6 years ago

Now implemented as you have suggested. When you add users to a non-default badge via the ACP, it writes the badge_id and the user_ id for entered usernames in the openra_badge_availability sql-table. On the UCP side, available badges will be shown in a Select Badges tab (I had to split the queries for default / available badges and use UNION because the query you suggested and everything I tried would only show default badges if there exists an available badge, OR didn't work the way we need it).

Renamed the other tab to Order badges. The only thing missing for this feature is the visual table that shows for which users a selected badge is already available.

Don't forget to disable & delete when you install the updated extension, the renamed module can cause problems else.

ghost commented 6 years ago

Have implemented the table that shows availabilities for the selected badge. Adding/removing will add log entries to the admin log.

ghost commented 6 years ago

There are no pending changes/fixes for this feature so this can be closed.

• © Githubissues.
• Githubissues is a development platform for aggregating issues.

[ghost]

This will probably not make it into v1.

[pchote]

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 openra_badge_availablility table (with columns for badge_id, user_id) and exposed in the "Default badges" UCP panel (which would be renamed to "Select badges") by modifying https://github.com/matjaeck/OpenRAUserAccounts/blob/ef708d213cd7ddd13d57c6294c91a7ee4f5aa267/ucp/useraccounts_module.php#L402-L406

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 badge_availability table and UCP parts of this before we deploy the first version? This would save us from having to do a messy database migration in the future with real user data.

[ghost]

I'm working on something and will report later.

[ghost]

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.

[ghost]

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.

[pchote]

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 openra_badges and my proposed openra_badge_availability tables address the first question for default and admin-granted badges respectively, and then the openra_user_badges table addresses the second question.

[ghost]

Now implemented as you have suggested. When you add users to a non-default badge via the ACP, it writes the badge_id and the user_ id for entered usernames in the openra_badge_availability sql-table. On the UCP side, available badges will be shown in a Select Badges tab (I had to split the queries for default / available badges and use UNION because the query you suggested and everything I tried would only show default badges if there exists an available badge, OR didn't work the way we need it).

Renamed the other tab to Order badges. The only thing missing for this feature is the visual table that shows for which users a selected badge is already available.

Don't forget to disable & delete when you install the updated extension, the renamed module can cause problems else.

[ghost]

Have implemented the table that shows availabilities for the selected badge. Adding/removing will add log entries to the admin log.

[ghost]

There are no pending changes/fixes for this feature so this can be closed.