 Yeah, hi, welcome. Yeah, I'm Liz, I said, and the title was also already mentioned. Why do I want to talk with you about user events? Because it's very basic and it should be documented, right? That is certainly the case, but what I was wondering when I gave the idea for the proposal for this talk was to get actually a state of where we currently are. Because it has a little bit of background. We had an evolution of different event systems. Next cloud started from very early on with the hooks and went over the emitter approach and yeah, eventually, eventually arrived at this event departure with the typed events. So that has some, I mean, the old approaches were that had some issues, of course, so that we kind of changed it over time. I think the last was also due to an upgrade of the component from Symphony. But it also means that we had to, yeah, migrate the old events. Some may still be there and there are also still some code for backwards compatibility. But yeah, I wanted to see first whether all the user events actually are there and then there's another thing, because we have different user backends. So we have the local ones like the database, which is built in or the guest app, which is also local backend. You can also use this also from other places, like from LDAP or via SAML or OpenID. And summary mode backends can be also written to us. So there's a plugin to us right back to LDAP. So that makes it maybe a little bit more complicated. That's why, yeah, I looked into this as well and you see the cycle, it's not a cycle, but an arc really and yeah, we will now step forward through the event types here. So provisioning events we have them when the user is created and events typically come always in tuples. So you see there in the backends they before. So usually there's an event that is being emitted before something happens and then after the yeah, action is actually completed then there's an event like user created event that is also being emitted. Now you see already here that only a few of these backends I noted down behind this event because that's also what I figured out that some do not, some backends do not really emit this. And the background here is that that we have in the abstraction, there's a method to create a user, but this really has only effect on those that actually write it somewhere. So like in the database or the guest because they write on the local table and they write support. It's also, yeah, sends this upstream into the LW repository but others they perhaps do not listen to this. And then the second one, the user added one, there's a school specific. So it's added to a group. This has of course only relevance to, yeah, the group backends here and the other back end, this time also emits this. So maybe this is a little bit confusing and maybe this is also that we have to address at some point. The bottom one this is rather an edge case or user ID is accessed. So in this case there's not supposed to be a heavy user creation logic to be executed, only maybe some some logic that updates databases basically about the available user IDs or so. But in most cases you will not want to listen to this because it's really an edge case here. Then the activity events, it's mostly about, yeah, logging in, logging out. They're looking with cookie event. This is agnostic because, well, it's a cookie that's sent from the browser and no other back end is being pulled in here because it simply goes through via an extra logic. But the user looked in event. This is also again dependent a bit on the logic of the back end. It also, yeah, emits, it's properly and announces it and yeah, lockout is again agnostic because you also have some core functionality that needs to be executed to properly lock out the user. We see then an old type event here on the bottom. That's a generic event for the first look-in. I think that we can also migrate at some point into this user look-in event because one of the difference between the generic events is that it takes an opaque structure of some metadata, but this is, yeah, you need to kind of know the internals about this. So it's not exposed at some point. But the user look-in events are classes that are then sent around and they are in the OCP namespace and our PHP API and the UC, yeah, which data is being provided there, user ID, look-in name, et cetera. And then we could also at the bool value where there's the first look-in owner. The modification events are emitted for five types. It's when the display name changes, when the email address changes, the avatar of a user and the enabled state. And this is basically agnostic, but it goes via the user component from core. And this is a little bit tricky with those backends that actually then write or not write to remote because then you could run in a circle. So there are some tricks for the backends to do, to announce this properly, but yeah, if you just want to listen to it and react to it and it doesn't need to interest you too much. And there is a special event here when the password was changed. This is an also emitted. Eventually, when the user is being removed, it has events as well, obviously, that was much. These are agnostic also into some degree because they need to be then removed from, yeah, all the internal databases. But what we also can only do is to clean up the data that we next slot core files on the server know about. So that is about the central tables and the file system. But if your app has your own tables where you have user data with a user ID, then you need to clean up after them yourselves. So I think that's the most important part actually that yeah, when a user is deleted that also to data is cleaned up so that if possible future user does not get old data. Right. And yeah, eventually use cases. So it's all about housekeeping basically, maybe initializing some tasks, background tasks, perhaps also about integration when you try to reach out to other servers, male server, for the mail app, for instance, they do this. Yeah, these are the typical points where you want to listen to it to establish some tasks or remove them even. Yeah, sometimes takeaways, it's basically a petition of what I said before. And then eventually final slide is how you can register a listener that should be in the documentation. It's straightforward in your application PHP. You have the register method. You can just edit, you provide the class names from the event and from your listener and on the bottom here you see your your own implementation. So where the three dots are is your logic, basically what you want to do and yeah, this is a simple structure of an handler. Okay, yeah, thank you so much. Thank you. Thank you so much for your talk, please.