I think we should choose UID as an arbitrary string, and choose the
initial value of the string to be the login id. This also protects
automatically against anyone who tries to re-register an existing ID.
Does this mean we need to (slightly) refactor the interface for
UserProfile so that getId() returns a String? It should be the same
ID, methinks.
This is obvious. We can have a way better ACL editor...
Agreed. Thought I'd restate the assumption. :)
- For those who are curious (Terry?), we already change user names
in ACLs when the person's login/wiki name changes. So if Terry
decides to change his wiki name from TerryS to Terry, all ACLs that
contain "TerryS" will be chanced correctly.
This is obviously not good, because it will cause changes in all
pages, even though it was something else which changed.
Well, this is something we do today, already. And the reason we do it
is because otherwise if a user changed their wiki name, all of sudden
he or she would be locked out of all pages containing ACLs with their
name.
So, when a user changes his or her name, UserManager fires a
PROFILE_NAME_CHANGED event. PageManager detects this, iterates through
every page and checks the ACLs for any of the "old" names. If any are
found, the ACL is changed and replaced, and the page is saved.
This particular chunk of code would go away, clearly, if we stored IDs
rather than Principal names. However, the ACL implementations would
need to resolve the ID and return Principals (do the "translation"
between IDs and Principals).
(Just trying to think this through...)
