Guild of Project Controls: Compendium | Roles | Assessment | Certifications | Membership

Tips on using this forum..

(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?

(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.

Progressing Milestones in the Spreadsheet

1 reply [Last post]
John Barter
User offline. Last seen 6 years 34 weeks ago. Offline
Joined: 17 Aug 2017
Posts: 2
Groups: None

When I log in as admin I can progress milestones in the spreadsheet, but when I log in as a user inside of a security group I have to progress up to 100% complete on the Gantt Chart and then change the date. The error reads that I do not have sufficient access rights when I try to apply the progress on the spreadsheet but I cannot find the specific setting that is stopping me from doing so. Any suggestions?

Replies

Mike Testro
User offline. Last seen 4 weeks 5 days ago. Offline
Joined: 14 Dec 2005
Posts: 4418

Hi John - welcome to planning planet

This is an extract from the Asta website on assigning user rights.

I hope it helps.

You specify user access rights in Asta Powerproject by setting up and configuring a combination of users and security groups.

You should create a user record for each individual who is to log into a project using a different user name and password. You may find it useful to create a hierarchy of users that reflects the hierarchy of your organisation. For example, you could create a number of user folders to represent each department within your organisation, with individual user records within each folder to represent the people within each department. If you create a hierarchy of users, you should create the entire hierarchy beneath the top-level user in the project - the Admin user.

You can assign different access rights to different users. You do this by creating a number of security groups in Library Explorer, with each security group defining a different level of access, and assigning users to the security group that matches the level of access that you want them to have. Security groups determine the access rights that users have to the charts, summary groups, fields and library objects within a project. You should create a security group for each different level of access that you want to grant the various users in a project. For example, the Project Manager may be a member of a security group that gives modify access to the whole project, but a Line Manager may be a member of a security group that gives only read-only access to the sections of the project that affect the manager and their team. You assign users to the appropriate security group using the Security group field on the User Properties dialog, or by using the Security Group Members dialog, which you can access by right-clicking a security group in Library Explorer and selecting Security Group Members.

You may find it useful to create a hierarchy of security groups that reflects the hierarchy of your organisation. For example, you could create a number of security group folders to represent each department within your organisation, with individual security group records within each folder to represent the different levels of access that people within the department should have. However, the security group hierarchy does not have to mirror the hierarchy of your organisation; nor does it have to mirror the hierarchy of users within the project.

If you create a hierarchy of security groups, you should create the entire hierarchy beneath the top-level security group in the project - the Admin security group, which has full rights to everything. When creating a hierarchy of security groups - with security groups located in folders together with other security groups that have similar or identical access rights - it is good practice to create the security group folders and assign appropriate access rights to them before creating the security groups within each folder. This way, the security groups that you create within a folder will automatically inherit the access rights that you have assigned to the folder. If you create the individual security groups before assigning access rights, you will have to assign access rights to each security group individually.

You can assign more than one user to each security group, but each user can be a member of only one security group.

When editing security groups, note that you cannot grant subordinate security groups access rights that your own security group does not possess. If you think you need to have your access rights extended, contact your System Administrator

Best regards

Mike Testro