see also "Global resource pool (issue 57640)"

We should foresee pool data.
This can be done e.g. by a link to a pool file or integrated.
The way a link form project to pool is established. It would be usefull to have
also a link from the pool to the project, so that a resource can get data on all
the projects he is working on.
The software must be tolerant against changes in file locations (allowing to
find the file).

Pool data:
- resouce-pool
- calendar pool (e.g.base calendar of a country / company)

To put this in context with a hypothetical enterprise multi user scenario and a
more or less real single user scenario:

In order to implement such a global "resource" pool across individual project
domains, we require that we

a) integrate into for example existing directory services used for both
authentication and authorisation, along with also provisioning of additional
data and meta data on the "resources", aka users being assigned to individual
tasks of a project a/o holding ownership in for example the lot of the project,

b) integrate into existing ERPM solutions for example for handling material
allocation/reservation/ordering incl. also provisioning of additional data and
meta data and so on,

c) integrate into existing accounting and booking solutions for example for
automatic synchronisation of cost and budget information incl. also for
provisioning of additional data and meta data and so on,

d) as for calendar pools, we will also have to go the distributed way in order
to solve it the local way, i.e. by introducing abstract apis, see below

e) make all of the above available to a single user installment in a more
rudimentary way


As you can see, in the enterprise context, the global "resource" pool is more or
less a distributed resource pool, with many of its distributions being currently
undefined as to the complex nature of the possible integrations into existing
past and future solutions for accounting/booking, ERPM and so on.

But we may know for sure, that in an enterprise context, we at least can assume
that we have some kind of directory service available, from where we at least
can get user information and also role/group associations.

What we cannot be sure of is the exact nature of the accounting/booking, ERPM
solution being used, and so on. For this we need to plan ahead in that we
provide proper extension points to be satisfied in the future by third party
extensions.

As such, the global resource pool, when being seen as for actually being
distributed in its overall nature, we surely have to implement a most abstract
api in order to make this all happen.

When it comes to a single user installment, we surely have to provide a
cross-project resource pool from where users can include/import/reference/reuse
existing resources defined in their local environment.

For this, we can use for example the local PAM/SAM for authentication purposes
alone, however we still have to add the capability of group/role associations
and we will therefore also have to manage this locally, whilst always being able
to transition to a multi user scenario as required by the user. Unless the user
is capable of authoring the /etc/passwd,/etc/shadow,/etc/groups,/etc/gshadow, or
the SAM provided local users and groups management facility.

However, not all users can handle such, rather difficult tasks, and, besides,
most of these operations require root access to the system.

Therefore I would assume that besides from going the local PAM/SAM way, we also
include a complete and integrated solution ourselves for managing users and
groups, also handling authentication (if required in a local installment) and
authorisation as well.

As for calendaring, we should definitely provide for multi calendars of some
sort, where multiple project calendars are layered so that a single user can see
all or some (filtered) of the scheduled items that he is inclined on working
with/on.

However, I do not see calendars as for being part of the global resource pool,
they actually arise naturally from all of the scheduled items that a user (in
your terms this would be a human resource) has been or had been assigned to.


Additionally, what you actually call the resource pool also includes all of the
available projects, milestones and tasks associated with any of the projects
available. Including also roles, role assignments and groups etc. This also
includes any of the permissions defined.

As such, we always will talk about a distributed resource pool, where the global
resource pool is actually a rather complex view on a manifold of available
resource pools, even if it is all contained in a local environment.

I would propose that we add to the requirements analysis component (ra) the
following (sub)subcomponents, if possible

ra::Localisation::CalendarAndTimezone
ra::Calendaring::Integrations::IMAP
ra::Calendaring::Integrations::Exchange (if required, see IMAP integration)
ra::Calendaring::DataExchange::MailboxFormat (see Kollab, and other solutions as
well)
ra::Calendaring::DataExchange::MaildirFormat (see Kollab, and other solutions as
well)
ra::Calendaring::DataExchange::Feeding::RDF
ra::Calendaring::DataExchange::Feeding::Atom
ra::Calendaring::DataExchange::ICALFormat
ra::Security::AuthorizationAndAuthentication
ra::Security::RoleBasedAccessControl
ra::Security::Roles
ra::Security::Groups
ra::Security::BestPractices
ra::Security::Integrations::Custom (OOPM Custom Solution for Single User
Scenario, replacing local PAM/SAM incl. group assignments)
ra::Security::Integrations::PAM (also incl. adding role based access control to
local PAM)
ra::Security::Integrations::SAM (also incl. adding role based access control to
local SAM)
ra::Security::Integrations::LDAP (group/role assignments incl. also additional
data/meta data on users/groups/roles)
ra::Security::Integrations::ActiveDirectory (see LDAP)

I forgot 

ra::Security::Permissions


I reckon that there are a lot of commonly shared permissions, for example the
CreatePermission and others as well.

However, additional permission schemes will be introduced by the objects that we
either define from start or that will be introduced into the system later
because of its overall extensible nature.

Reset assignee on issues not touched by assignee in more than 1000 days.

obsolete