The following warnings occurred:
Warning [2] Undefined variable $unreadreports - Line: 26 - File: global.php(961) : eval()'d code PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/global.php(961) : eval()'d code 26 errorHandler->error
/global.php 961 eval
/showthread.php 28 require_once





× This forum is read only. As of July 23, 2019, the UserSpice forums have been closed. To receive support, please join our Discord by clicking here. Thank you!

  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Status Update 033
#1
I fixed the conflicts with Dan's push.
New SQL dump required.

UPDATES
users
admin.php - Removed {} around ifs and else for viewing purposes
views
_admin_stats.php - Indented "Statistics" h2
_admin_site_settings.php - Added tooltips
_admin_register_settings.php - Added tooltips, changed recommends to selects instead of inputs
_admin_login_settings.php - Changed hyperlink to docs to have a target attribute of blank to open in new tab/window
_admin_css_settings.php - Changed notes to tooltips
_join.php - Changed hyperlink to be nounderline for viewing purposes, "confirm" ID was being used twice, corrected this, made label wrap agreement_checkbox
_verify_resend.php - Removed jumbotron to match the other pages, added <br> after form
Removed all jumbotrons from the forgot_password and verify views
Added nounderline class to all links
admin_users.php
-Add User Form: added password generator for when force_pr=1, also makes the input readonly, includes the show password and reason why you can't edit
admin_user.php - made all checkboxes surrounded by non-bolded labels (adding class "normal") and cleaned up a bit
view_all_users.php, profile.php, edit_profile.php - few minor changes for appearance, changed ucfirst to echouser.
user_settings.php - added show password and reason why you can't edit username if applicable, moved () info to popover
admin_permission.php - added labels to all checkboxes to make the label clickable
  Reply
#2
My notes while going through the system:
Add SELF to "here" on token fail?

We should make the master account protected by default
  Reply
#3
So you're saying that master should not even do the token check?
  Reply
#4
Nope: we have the Protected Profile option in admin_user that protects a profile from edits, we should default this profile to have the value of 1 in the protected row (this is a DB edit).
  Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)