Sounds reasonable to me. Karl
On Sun, Mar 16, 2014 at 3:26 PM, Ahmet Arslan <[email protected]> wrote: > Hi, > > Great to hear that, I think we shouldn't include built-in fields when user > checks "include all metadata". > > > If a user > > a) selects "include all metadata" do not include built-in fields. Same as > before. > b) intents to select subset of fields, display built-in fields with a > informative pretty name. > > And document above. I think this approach is reasonable. > > Thanks, > Ahmet > > > > > > > On Sunday, March 16, 2014 6:15 PM, Karl Wright <[email protected]> wrote: > Hi Ahmet, > > See lines 1616 and 1276. This is the full list of available fields is > calculated. You will need to change these lines too if you want "all > metadata" to include built-in fields. > > Karl > > > > > On Sun, Mar 16, 2014 at 9:43 AM, Ahmet Arslan <[email protected]> wrote: > > > > > > > Hi, > > > > 'name (built-in)' for pretty name makes sense and informative. What will > > be the behavior when user checks 'include all metadata' with this > approach? > > Will combined fields list be sent to output connector? > > > > > > Ahmet > > > > On Friday, March 14, 2014 7:15 PM, Karl Wright <[email protected]> > wrote: > > Hi Ahmet, > > > > Yes, I don't think it is necessary to distinguish functionally between > > built-in metadata and user-defined metadata. It all works exactly the > same > > way. But if you like, you can make the pretty name of the built-in > > metadata be something like this: > > > > name (built-in) > > > > ... if you think that would help people to understand where it was coming > > from. > > > > Karl > > > > > > > > > > On Fri, Mar 14, 2014 at 1:05 PM, Ahmet Arslan <[email protected]> wrote: > > > > > Hi Karl, > > > > > > So you want me to add hard-coded field names in > get{Lib/List}FieldList() > > > methods? > > > So that, combined field list (current field list + built in fields) are > > > displayed to the user. > > > User then select subset of them. > > > > > > > > > I initially thought about a new GUI feature (add a built in metadata > that > > > is not listed here), analogous to Forced Metadata, to enhance existing > > > metadata fields. > > > > > > > > > Ahmet > > > > > > > > > On Thursday, March 13, 2014 11:54 PM, Karl Wright <[email protected]> > > > wrote: > > > Hi Ahmet, > > > > > > Yes, you add the internal name and the display name to the map, just as > > you > > > demonstrate. > > > > > > You would probably want to avoid including fields that would change on > > > every document access, because that would break incremental crawling. > > But > > > otherwise you can include most anything, although some fields would be > of > > > limited utility. Since we'd have to support them forever going > forward, > > > I'd add the minimum right now, and add more later as need arises. > > > > > > Karl > > > > > > > > > > > > > > > On Thu, Mar 13, 2014 at 5:38 PM, Ahmet Arslan <[email protected]> > wrote: > > > > > > > Hi Karl, > > > > > > > > bq. adding specific canned values to the current result of > > > getLibFieldList > > > > > > > > Something like this? > > > > Map<String,String> map = proxy.getFieldList(); > > > > > > > > map.put("UniqueId","UniqueId"); > > > > map.put("EncodedAbsUrl","EncodedAbsUrl"); > > > > > > > > return map; > > > > > > > > bq. making sure the "built in" fields you include actually exist on > all > > > > SharePoint 2010 systems. > > > > > > > > During experiments I added non-existent field name, it didn't harm > > > > anything. > > > > I assume, if a user adds an additional 'built in' field, isn't that > > > user's > > > > responsibility to checks its existence? > > > > > > > > I will try to learn more about built-in fields next week. > > > > > > > > Thanks, > > > > Ahmet > > > > > > > > > > > > > > > > > > > > On Thursday, March 13, 2014 7:08 PM, Karl Wright <[email protected] > > > > > > wrote: > > > > Hi Ahmet, > > > > > > > > It is actually simple to add built-in fields to the connector by > adding > > > > specific canned values to the current result of getLibFieldList and > > > > getListFieldList, around line 3722. But there are some issues here. > > One > > > > issue is that built-in fields may or may not have existed in earlier > > > > versions of SharePoint, so you would have to confirm that SharePoint > > 2003 > > > > and SharePoint 2007 both had the fields you were looking for. The > > second > > > > issue is making sure the "built in" fields you include actually exist > > on > > > > all SharePoint 2010 systems. > > > > > > > > If you can answer these questions, feel free to create a ticket and > > > propose > > > > a patch. > > > > > > > > Karl > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 13, 2014 at 12:51 PM, Ahmet Arslan <[email protected]> > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > I have a use-case where I want to add additional metadata field > names > > > > > (EncodedAbsUrl, UniqueId, ServerUrl) in share point connector job > > > > > definitions. Somehow these metadata field names are hidden and not > > > listed > > > > > when multi-selecting metadata fields. I assume these are similar to > > > GUID. > > > > > > > > > > I confirmed these metadata fields values are fetcable, by adding > > > > > "metadataDescription.add("EncodedAbsUrl");" to several places in > > > > > SharePointRepository.java. > > > > > > > > > > It would be nice to edit existing metada field names, or add new > ones > > > via > > > > > GUI or something. It would be nice to edit existing metada field > > names, > > > > or > > > > > add new ones via GUI or something. I need this for both 'document > > > > > libraries' and 'lists' > > > > > > > > > > What do you think about adding this feature? > > > > > > > > > > Thanks, > > > > > Ahmet > > > > > > > > > > > > > > > > > > > > > > > > >
