Alfresco discussion and collaboration. Stick around a few hours after asking a question.
Official support for Enterprise subscribers: support.alfresco.com.
Join in the conversation by getting an IRC client and connecting to #alfresco at Freenode. Our you can use the IRC web chat.
More information about the channel is in the wiki.
More help is available in this list of resources.
2020-02-21 08:51:19 GMT <alfresco-discord> <yreg> Good morning folks!
2020-02-21 08:53:01 GMT <alfresco-discord> <yreg> I want to do an exact partial match on "the flow" so I want "the magic flow" to be excluded but "I found the flow to be magic" included
2020-02-21 08:53:53 GMT <alfresco-discord> <yreg> is there a way to tell SOLR through FTS to do that.. ?
2020-02-21 08:55:30 GMT <AFaust> ehm... by querying for "the flow" as a phrase? Shouldn't that already exclude "the magic flow" because it has a word in between?
2020-02-21 08:55:34 GMT <alfresco-discord> <yreg> obviously =acme:someField:"*the flow*" would match "I found the flow to be magic" but also "Bathe flowers" which I would love to avoid
2020-02-21 08:56:03 GMT <AFaust> then do =acme:someField:"* the flow *"
2020-02-21 08:56:54 GMT <alfresco-discord> <yreg> That won't work either 😅 because I want "I hate the flow" without a tailing space to be included as well ...
2020-02-21 08:57:12 GMT <AFaust> though you then would have to OR combine it with =acme:someField:"the flow" OR =acme:someField:"the flow *" OR =acme:someField:"* the flow"
2020-02-21 08:58:33 GMT <alfresco-discord> <yreg> I was wondering if there were a magic word/operator to tell solr this word stops here without having to duplicate my same query three times to get a half working workaround
2020-02-21 08:59:38 GMT <alfresco-discord> <yreg> That won't work either because I would expect "Take the flow!" to match as well 😅
2020-02-21 09:05:08 GMT <alfresco-discord> <yreg> The requirements from the business is "Google-like" search with those scenarios as acceptance criteria ...
2020-02-21 09:09:18 GMT <alfresco-discord> <yreg> looking at angelborroy hoping for a bright stop word marker in solr to make all my users wishes come true ...
2020-02-21 09:26:03 GMT <alfresco-discord> <yreg> just in case of someone catching up and willing to throw their two cents into the issue... acme:someField:"the flow" matches "The magic flow" and therefore should be discarded =acme:somefield:"the flow" does only full exact match on the whole d:text field, and therefore is no good to me =acme:someField:"*the flow*" does take partial word match on both edges (ie: "Bathe flowers") and therefore is no
2020-02-21 09:26:03 GMT <alfresco-discord> good to me =acme:someField:"* the flow *" doesn't take the cases of the extrimities of the query colliding with the extrimity of the field, and also would never match "the flow!!" therefore I can not consider it I was considering (acme:someField:"the flow" AND =acme:someField:"*the flow*") with tokenisation setting set to BOTH but I am wondering about edge cases... I am also thinking that, few years ago, searching
2020-02-21 09:26:04 GMT <alfresco-discord> on a phrase inside the content did give a similar result to what I am trying to achive here, and therefore I am wondering if there is some setting in shared.properties or solrcore.properties that I can enable to achieve the same behaviour for my custom properties ...
2020-02-21 09:41:27 GMT <alfresco-discord> <dgradecak> have another field indexing the content the way you need ? 🙂 sure a bit more complex than a magic keyword
2020-02-21 09:52:05 GMT <AFaust> Argh... why does the Public v1 ReST API have to use a non-standard authenticator... have to add another explicit case of handling authentication differently when public API is called...
2020-02-21 09:52:44 GMT <AFaust> So I guess half of my DevCon talk about the Keycloak module might just be a rant about Alfresco and "Y U NO make authentication consistent"
2020-02-21 10:24:27 GMT <alfresco-discord> <bhagyas> xD
2020-02-21 10:25:53 GMT <alfresco-discord> <bhagyas> I think the bigger reason here is that you need repository for WebDAV, FTP etc, but ideally they should exist (at least proxied) through Share
2020-02-21 10:26:48 GMT <alfresco-discord> <bhagyas> Nearly the number one reason we can't recommend people to buy a 2FA solution, because it renders all other interfaces unusable
2020-02-21 10:27:36 GMT <alfresco-discord> <bhagyas> (╯°□°）╯︵ ┻━┻
2020-02-21 10:29:36 GMT <alfresco-discord> <yreg> not if you use it to generate application tokens that could be used to access all other protocols without 2FA
2020-02-21 10:34:43 GMT <alfresco-discord> <dgradecak> this is exactly what you can find here https://github.com/dgradecak/alfresco-jwt-auth
2020-02-21 10:34:44 GMT <alfbot> Title:GitHub - dgradecak/alfresco-jwt-auth: Alfresco Identity Service without Keycloack - but with a custom signed JWT (at github.com)
2020-02-21 11:58:02 GMT <younes> Ok, in case anyone was wondering, this did the trick (acme:someField:"the flow" AND =acme:someField:"*the flow*")
2020-02-21 12:16:36 GMT <AFaust> bhagyas: FTP only supports user name + password anyway, and no Alfresco filters deal with FTP requests, so no special handling. WebDAV / AOS may indeed be an issue, and so far I have ignored these (hard to test without MS Office at hand anyway), but will have a look at them when the main stuff is stable.
2020-02-21 14:19:32 GMT <alfresco-discord> <binduwavell> @yreg I'm very surprised that acme:some Field:"the flow" does not do what you want. I wonder if you can do a proximity search: acme:some Field:"the flow"~1
2020-02-21 14:20:00 GMT <alfresco-discord> <binduwavell> Not somewhere I can test so not 100% sure I have that syntax right.
2020-02-21 14:28:40 GMT <alfresco-discord> <yreg> @binduwavell acme:someField:"the flow" gives back also a positive for "the magic flow", and =acme:someField:"*the flow*" gives back a positive for "the flower" I only managed to get my story accepted by combining both ...
2020-02-21 14:29:25 GMT <alfresco-discord> <binduwavell> What about specifying proximity as in my example?
2020-02-21 14:31:51 GMT <alfresco-discord> <yreg> using tilde ~ is for fuzzy search AFAIK not for proximity and it takes a real parameter between 0 and 1 to indicate how exact the search should be... term~1 would then be the same as just term, and term~0.8 would match anything with 80% similarity to term ...
2020-02-21 14:33:28 GMT <alfresco-discord> <yreg> as for the real proximity search, if I remember right from the old wiki, there was something about using *(3) between two terms to indicate the terms should be at most (or was it least ?) three terms away from one an other
2020-02-21 14:33:35 GMT <alfresco-discord> <yreg> but I don't see how that would work
2020-02-21 14:34:22 GMT <alfresco-discord> <yreg> I remember also something to match on end/beginning of the field, but nothing to indicatio beginning/end of the term when combined with asterisks 😉
2020-02-21 14:34:54 GMT <alfresco-discord> <yreg> Any how, my PO says now that it is good enough, I am not going to dig deeper
2020-02-21 14:37:54 GMT <alfresco-discord> <yreg> and by that I mean the result I got with : (acme:someField:"the flow" AND =acme:someField:"*the flow*")
2020-02-21 15:48:16 GMT <alfresco-discord> <binduwavell> Last I checked, searching with * at the beginning of a term will blow up your Solr memory usage because of how indexes are managed.
2020-02-21 15:49:27 GMT <alfresco-discord> <binduwavell> https://lucene.apache.org/core/2_9_4/queryparsersyntax.html#Proximity%20Searches
2020-02-21 15:49:28 GMT <alfbot> Title:Apache Lucene - Query Parser Syntax (at lucene.apache.org)
2020-02-21 15:50:53 GMT <alfresco-discord> <yreg> That's a reference for 2.9.4, we are on 6.x
2020-02-21 15:52:03 GMT <alfresco-discord> <yreg> anyhow, if users start complaining about perf or solr memory becomes an issue (so far we don't have production, and the total size of our heaviest environment is around 300m from ~5k nodes)
2020-02-21 15:56:06 GMT <alfresco-discord> <binduwavell> Here is a nice trick for you @cm:name:"the.flow"
2020-02-21 15:56:30 GMT <alfresco-discord> <binduwavell> . is punctuation and is treated kind of like space but also not like space...
2020-02-21 15:58:10 GMT <alfresco-discord> <binduwavell> https://lucene.apache.org/solr/guide/6_6/the-standard-query-parser.html#TheStandardQueryParser-ProximitySearches
2020-02-21 15:58:11 GMT <alfbot> Title:The Standard Query Parser | Apache Solr Reference Guide 6.6 (at lucene.apache.org)
2020-02-21 15:58:29 GMT <alfresco-discord> <binduwavell> The proximity thing does not do what you want but I think the syntax I suggested was what I had remembered at least 🙂
2020-02-21 16:16:42 GMT <alfresco-discord> <yreg> interesting, it seems alfresco and solr document stuff differently now : https://docs.alfresco.com/search-enterprise/concepts/searchsyntax-fuzzy.html
2020-02-21 16:16:43 GMT <alfbot> Title:Search for fuzzy matching | Alfresco Documentation (at docs.alfresco.com)
2020-02-21 16:17:21 GMT <alfresco-discord> <yreg> Thanks, will give the . and the @ a try if ever performance issues have arised
2020-02-21 16:24:21 GMT <alfresco-discord> <yreg> @binduwavell it seems that the ~ behaves differently on the presence of quotes, the Alfresco documentation is quite old and dusty there, when used without quotes the tilde indicates a fuzzy search !!
2020-02-21 16:24:42 GMT <alfresco-discord> <yreg> (scrolled a bit up in the page you linked)
2020-02-21 18:38:28 GMT <alfresco-discord> <jpotts> Suppose I have my own custom bean that I have annotated with @ManagedAttribute and @ManagedOperation so that I can do get/set calls on it successfully with a tool like JMXTerm. Should I expect to be able to create a custom Admin Console page without too much trouble that can also make those calls?
2020-02-21 18:39:30 GMT <alfresco-discord> <jpotts> Or put another way, is there a difference between creating an admin console page that works with Alfresco's JMX beans versus one that works with my own custom JMX beans?
2020-02-21 22:20:50 GMT <alfresco-discord> <jpotts> Turns out for read-only attributes it just works. For read-write attributes I'm getting a CSRF error when clicking save, but I'll bet that can be fixed by adding something to my freemarker template. I'll go peek at OOTB Support Tools or some of the out-of-the-box examples to see how they get around that.
2020-02-21 22:22:04 GMT <AFaust> jpotts: It is not a matter of getting around CSRF - it is a matter of configuring Alfresco correctly.
2020-02-21 22:22:55 GMT <AFaust> You need to set CSRF filter referer / origin via alfresco-global.properties in the newer Alfresco versions (https://github.com/Alfresco/alfresco-repository/blob/master/src/main/resources/alfresco/repository.properties#L1283)
2020-02-21 22:22:56 GMT <alfbot> Title:alfresco-repository/repository.properties at master · Alfresco/alfresco-repository · GitHub (at github.com)
2020-02-21 22:23:18 GMT <AFaust> Or disable CSRF...
2020-02-21 22:28:41 GMT <AFaust> If you use the default Alfresco FTL directives for generating fields / forms for JMX, you should already be set up for correct handling. The only time you may need to handle CSRF yourself is when you perform a custom POST from client side JS, but so far I have not encountered this myself - even in OOTBee Support Tools
2020-02-21 22:32:23 GMT <alfresco-discord> <jpotts> afaust: This is an SDK 3.0.1 project. It's not configured to handle CSRF correctly? I'm shocked.
2020-02-21 22:33:23 GMT <AFaust> I can imagine. I mean, after all, it is a perfect product in every other way...
2020-02-21 22:34:21 GMT <alfresco-discord> <jpotts> 🙂
2020-02-21 22:35:55 GMT * AFaust goes back to duct-taping Keycloak authentication with Public API
The other logs are at http://esplins.org/hash_alfresco