Global Specification

[xNok]

I open this issue to open the debate on the project specifications. It's for my part a way to define this project. I will complete this part step by step to create the guideline documentation

Global System

Database management (REST API)

The technological choice of DunglasApiBundle offers a systematic way to create, retrieve, update and manage data. Moreover LoopBackApiBundle add more even more finesse in the request.

More specifically it provide a REST API. Once you have created your database, resources are represented by URIs and actions are represented by Http verbs.

For instance : Get all users GET request on /api/users Get an user GET request on /api/user/{id} Create a new user POST request on /api/user/{id} Modify an user UPDATE request on /api/user/{id} Delete an user DELETE request on /api/user/{id}

Incipio should at first provide an entry point on a secure platform. With login attemps management et permission management. With no consideration of members or association management. This let anyone the possibility to change easily the structure of basic module.

If we aggregate user and member whe could lost possibilities and the power of DunglasApiBundle.

• It is more complicated for frontend developer to use se structure if we aggregate entity such as member and client.
• It increase the risky of error when we create new feature (even if we add tests)
• It complexify the possibility to change the structure after all

A log system could help admin to manage Incipio,to find modification and errors

Document management (EDM)

The second goal, I think, is to create a document management system. Because we will manage a lot of document (AP, CC, Student convention, ...). We should have the same structure for all document to store them on the web server, generate them if possible and manage them simply after all.

Basic modules

The association management module

How to best describe the structure of a given Mandate for a JE ? This is an exemple of what i want to modelize :

How to manage membership ?

How to manage Alumni ?

How to manage contractors ?

• Is contractor related to assoiation management or project management ?

A contractoris a member with a "Contractor" job, which would be a prepopulated job and that could not be removed. But still, a contractor is belongs to the association management. But, that does not exclude the possibility to attach them somehow to a project.

The project management module

The accounting module

[theofidry]

Database management (DBMS)

Rather than being the "database management", you can call it the API. If you want to be more precise it's a REST API. But the description is right, it's the part responsible for manipulating and persisting the data.

Regarding the security, we can use ACL.

Document management (EDM)

I would avoid that as much as possible. Not that it's not an interesting feature, but it's a very tricky one. There is a lot of EDM in the wild, but few that works well (Dropbox, Google Drive, Sinology). But we can handle documents generation without much problem.

How to best describe the structure of a given Mandate for a JE ?

A mandate is defined by it's period of exercice. One can belongs to a mandate though a job he gets with it.

Is contractor related to assoiation management or project management ?

Association

[xNok]

Database management (DBMS)

Rather than being the "database management", you can call it the API. If you want to be more precise it's a REST API. But the description is right, it's the part responsible for manipulating and persisting the data.

I've completed this point.

Document management (EDM)

I would avoid that as much as possible. Not that it's not an interesting feature, but it's a very tricky one. There is a lot of EDM in the wild, but few that works well (Dropbox, Google Drive, Sinology). But we can handle documents generation without much problem.

I agree on this point. We wil not add an entire EDM but we must create une guideline for document referenced on the ERP.

What I called the Incipio's Global System is a set of rules and practices. In order to provide a commun staddlestone for the other modules. If actually i want to start a part of module, I can't because I've not enouth information to go in the same way that the rest of Incipio.

How to best describe the structure of a given Mandate for a JE ?

A mandate is defined by it's period of exercice. One can belongs to a mandate though a job he gets with it.

for my part this may be not enouth to recreate the organization chart of a mandate. May be It should use a tree Jobs structure. Also we ca Add a type on Jobs, but can we easyly manage types after all ?

Why do we do that ?

• If i want to get information on a group of job such as project or communication
• If i want to send email to a group of job

Is contractor related to assoiation management or project management ?

Association

For my art it is not that simple. someone is contractor only for a given mandate or he is bound to be contractor for a mandate this is may be a job infact. It is not a global proprerty such as a type for my part. We could alo say that a contractor is someone related to a project. Thus it is a part of project management.

[theofidry]

for my part this may be not enouth to recreate the organization chart of a mandate. May be It should use a tree Jobs structure. Also we ca Add a type on Jobs, but can we easyly manage types after all ?

I agree with you. If you want to create a full hierarchy it is necessary to attach a type defining a certain level of permissions on a job basis. However this is very complex and is quite a pain to manage and set properly, this is why most of simple ERP just provide a permission management on a group or user basis. In the case of a J.E., although lots tend to try to, they very rarely need such granulation in the permissions management. So IMO it's better to keep with a simpler model.

Why do we do that ? If i want to get information on a group of job such as project or communication If i want to send email to a group of job

We do have groups, but they are not job related, only user related at the moment (it's the FOSUserBundle groups). But I'm sure we can tweak it to have what we want. That being said, I still believe we should keep this only as a way to contact a set of user and not for permissions management.

But I'm sure @flef has his word to say too.

For my art it is not that simple. someone is contractor only for a given mandate or he is bound to be contractor for a mandate this is may be a job infact. It is not a global proprerty such as a type for my part. We could alo say that a contractor is someone related to a project. Thus it is a part of project management.

I'm for defining a contractor as a member with a "Contractor" job, which would be a prepopulated job and that could not be removed. But still, a contractor is belongs to the association management. But, that does not exclude the possibility to attach them somehow to a project.