There has been a Sentry mechanism in NetServer for requests (well, the table is called ticket) for many years. Ticket rights are not calculated in the same way as for Sales entities: instead of an owner and group system and a data access matrix, tickets belong to categories (ej_category) and those categories have masters and members. Finally, users belong to roles that have specific functional rights, and those functional rights are used to grant types of access to tickets.
As with sale or appointment, access rights calculated for the root table will also lead to specific rights for derived tables (think appointment -> text). In the case of ticket, the ej_message table is the most interesting derived case.
Think of it as category replacing the owner/group distance concept in Sales; and the functional rights correspond to the different columns in the data access right matrix in admin, for Sales entities.
This TicketSentry in NetServer has, up to now, only worked with the type of access required for so-called List of tickets. In Service that means you get to see tickets in grids, but you can't change them and you can't see the messages belonging to those tickets. The List/View/Edit levels in Service don't have a direct counterpart in Sales entities, but it actually maps pretty well to table rights.
- List => ticket - Read, ej_message - None
- View => ticket - Read, ej_message - Read
- Edit => ticket - Full, ej_message - Full
This is the mapping we'll have from now on. But, until now it was "if you have List, you get FULL on everything; otherwise you get NONE on everything; and we don't care about View or Edit". That wasn't really good, and it will now change to the rights mapping as outlined above.
The rights calculations themselves do not change (no refactoring there!), so the various rules for members/masters/non-service-users etc are exactly the same as before. But they will now be enforced by the database layer in NetServer, and they will appear properly in the FieldRight dictionaries on TicketEntity carriers.
As an example, if you perform a query that takes its first field from the ej_message table, and you do not have the right to see the ej_message part of some record in the result set, then that record will disappear completely. Even if it is joined to things that you do have access to - the ej_message part of the record will decide the outcome, because it is the first field you refer to.
In other words - GetTicketMessageEntity(123) will start returning null if you don't have access to that message (calculated via its ticket, and you relationship to that). Likewise, a dot-syntax search where the first field is ej_message.
If you are getting hold of ej_message fields in some other way - say, as a dotsyntax query that starts with ticket - then the ticket may be there (if you have access), but fields belonging to ej_message may be blank (if you don't have access to that message).
I will just reiterate that the rules have not changed. But we are starting to enforce them, within NetServer, using the standard mechanisms and behaviours there. Hopefully you're not dependent on the old, laissez-faire behaviour... it's going away.