You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When subskills are enabled, there are several usability issues that are a bit upsetting.
When trying to assign one subskill manually (from the users list in admin, click the skill assignment icon), something like /main/skills/assign.php?user=19491, there is no confirmation message about the skill being assigned (probably also happens with main skills)
When the subskill is assigned on /main/skills/assign.php?user=19491, the page refreshes and returns on the skill assignment page. However, it is very rare that one would one to assign several skills at a time. Add a button "Save and add more" that effectively returns to the fresh form. The normal "Save" button should redirect the admin to the user information page (/main/admin/user_information.php?user_id=19491)
When I click on one skill assigned (from the /main/admin/user_information.php?user_id=19491 page), I get to the /main/skills/issued_all.php?skill=95&user=19491 page which is... not beautiful (see screenshots). The badge should be centered, the left column should be wider to give space for the button (or the text on the button should be replaced by a download icon) and text elements should not be overlapping form elements in the form below
When I assign a skill manually, the skill_rel_user.assigned_by field does not have the ID of the person who assigned it. In fact, over more than 6000 skill_rel_user assigned manually, none has anything else than assigned_by = 0, so this field should be removed from the database to avoid confusion.
The text was updated successfully, but these errors were encountered:
When subskills are enabled, there are several usability issues that are a bit upsetting.
skill_rel_user.assigned_by
field does not have the ID of the person who assigned it. In fact, over more than 6000 skill_rel_user assigned manually, none has anything else than assigned_by = 0, so this field should be removed from the database to avoid confusion.The text was updated successfully, but these errors were encountered: