1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-11 17:32:41 +01:00
Commit graph

7 commits

Author SHA1 Message Date
epriestley
e0e339f16c Modernize People application
Summary: Move to application navigation, make it possible to get to /logs/ from the navigation.

Test Plan: Hit all interfaces, verified email.

Reviewers: btrahan, vrana

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1569, T631

Differential Revision: https://secure.phabricator.com/D3261
2012-08-13 15:27:21 -07:00
Ricky Elrod
729f246f92 Add a checkbox to allow administrators to re-send the welcome email to users.
Summary:
See title - This simply adds a checkbox to the "Edit User" page in the
admin view, to allow an administrator to re-send the "Welcome to Phabricator"
email.

Test Plan:
Sent myself another welcome email using the checkbox.
Created a new user using the admin panel, to make sure emails still get
sent for new users.

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Maniphest Tasks: T1524

Differential Revision: https://secure.phabricator.com/D3081
2012-07-26 17:41:14 -04:00
epriestley
957f9e2ec5 Add an administrative tool for deleting users
Summary:
Allow administrators to delete accounts if they jump through enough hoops.

Also remove bogus caption about usernames being uneditable since we let admins edit those too now.

Test Plan: Tried to delete myself. Deleted a non-myself user.

Reviewers: csilvers, vrana

Reviewed By: csilvers

CC: aran

Maniphest Tasks: T1184

Differential Revision: https://secure.phabricator.com/D2767
2012-06-15 17:02:20 -07:00
epriestley
0e1bbbd489 Allow administrators to change usernames
Summary:
Give them a big essay about how it's dangerous, but allow them to do it formally.

Because the username is part of the password salt, users must change their passwords after a username change.

Make password reset links work for already-logged-in-users since there's no reason not to (if you have a reset link, you can log out and use it) and it's much less confusing if you get this email and are already logged in.

Depends on: D2651

Test Plan: Changed a user's username to all kinds of crazy things. Clicked reset links in email. Tried to make invalid/nonsense name changes.

Reviewers: btrahan, vrana

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1303

Differential Revision: https://secure.phabricator.com/D2657
2012-06-06 07:09:56 -07:00
epriestley
0a7b4591ef Allow usernames to include ".", "-" and "_"
Summary:
See T1303, which presents a reasonable case for inclusion of these characters in valid usernames.

Also, unify username validity handling.

Test Plan: Created a new user with a valid name. Tried to create a new user with an invalid name. Ran unit tests.

Reviewers: btrahan, vrana

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1303

Differential Revision: https://secure.phabricator.com/D2651
2012-06-06 07:09:05 -07:00
epriestley
489303a057 Fix transaction handling in PhabricatorUserEditor->createNewUser()
Summary:
See https://github.com/facebook/phabricator/issues/117

  - The $user save can hit a duplicate key exception like the email, but we don't handle it correctly.
  - When the $user saves but the $email does not, the $user is left with a (rolled-back, invalid) ID. This makes the UI glitch out a bit. Wipe the ID if we abort the transaction.
  - We show the "Required" star marker even if the email is filled in.

The ID issue is sort of a general problem, but I think it's fairly rare: you must be doing inserts on related objects and the caller must catch the transaction failure and attempt to handle it in some way.

I can think of three approaches:

  - Manually "roll back" the objects inside the transaction, as here. Seems OK if this really is a rare problem.
  - Automatically roll back the 'id' and 'phid' columns (if they exist). Seems reasonable but maybe more complicated than necessary. Won't get every case right. For instance, if we inserted a third object here and that failed, $email would still have the userPHID set.
  - Automatically roll back the entire object. We can do this by cloning all the writable fields. Seems like it might be way too magical, but maybe the right solution? Might have weird bugs with nonwritable fields and other random stuff.

We can trigger the rollback by storing objects we updated on the transaction, and either throwing them away or rolling them back on saveTransaction() / killTransaction().

These fancier approaches all seem to have some tradeoffs though, and I don't think we need to pick one yet, since this has only caused problems in one case.

Test Plan: Tried to create a new user (via People -> Create New User) with a duplicate username. Got a proper UI message with no exception and no UI glitchiness.

Reviewers: btrahan, vrana, hgrimberg, hgrimberg01

Reviewed By: hgrimberg01

CC: aran

Differential Revision: https://secure.phabricator.com/D2650
2012-06-05 06:46:01 -07:00
vrana
6cc196a2e5 Move files in Phabricator one level up
Summary:
- `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`.
- [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php`
- Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`.

NOTE: `arc diff` timed out so I'm pushing it without review.

Test Plan:
/D1234
Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general.

Auditors: epriestley

Maniphest Tasks: T1103
2012-06-01 12:32:44 -07:00
Renamed from src/applications/people/controller/edit/PhabricatorPeopleEditController.php (Browse further)