Hi Anahide, thanks for the fast answer.
Anahide Tchertchian wrote: >> >> I am trying to adopt CPS and CPSWorkflow for a studentadministration >> process. >> >> The most problems I have in doing this is mapping the documentpublishing >> centric view of CPS to this process. >> >> CPS and CPSWorkflow is about publishing documents in a collaborative >> way. The creation and reviewing process happens in a workspaces and the >> resulting document is published in a section. >> The creator is the owner. > > > I'm not sure I agree : *CPSDefault* is about publishing documents, but > CPSWorkflow (and CPS) are not so specific ; you can adapt you workflow > for such a purpose. > However CPSWorkflow is document centric, this is a constraint inherited > from DCWorkflow. But this is not a problem for your use case. > >> In a studentregistration it is very different: >> - The creator of a student-record (document) is the studentadministrator >> - A student may only view and modify certain data of HER/HIS record > > Ok so other data need to be editable by other users (student > administrator perhaps? sure, but it also must not be even viewable by other students > >> - A student must fill in other data of HER/HIS record >> - A student may view only certain data, which others fill in i.e. >> examination results. >> - the record gets never really published, it goes through a lifecyle, >> so the notion of workspaces and sections makes no real sense here. > > Then chose where you'd like these documents to live (sections or > workspaces) and leave them there : your document does not *have* to go > through a publication related transition. > >> So my question is, did anybody already use CPS for such a purpose, or >> can give advise how to do so ? > > > Yes, we use CPS and its workflows for purposes like this one very often. > Are there examples, where I could take a look at ? > I would advise (if you chose workspaces as the main container) to make a > mapping between different users and roles available in workspaces. Let's > say student administrators will be defined by the fact that they have > the WorkspaceManager role, and students will be defined by the > WorkspaceMember role. > > Then you'll define your workflow using these roles taking care of your > conditions. Ok I chose a section as the main, container in our prototype. How would I achieve that a student only see's his/her data, can I (ab)use the owner-attribute for that ? Or the question asked CPSWorkflow specific. What is the role of the student I put on the workflow-stack or do I put the student-memberid on the workflowstack, if only he is allowed to do something at this stage. > > I'm not sure I understand what is the life cycle through which your > document goes: what are your states/transitions? This is the first > designing step. > The lifecycle of the student-record should reflect the students lifecycle at the university, I created the student-record therefore as a folderish document, which can contain the data for the different semesters for example. By the way, do you use any tools for describing and visulisation of workflows ? > About protection of some of the document data, you can play with the > widgets condition expressions to control the presentation (and have > conditions like: "if user is a WorkspaceManager and layout mode is > 'edit' or 'create', widget mode is 'edit' too, else it is 'view'") > Thanks for the hint. > I'm not going through details now, because it looks like you're not > there yet, but do not hesitate to ask other questions. Actually we have already a working prototype, which uses the basic CPSworkflow just for documentcreation and editing. And now I want to add the "real" workflow to it. -- Mit freundlichen Grüßen Joachim Schmitz ...................................................................... AixtraWare eK ..Joachim Schmitz ..www.aixtraware.de ..t: +49-2464-8851 Hüsgenstr. 33a .....d-52457 Aldenhoven .............f: +49-2464-905163 _______________________________________________ cps-devel mailing list http://lists.nuxeo.com/mailman/listinfo/cps-devel
