Daily Log for #alfresco IRC Channel

Alfresco discussion and collaboration. Stick around a few hours after asking a question.

Official support for Enterprise subscribers: support.alfresco.com.

Joining the Channel:

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.

Getting Help

More help is available in this list of resources.

Daily Log for #alfresco

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:40 GMT <alfresco-discord> <LuisColorado> I downloaded the javascript console from maven central, and tried to install on Alfresco 5.2.3, but now it can't start. I also tried a version that I built long time ago.

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:16 GMT <alfbot> Title:GitHub - share-extras/js-console: Administration Console component for Alfresco Share, that enables the execution of arbitrary JavaScript code against the repository (at github.com)

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:29:49 GMT <alfbot> Title:GitHub - share-extras/js-console: Administration Console component for Alfresco Share, that enables the execution of arbitrary JavaScript code against the repository (at github.com)

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 😃

End of Daily Log

The other logs are at http://esplins.org/hash_alfresco