Licensing viewer and participant

Hi there, I want to create a ressource with limited access right i.e. with a viewer like license type (read only access to project). The problem is that whenever I create a new ressource it is being automatically granted the 'Resource - Enter Time' instance right.As a consequence the ressource gets a minimum license level 'Participant' which is a higher level than 'viewver. Is there a way to prevent new ressource to be automatically granted 'Resource - Enter Time' right? Thanks,Jerome

Hi, i don't know how to prevent it.If you are creating the user manually then you can delete the Enter Time rights manually.If you are creating the resources via upload then you can try to remove the rights via xog. Important :- This xog will remove all instance level rights not any specific rights like "Enter Time Rights".i haven't explored to remove any specific instance rights.If you find that then you can put this one as an scheduled job removing the rights weekly/bi-monthly. whenever the user is de-activated i used to remove all user's rights related to global,instance,group level via this xml.(Monthly once).
cheers, sundar

If you create the "resource" as a "user" I think Resource - Enter Time right is automatic ie code.Kinda curious that it does not allow time entry without timesheets navigate. If you create the "resource" as a "resource" then the user is locked, but I think the right Resource - Enter Time right i still automatically granted and with locked status it is still counted as participant. If that is correct there is no supported way to solve your problem. Martti K.

Yes, this is correct. In both cases the right Resource - Enter Time is automatically added to the user.Same behavior with XOG. This means than by default all user get the participant license level, ie.a level higher than the viewer one.I am wondering if this is the expected behavior? The only workaround I can see if to remove for each ressource the instance right. Jerome

Hi, i don't know how to prevent it.If you are creating the user manually then you can delete the Enter Time rights manually.If you are creating the resources via upload then you can try to remove the rights via xog. Important :- This xog will remove all instance level rights not any specific rights like "Enter Time Rights".i haven't explored to remove any specific instance rights.If you find that then you can put this one as an scheduled job removing the rights weekly/bi-monthly. whenever the user is de-activated i used to remove all user's rights related to global,instance,group level via this xml.(Monthly once).
cheers, sundar

However, in v12SP03 it did not work exactly as planned:The security model is overahauled in that version and SP04 and there are no participant viewer licences any more.Both are team members. So not writing timeentry does not change the license requirement. Martti K.

It works too for CA 12 SP4. In Clarity 12 SP4 the license types have being modified. New ones are : Enterprise Visibility Option (EVO) , Team member, ManagerAs compared to (CA 8.1): Viewer, Participant, Creator, Studio Developer, Other I tested the XOG proposed by sundar and I get an EVO licence that corresponds to the former viewer license.If you do not remove Resource - Enter Time you get a Team license which is a level above the EVO one (corresponds to the former Participant) license. Thank you all for your helpJerome

Jerome, Happy to hear that as we also started working for our Big Bang upgrade to v12 sp4. But have u changed the xml,how did you removed that specific rights (Timesheet Enter Time) alone? cheers,sundar

The security model is overahauled in version in v12SP03 and of course it is the same for SP04 There are no participant viewer licences in the User count by licence type any more both are team members.
You can see that if you open team members and drill down to a user. The Enterprise visibility option user is a viewer. Martti K.

Hello, Martin, Sundar, et.al.
ITW has a large EVO population. We have discovered that an EVO Resource added as a Participant to a Project is awarded an "invisible" access right, "Project - Participant (Auto)" that increases the Team License count, even though the Resource has only View rights.

Have opened a Case, number 20252902-1, to determine if this is known bug.
Steve V.

Hi Sundar, By creating the user via XOG using your your exemple the system creates the user without the right 'Resource - Enter Time'The bit of instruction that does the trick in the XOG is . Here is the complete XOG instructio for R12 SP4

I'd love to be able to review this XOG format for some applications within our instances, but I don't see it included in your post. Has the XML been removed, or is it there but something in my browser configuration is preventing me from seeing it?

Hi Jerome, It's possible to restrict "Resource - Enter Time" access rights when you create a new user from Application (UI) or XOG. But you have to change some source file. It's not advisable to change the source file. if you want to change the source file, first get the approval from CA, before implement this in production.First taken backup file from your development server then change the following source file. once changed, you have to restart the application services, then try to create a new user from application and XOG then provide your feedback. Application (UI) : \META-INF\nmc\xbl\insertUser.xbl Just Comment the following section in insertUser.xbl file. XML : \WEB-INF\xog\xql\cmn_users_write.xql ThanksSenthil.

