Mark,
adding a multi-valued property for your UserNotes should be
straightforward by defining this in your model for Alfresco.
But be aware that the Alfresco permission model (like most other ECM
systems) only manages one permission per document object. You cannot
have different permissions per property, and certainly not per entry in
a single multi-valued property. As you want to have users to be able to
write to the last note, but not change any previous notes, I don't think
this approach fits your needs.
Of course, you could find workarounds, like managing access restrictions
in the client UI or changing fields through a system user as part of a
workflow. But this has other drawbacks, a concept with a separate object
per note seems to be much easier to setup.
Just my thoughts.
thanks
Karsten Eberding
St.-Martin-Str. 19
85604 Zorneding
Phone +49 171 3090201
Mail [email protected]
Am 04.09.12 17:29, schrieb Mark Streit:
Jeff
I did read your updated version of the Alfresco Content Model paper
(SomeCo)
http://ecmarchitect.com/images/articles/alfresco-content/content-article-2ed.pdf.
I saw the model that you have for modeling the "whitepaper" concept. I
don't think anything short of being able to add a multi-valued property
like the List<UserNote> concept will work for our application. I have
doubts that SharePoint, as an ECM choice, can even support this anyway and
would guess Alfresco might be the closest at being able to do this given
its configuration capability as you describe in your paper.
Do I understand correctly that no matter what we did, the UserNote object
would have to be a subclass of cmis:Document ? Perhaps I am not
understanding.
The current model we have been using successfully looks like this (where
userNote is actually just a text (String) property type:
<types>
<!-- Enterprise-wide generic document type -->
<type name="acme:doc">
<title>ACME Document</title>
<parent>cm:content</parent>
<properties>
<property name="acme:documentDisplayName">
<type>d:text</type>
</property>
<property name="acme:documentType">
<type>d:text</type>
</property>
<property name="acme:userID">
<type>d:text</type>
</property>
<property name="acme:category">
<type>d:text</type>
</property>
<property name="acme:subCategory">
<type>d:text</type>
</property>
<property name="acme:expirationDate">
<type>d:date</type>
</property>
* <property name="acme:userNotes">
<type>d:text</type>
</property>*
<property name="acme:keyWords">
<type>d:text</type>
</property>
</properties>
It is the following element definition above:
<property name="acme:userNotes">
<type>d:text</type>
</property>
Where we want the actual <type> to be definable as a List<UserNote>
1) we have to be able to define UserNote (obviously we can model as simple
Java bean)
2) we need to be able to have this acme:doc defined such that it can
include the List<> construct
I am guessing this may not be feasible?
Thanks..
Mark
On Aug 31, 2012 2:31 PM, "Mark Streit" <[email protected]> wrote:
Hi Jeff
Thanks for the quick response (seems to be common on this list which is
really appreciated).
I see what you are saying. Not sure if it is quite along the idea the
team was thinking of for this application. The notion of being able to
model a *UserNote *object and hold a List<> of them as part of the single
cmis:Document instance was really the desired approach.
The custom web front end being developed presents 2 of the 4 items, say
categoryCode, type=String
subCategoryCode, type=String
as drop downs the user selects from - we control the values with a
configuration file. When the document is added or updated, these
properties are then set and saved to the back-end ECM via openCMIS (only
one objectId for the Document is involved). This has worked just fine.
Now the UI design has been altered to allow a free-form text input
field...input text box allows the user to enter a "note". The intent is to
to add this note to a persistent *list* of notes that rides around on the
cmis:Document instance - when the save button is pressed, the note is added
to the list. There is also a history link let's say, where the user clicks
- and a this now, non-editable, list pops up showing the history.
Does that help better illustrate?
Thanks again.
On Fri, Aug 31, 2012 at 1:03 PM, Jeff Potts <[email protected]> wrote:
Mark,
You could use relationships in repositories that support it to associate
documents with N notes. For repositories that don't support it, a note
could be a cmis:document and you could track cmis:objectId's of notes in a
multi-value property on the cmis:document (more likely a child type of
cmis:document) instances related to those notes.
Does that make sense or am I missing your intent?
Jeff
On Aug 31, 2012, at 10:45 AM, Mark Streit wrote:
I have seen a few threads on a similar topic so pardon if this is
duplicated.
First off, I know that this is completely dependent on the ECM product
supporting this. 2 ECM products are being considered - SharePoint 2010
(or
possibly 2013) and Alfresco 4
Second this an all Java implementation from the client side. Here is
the
scenario.
We can currently add properties to *cmis:Document* .... let's say for
simplicity, we add:
categoryCode, type=String
subCategoryCode, type=String
displayName, type=String
employeeID, type=String
This works fine in both products - in one case, AF4, you extend the
model
with an XML configuration file whereas in Sharepoint, you can use the
Library Admin page to add fields of various types to the current
document
model. So far, so good.
Now, we have a use case, where we need these same 4 properties, PLUS a
List<UserNote> where:
UserNote:
id, type=long
date, type=Calendar
noteText, type=String
As I see it we have to 1) define the UserNote object in the ECM backend
somehow and 2) add this List<UserNote> property to the cmis:Document.
What
they are looking to do is to keep the history of these notes made by the
user on this Document whenever they retrieve it to edit, etc. Not
trying
to reproduce version control as much as attaching these ad-hoc notes
managed on the Document.
My 2 questions are:
- Can the CMIS APIs support this use case?
- If so, can anyone suggest an example or point to document showing
something similar to this?
Thanks in advance for any insight or suggestions.
--
Mark
* *
*
*
