chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karsten Eberding <kars...@eberding.eu>
Subject Re: support for adding List<Object> to cmis:Document
Date Tue, 04 Sep 2012 16:02:59 GMT
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 karsten@eberding.eu

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" <mcs130@gmail.com> 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 <jeffpotts01@gmail.com> 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
>>>> * *
>>>
>>
>> *
>> *
>>


Mime
View raw message