I want to create a ressource with limited access right i.e. with a viewer like license type (read only access to project). The problem is that whenever I create a new ressource it is being automatically granted the 'Resource - Enter Time' instance right.As a consequence the resource gets a minimum license level 'Participant' which is a higher level than 'viewer ' I strongly suggest you contact your local CA office to clarify licensing before you attempt any customizations. Please. 'Resource - Enter Time' is very basic in Clarity and "assumed" in the licensing I believe.

Just wondering again...If you can do it in the GUI it should not count as customization, should it? If the objective is to create a user type viewer, how would you do it? Yes, timeentry is very basic, but it is only for those who do actual work, not if you just want to view info, right? Martti K. Message Edited by another_martink on 26-10-2009 02:18 PM [left]

Hi, As paul said you pls clarify with CA / Account manager... Hope you can justify CA that "enter time" is an default rights comes with user creation and these users are not entering timesheet.For the users who are not entering time you would have set "Open for time entry" as "un checked" and Track Mode = 'None' in Resource Level.As an proof you can also add these 2 fields and show in the user licences,so that these users only hold "viewer Licence". cheers,sundar

Timeentry right means that the user can enter time.That is different from open from timeentry.Open for timeentry means somebody with timeentry right may enter time. It does not have to be the resource self. Martti K.

This is in response to latest posts of Steve and Sundar which for some reason I can only see when not logged in.

This relates on one hand to the Auto rights in general and on the other hand to the Collaboration rights being out of the standard rights administration.
As far as I know there have been a number of ERQ for putting the collaboration rights into the rights administration for easier handling of situations like where the collaboration manager leaves the organization. I have not seen any position regarding these ERQ's but because the system is still as it has ever been I take they have not been approved.

Therefore I think you can conclude that the response to the auto participant will be that the product works as designed.

A reasonable request regarding the Auto rights is that they should be listed in the documentation with the rights they have.
That would make it easier for the rights administrators to design the security model to have roles with equal rights for others if needed and have better understanding where the model "leaks".

Wonderful work, Martin.
While I don't fully understand it yet, "Rightstool" appears to be an Excel workbook for designing access rights sets for Resource Groups? Please advise the XML tab, if this is a mechanism for assembling XOG filles.

The problem here is relatively simple, in comparison. It has to do with the Auto rights you mentioned in your post.
ITW uses the Clarity job LDAP Sync to create new user Resources.
These are to be EVO users, view-only, which they become when the Auto right "Resource - Enter Time" is removed.
This is essential for a global deployment of Clarity.
However, when added to an Investment as a Participant, these EVO users incur a Team Member license because of the Auto right "Project Participant", although they remain view-only users.
Was wondering if there are other sites at which this is an issue?

The purpose of the RIghtstool is to help in creating the user groups in the security model of your choice.
You have a column for each group (you can name them on the Global tab) you mark the desired rights with x's.
The formulas transfer them to the summary tabs. There you filter out the blanks to get global, instance and OBS rights without spaces.
The license columns tell you the license requirements. You can lower them a little in some areas if you use instance rights instead of global.
The xml tab is there to get you started for creating the groups with rights with XOG. It is simplest with global rights. The right codes are the same as xml tags. For instance rights you need the instances and OBS rights you need the OBS units. Typically with OBS rights there are several similar groups related to different OBS units but having the same set of rights.
Therefore I normally copy the right codes to another worksheet where I have the xml file headers and footers, set of formulas and data to complete OBS rights and manually finalize the instance rights. If instance rights are given to a group they are usually the same instances to (OBS based) groups.
Then one more tab to summarize all the xml's of the same type of groups to one single file.
That way you have a record of what you planned and it only takes a couple of hours to implement a dozen types of groups each with a dozen OBS based variation.

Now the Automatic rights are listed, too.
The main use of that spreadsheet is planning the license requirements or should I say being aware of the requirements in that area, Both the old and new license model types are there.

Now it appears that you are gonna be a board member you could be aware that there was a GUG session where that Rightstool was presented and the recording is still available.