[#22 event system]#122
Conversation
|
@jesperpedersen Is this similar to what u have in mind? |
| public LocalDateTime createdAt; | ||
|
|
||
| @Column(nullable = false) | ||
| public Long entityId; |
There was a problem hiding this comment.
I thought that an event couldn't exist without being tied to an entity. If yes, what is the case of something like that?
There was a problem hiding this comment.
well, lets see once the event system is bigger - for now it is just a comment
|
@Hamza-Azeem Good start, lets iterate on it now |
|
@Hamza-Azeem Lets start with license headers |
|
@jesperpedersen Sorry for being inactive. I will work on it this weekend, and maybe try to complete it together. |
|
@Hamza-Azeem No problem, I think we will put this into the 0.3 release. Try and think about a support ticket goes through its "life phases" and which events it would generate. How can we see a ticket that has been alive for a long time ? How can we see how support people perform (we need the rating for that) ? But, how long did it take ? Was it time on the customer side or our side ? How many people were involved ? Was it a known issue ? It is an area that expands over time, we just need to make sure that the data model is in place to give us data points. The events will drive the reports forward |
|
@Hamza-Azeem Think about the roles too - How many tickets did company/person X created/update/resolve/closed ? F.ex Support/X has 50 tickets, and Support/Y has 10 tickets. But are Y's tickets harder and require QE/Engineering ? So, "External issue" is important... Think of it from the different angles - the main thing is that we need data to show us why the ticket wasn't closed fast |
|
Also, the Service Level Agreements - did tickets get into yellow or red ? (You probably need a scheduled service for this in order to check timestamps and fire an event) Did a company's entitlement expire ? How many open tickets do they have ? (Same thing here) |
|
@Hamza-Azeem I'm not saying to have to implement all at once - think about decide on the core, and then file issues for what is left |
|
Hello @jesperpedersen I also added a new column in the event entity to refers to the user who did the action triggering an event, while refactoring the old code a little. Please tell me if this is close to what you had in mind. I tried to get some requirements from
and decided to work on the life phases of the ticket for now, after I finish it, I can go for the next one. tell me what do you think |
|
@Hamza-Azeem Yes, I think that is a good idea - we can hide it behind a "Events" button on the ticket page. You are going in the right direction |
|
@Hamza-Azeem You are still ok on this, right ? |
|
@Hamza-Azeem Just focus on the events. We will create separate issues for all the new reports based on this |
|
@jesperpedersen yes I am still on it and I will keep you updated |
Hamza-Azeem
force-pushed
the
event_sys
branch
2 times, most recently
from
5c437c7 to
75727d8
Compare
|
Hello @jesperpedersen , I made some changes to the database and design of EventService. |
|
@Hamza-Azeem Yes, the correct direction. You need a license header for new files. You need documentation for each event type. And, a 74-events.md chapter that describes everything. I think the event types should have an explicit number ( |
…lity and add frontend timeline for all user types
|
@jesperpedersen Hello, I have added event_type entity that tracks name of event, and it's type whether it's a category or action and linked it to the event entity, which led to deletion of multiuple enums and refactoring event service to be more flexible and maintanble. I also added 74-events.md chapter and event with event_type to the 72.architecture.md PTAL |
| BIGINT user_id FK | ||
| INT event_type FK | ||
| } | ||
|
|
There was a problem hiding this comment.
We shouldn't have any FKs.
I don't think we need entity_type because we can get that from the event_type.
The event_type should be folded into the entity, so just BIGINT event_type. And, then EVENT_TYPE_BUG_XYZ, EVENT_TYPE_QUESTION_XYZ, ...
| INT id PK | ||
| STRING name | ||
| STRING TYPE | ||
| } |
There was a problem hiding this comment.
So remove EVENT_TYPE
| | `CLOSED` | The ticket was closed | | ||
| | `EXPIRED` | The ticket expired without resolution | | ||
| | `UNKNOWN` | The action could not be determined | | ||
| | `CREATED` | _(Reserved for future use)_ | |
There was a problem hiding this comment.
Just explain the constants here
| | `CREATED` | _(Reserved for future use)_ | | ||
| | `UPDATED` | _(Reserved for future use)_ | | ||
| | `DELETED` | _(Reserved for future use)_ | | ||
|
|
There was a problem hiding this comment.
We don't need to reserve -- we have all the public static longs
|
@Hamza-Azeem How are you doing on this ? |
2 participants
Add event entity and backend service with types supporting changes in tickets by support, user and tam.