1) global vs project-wise profiles. I assume the global profile to be the "default" for to-be-assigned projects AND to give "global access" rights if so granted on project-dependent data; whereas the project-wise profile possibly grants increased rights on this project's data but so encapsulated as to have no effect in other projects nor in global functions.
Yes you are right.
Just in addition, project level profile can decrease rights on a project.
For instance you can allocate an admin with guest profile on a project to reduce his rights on this project.
Also rights at project level are inherited (recursively) to sub-projects.
2) effect of Profile codes. The manual suggests there are two "special" profile codes ADM & PL ; but I didn't find what behavior they imply.
ADM identifies an 'Admin' profile. Only admins can coonect when application is closed (to reopen it) or during migration
PL is for Project Leader. When you send an email to Project Leader, it selects all resources allocated to the project with profiles having coee PL
3) Profiles access vs items Manager. How do "responsible for" & "own projects" access modes interact with the "manager" property on Projects/Organizations/Teams on the one hand, with special Profile codes ('PL' at least) on the other?
It just does not. Project manager is just informative or to send email. It does not manage rights.
"Responsible for" gives acces to items (tickets, activities) the resource is name reponsible.
"Own projects" means all projects he is allocated to.
How can I get a Team or Org manager to be able to create/edit assignments of his "own" Resources on Projects in his Organization ?
You cannot through "manager"? You must allocate the resource to the project. Also Organization is not used to manage rights except for resource list visibility.
4) Access to forms vs to data. I understand Form access to be a pure GUI filter, independent from rights on data objects managed through each screen.
Yes, but not only. No access to form will mean no acces right, whatever other options. This will also be applied to non GUI interfaces (import, API)
5) Project data vs Specific access. Is there a priority or cumulative requirement between specific access rights like project allocation, task assignment, real work input, task prioritization, planning calculation, on the one hand ( manual.projeqtor.org/html_en/AccessRights.html#specific-access ); and "project data" modification rights on project, activities, resources, on the other hand?
Specific acces give additional restriction. For instance you can define that a profile can update activities (acces to data) but cannot change validated data (work, cost, start, end). THis will allow tema members to change result of activity but not the "reference" data.
E.g., do I need to be allowed to modify project activites and/or resources to be able to assign the latter to the former?
Yes, you need to be allowed to update activities (but not to update resource) to assign resource to activity. Assignment changes the activity (but does not change the resource)
6) Resource vs Pool allocation to Projects. Let a Pool be allocated to a Project; if any or all individual Resources included in the Pool are not allocated, what will be the Pool available resource capacities taken into account for an activity assignment in the Project?
The sum of capacities of the resources allocated to the pool. You don't need to allocate resources individually if you don't want to plan them individually and give then access to data of the project.
For instance for support project, support team can be allocated as a pool and not individually. But then resources can enter work on activities of the pool, but not see or update items of the project.
Supportez nous sur Capterra
STOP INFO
