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.
2019-04-03 05:23:58 GMT <alfresco-discord> <digcat> hi @Mark-Unofficial thanks @angel.borroy
2019-04-03 05:24:06 GMT <alfresco-discord> <digcat> be back on in a while
2019-04-03 07:08:43 GMT <alfresco-discord> <dgradecak> morning all, any idea why the DELETE_CHILDREN permission does not allow a contributor to delete documents created by others? What would be the work around?
2019-04-03 07:10:27 GMT <alfresco-discord> <dgradecak> although I did not check if it just share that is not showing the delete, maybe the permissions per se works
2019-04-03 10:34:27 GMT <AFaust> dgradecak: DELETE_CHILDREN is only the permission to delete child associations, but you actually need the DELETE permission on the child node in order to be allowed to delete that.
2019-04-03 11:07:34 GMT <alfresco-discord> <dgradecak> AFaust: sure, which than requires a rule/behavior to set that delete permission if on the parent the user does not have the delete permission. Not quite convincing but that is how it is
2019-04-03 11:08:30 GMT <angelborroy> AFaust, I’m starting with that Cross Locale thing
2019-04-03 11:08:31 GMT <angelborroy> https://github.com/aborroy/search-services-cross-locale
2019-04-03 11:08:32 GMT <alfbot> Title:GitHub - aborroy/search-services-cross-locale: Alfresco Search Services deployment for Cross Locale users (at github.com)
2019-04-03 11:08:34 GMT <alfresco-discord> <yreg> does it mean that you need to have delete children permission on all parents in order to delete a node ?
2019-04-03 11:08:49 GMT <alfresco-discord> <dgradecak> that is that yreg
2019-04-03 11:08:49 GMT <angelborroy> We are going to create a ticket to make Search Service Docker Image configurable
2019-04-03 11:09:14 GMT <angelborroy> What do you thing?
2019-04-03 11:09:17 GMT <angelborroy> thing > think
2019-04-03 11:09:37 GMT <angelborroy> We are also fixing documentation
2019-04-03 11:09:37 GMT <angelborroy> https://docs.alfresco.com/search-community/tasks/solr6-install-withoutSSL.html
2019-04-03 11:09:39 GMT <alfbot> Title:Installing and configuring Search Services without SSL | Alfresco Documentation (at docs.alfresco.com)
2019-04-03 11:09:48 GMT <angelborroy> To state step 3 as REQUIRED for cross locale
2019-04-03 11:10:23 GMT <angelborroy> I don’t know if we can take any other action
2019-04-03 11:10:26 GMT <angelborroy> But glad to hear you
2019-04-03 11:19:01 GMT <AFaust> angelborroy: Did you have to create a new GitHub account just for your Alfresco work? Why couldn't you just continue to use your old / own account? Is that company policy?
2019-04-03 11:20:23 GMT <AFaust> yreg / dgradecak: As far as I know, having DELETE on just the child(ren) would be enough. If you delete a node, only that permission is checked. DELETE_CHILDREN is - AFAIK - only relevant for removing specific child associations via the NodeService API without directly deleting the child (which may be indirectly deleted if you delete the primary child associatoin)
2019-04-03 11:22:06 GMT <AFaust> angelborroy: Ok, so I see you are following what Harry Peek suggested when he first contacted me about my complaints / rants on Twitter...
2019-04-03 11:23:45 GMT <AFaust> I am not a fan of the"autoDetectQueryLocales" approach really, as that would - as far as I understand - only deal with the expansion / tokenisation of query terms to different locales, but which would then potentially not match anything because the actual content was not indexed according to the tokenisation rules of these locales
2019-04-03 11:27:01 GMT <AFaust> I still feel that index / query behaviour concerning locales should be something that can (partially) be configured in the data model, most specifically to allow for d:text / d:content to specify "locale-specific" or "not locale-specific" tokenisation. An extreme amount of d:text properties are likely some IDs or other technical values which do not require locale-specific tokenisation (but may require tokenisation in general to
2019-04-03 11:27:01 GMT <AFaust> support queries for fragments)
2019-04-03 11:30:24 GMT <AFaust> This could be similar to the tokenised config option wihich has a value of "true", "false" and "both". The option "both" would cause a non-localised (well, "English default") index field to be created in addition to the locale-specific ones as a fallback so that matches may be found if there are no locale-specific index fields for the locale of the current user who is executing a query.
2019-04-03 11:32:18 GMT <AFaust> An option for enablement of "cross-locale" indexation could / should also be a part of the data model configuration, because it too may be intrinsically tied to the semantics of a specific property.
2019-04-03 11:32:33 GMT <alfresco-discord> <dgradecak> Afaust: having delete on just the node is ok, but it requires rule/behavior to be executed on each content in a folder etc ... to add that as I said previously. Otherwise if you want it via the inherit permissions, than you need to have the delete on the parent
2019-04-03 11:33:26 GMT <AFaust> Ah, yes, just for the "ensure the permission is set without having it on the parent part". Somehow I did not understand that before...
2019-04-03 11:35:08 GMT <AFaust> angelborroy: On SOLR there should be a general configuration for indexing that determines the set of locales for which a cross-locale property / datatype will be indexed (should probably be the same used for the autoDetectQueryLocales in "afts" query parser).
2019-04-03 11:37:28 GMT <AFaust> angelborroy: And of course to support legacy / broken models / use cases, it would be necessary to be able to default and/or selectively override the cross-locale / locale-specific tokenisation config from the data model on a per-property / data type basis.
2019-04-03 11:38:22 GMT <AFaust> But yeah, as long as Alfresco does not take multi-locale deployment scenarios seriously and assigns proper resources, the improvement of documentation is about the only thing that can be reasonably expected.
2019-04-03 11:39:00 GMT <angelborroy> I’m using the Alfresco account for GitHub because this project is part of an Alfresco Presentation
2019-04-03 11:39:10 GMT <AFaust> (and some very naive / simple configuration options in Docker deployments)
2019-04-03 11:39:26 GMT <angelborroy> I’ll be talking about this (and some other Search related things) at Seville Alfresco Meetup
2019-04-03 11:39:54 GMT <angelborroy> In the short term, documentation + Docker Image configuration
2019-04-03 11:40:13 GMT <angelborroy> Any other thing we could provide?
2019-04-03 11:40:44 GMT <AFaust> You mean short of the real solution I outlined? I don't see any other non-improvement improvements...
2019-04-03 11:41:12 GMT <angelborroy> I’m looking at this
2019-04-03 11:41:13 GMT <angelborroy> https://lucene.apache.org/solr/guide/6_6/detecting-languages-during-indexing.html
2019-04-03 11:41:14 GMT <alfbot> Title:Detecting Languages During Indexing | Apache Solr Reference Guide 6.6 (at lucene.apache.org)
2019-04-03 11:41:49 GMT <angelborroy> As we are moving the Content Tracker to that microservice, fashion, probably I could include some language autodetection for indexing
2019-04-03 11:43:00 GMT <AFaust> I don't think that would work becauses Alfresco SOLR / Search Services is already dynamically indexing to specific fields with specific locale-prefixed values, so any handling of an update processor is going to be applied too late
2019-04-03 11:43:42 GMT <angelborroy> Yeah, I was thinking only for Content
2019-04-03 11:45:08 GMT <AFaust> And how would you auto-detect those "non-locale" ID / technical values.
2019-04-03 11:45:27 GMT <angelborroy> Good question
2019-04-03 11:45:33 GMT <angelborroy> I don’t know (by now)
2019-04-03 11:45:44 GMT <AFaust> The only thing where the update processor would be appropriate is for the actual full text content of files (d:content)
2019-04-03 11:45:55 GMT <angelborroy> I meant that, yes
2019-04-03 11:46:10 GMT <angelborroy> And the other can be solved by configuration
2019-04-03 11:46:15 GMT <AFaust> I honestly care less about d:content than about all the actual business metadata in d:text
2019-04-03 11:46:24 GMT <angelborroy> Declaring the fields as "technical"
2019-04-03 11:46:44 GMT <AFaust> Yes - as I outlined by being able to do some configuration in the data model.
2019-04-03 11:47:04 GMT <angelborroy> But for general “d:text”, it’s not that easy
2019-04-03 11:47:21 GMT <angelborroy> Probably we can try also auto-detection and falling back to client locale
2019-04-03 11:47:23 GMT <AFaust> That's why the data model is the best place for devs to define that on a per-property basis
2019-04-03 11:47:56 GMT <AFaust> The admin of the SOLR system should not have to add hundreds of config lines to shared.properties to config that there...
2019-04-03 11:48:07 GMT <angelborroy> :)
2019-04-03 11:48:18 GMT <AFaust> That would not scale, especially with 3rd party addons
2019-04-03 11:49:10 GMT <angelborroy> Why?
2019-04-03 11:51:08 GMT <AFaust> a) every addon dev would be forced to provide even more instructions for manual installation of the module, because there is no "extension feature" for SOLR shared.properties, b) every time someone added a module to the build project, the shared.properties would have to be adapted - since SOLR is typically not required to be (re-)built in customer projects, that would either necessitate SOLR to be included in CI/CD pipelines (and
2019-04-03 11:51:08 GMT <AFaust> config source control) or admin to modify config in the target environment(s)
2019-04-03 11:51:27 GMT <angelborroy> ah, ok
2019-04-03 11:51:36 GMT <angelborroy> I was thinking on the language auto-detection
2019-04-03 11:51:44 GMT <angelborroy> yes, using the Content Model is the right approach
2019-04-03 11:51:52 GMT <AFaust> Since the SOLR config is simple key-value, people would have to take care to avoid key-clashes, so devs couldn't even provide default configs that can just be copy&pasted by users / customers...
2019-04-03 11:52:49 GMT <AFaust> And the language auto-detection would not scale / work on d:text since there would typically be too little context / clear cut data to be able to correctly identify the locale.
2019-04-03 11:53:01 GMT <angelborroy> Right
2019-04-03 11:53:15 GMT <AFaust> It would be just as (in)precise as those upload filters on various content sharing services are going to be in about 2-3 years.
2019-04-03 11:54:50 GMT <angelborroy> By now, I have no better ideas
2019-04-03 11:55:04 GMT <angelborroy> This is interesting reading
2019-04-03 11:55:05 GMT <angelborroy> http://blog.mikemccandless.com/2011/10/accuracy-and-performance-of-googles.html
2019-04-03 11:55:06 GMT <alfbot> Title:Changing Bits: Accuracy and performance of Google's Compact Language Detector (at blog.mikemccandless.com)
2019-04-03 11:55:47 GMT <angelborroy> probably using some NLP Library, confidence can be improved
2019-04-03 12:02:00 GMT <AFaust> Just don't fall for the fallacy of the "magic technology" to help you solve your issues in seemingly less effort, just to then realise there are so many (potentially obscure but still relevant) exceptions that the much simpler option of explicit configurability would have perfectly covered.
2019-04-03 12:03:22 GMT <angelborroy> Agree
2019-04-03 12:03:28 GMT <angelborroy> Thanks for your feedback
2019-04-03 12:03:39 GMT <angelborroy> Any other opinion is welcomed, of course
2019-04-03 12:05:04 GMT <AFaust> I doubt I will come up with any other, as the above already represents what I though about for the last ~2 years.
2019-04-03 15:26:56 GMT <alfresco-discord> <LuisColorado> (but it crashed my Alfresco 5.2.3 as well)
2019-04-03 15:27:31 GMT <angelborroy> It’s working on 5.2.3
2019-04-03 15:27:33 GMT <angelborroy> for sure
2019-04-03 15:27:38 GMT <angelborroy> what version did you downloaded?
2019-04-03 15:28:25 GMT <alfresco-discord> <LuisColorado> https://mvnrepository.com/artifact/de.fmaul
2019-04-03 15:28:26 GMT <alfbot> Title:Maven Repository: de.fmaul (at mvnrepository.com)
2019-04-03 15:28:49 GMT <alfresco-discord> <LuisColorado> By the way, Hi!
2019-04-03 15:28:58 GMT <angelborroy> Hi
2019-04-03 15:29:14 GMT <angelborroy> I use to compile from source code
2019-04-03 15:29:15 GMT <angelborroy> https://github.com/share-extras/js-console
2019-04-03 15:29:35 GMT <alfresco-discord> <LuisColorado> I did that too, but I probably compiled with Alfresco 5.1.
2019-04-03 15:29:37 GMT <angelborroy> If not, you have to include Maven dependency as overly
2019-04-03 15:29:48 GMT <angelborroy> https://github.com/share-extras/js-console#usage
2019-04-03 15:30:14 GMT <angelborroy> you can just type “mvn clean package” and it’s don
2019-04-03 15:30:19 GMT <angelborroy> don > done
2019-04-03 15:30:20 GMT <angelborroy> it works
2019-04-03 15:30:34 GMT <alfresco-discord> <LuisColorado> I wanted to skip that step, but I'll try it. Thanks, Angel!
2019-04-03 15:31:11 GMT <angelborroy> You can skip the step, but then you have to create that overlay for the AMP
2019-04-03 15:32:14 GMT <alfresco-discord> <LuisColorado> I mean, I was lazy and I didn't want to build it, but I guess I'll have to do it anyway 😃
The other logs are at http://esplins.org/hash_alfresco