It is must to have negative numners.
Integer ID that is the recognized identity of the role. The ID must be a negative number, such as -10001. Role IDs must be unique for each application name. You can reuse the same role name-role ID pairs across a suite of applications.
3 of 3 people found this helpful
As Sidhdesh said, it's not that they are 'sometimes' negative, it's that they are ALWAYS negative. Now for the reason for roles, and why they are negative.
Back in the day before deployable applications, if you built an application and wanted to sell said application, importing that application on a non native server could be problematic because the permissions you assigned were static, meaning that if you created group 123, then all of your permissions were tied to group 123...if the server you were importing on had a DIFFERENT group 123 then people that had access to the other application suddenly had access to your application and there was no quick/easy way to fix this.....so, the concept of a deployable application and 'roles' were created. Deployable application gives you a container that everything inside belongs to and once everything belongs to that container, it gives you the ability to do things inside of it. In this case Roles. Roles are the concept of a permission within a deployable application. Due to the fact that everything is inside the container, nothing outside of it can affect it....so, if you have a role of 123, that role is specific to that container and you could have 15 applications on your server with role 123 and not have a conflict because the role is now tied to the container as well, you then map the role to a group and complete the link to the outside world thus allowing you to dynamically assign roles to groups via data driven mapping.
Now...we have roles...but, things like 'assignee group' need to be able to be accepted in the container as well without the possibility of being overwritten by the container permissions...so, it was decided that all roles must be negative numbers, and as such can't conflict with group permissions because those are all positive....
There you have it
To your point about multiple applications using the same Role IDs, I have a scheme I use when I build custom applications.
As you can see above I always use the same Role ID for the Admin role, same Role ID for the User Role, etc. This not only helps in troubleshooting because I start to recognize the Role ID's by memory but also if you export an app to update in a text editor and import as a new app everything just works and the permissions don't get stripped.