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 > > > > > > > > > > > > > > > >
