Looking through the AdminMgr methods, I'd propose the following methods be
added to the interface (I'll turn it into a Jira issue when we're done with the
discussion):
User addUser(User user, EntryCallback<User> callback);
void deleteUser(User user, EntryCallback<User> callback);
User updateUser(User user, EntryCallback<User> callback);
The User class would need one additional method - this would be very useful
just to further inspect retrieved objects but is also required within an
EntryCallback:
Entry getEntry();
The EntryCallback interface would look something like:
@FunctionalInterface
public interface EntryCallback<T extends FortressEntity> {
Entry transform(T fortressEntity) throws FortressOperationAbortedException;
}
I originally excluded the use of a callback on the delete operation but having
a callback allows the operation to be aborted (Based on values in the entry?
Or when referential integrity with other entries might be violated?). As
noted, having access to the underlying groupOfNames entry would also be useful.
I'd argue that you would commonly expect User and Group to be more complex
than Fortress' view of them since it's common to write schema extensions for
them. I'd also argue that Roles, Permissions, etc are specifically Fortress
implementations of the RBAC specification and they should remain black boxes to
other LDAP operations.
What do you think?
Steve
"And so I pretend not to hear her. And go out to get an envelope because I'm
going to have a hell of a good time in the process of buying one envelope. I
meet a lot of people. And, see some great looking babes. And a fire engine goes
by. And I give them the thumbs up. And, and ask a woman what kind of dog that
is. And, and I don't know. The moral of the story is, is we're here on Earth to
fart around. And, of course, the computers will do us out of that. And, what
the computer people don't realize, or they don't care, is we're dancing
animals. You know, we love to move around. And, we're not supposed to dance at
all anymore."
- Kurt Vonnegut
----- Original Message -----
From: "Shawn McKinney" <[email protected]>
To: [email protected]
Sent: Thursday, October 20, 2016 9:00:51 AM
Subject: Re: Custom object classes and attributes
> On Oct 20, 2016, at 1:29 AM, Patrick Brunmayr <[email protected]> wrote:
>
> - Please consider the possibility also for Groups or Roles
I get groups but why roles? Can you provide a specific use case of what those
attributes would be and why?
>
> On Oct 20, 2016, at 1:29 AM, Patrick Brunmayr <[email protected]> wrote:
>
> - It should also be possible to set/get these extra data through the
> REST interface
Agreed. Everything that can be done via api call must also be doable via rest.