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

2017-12-01 07:11:21 GMT <twen> hello

2017-12-01 07:12:19 GMT <MorganP> Hello

2017-12-01 07:19:37 GMT <bhuvana_> hi

2017-12-01 07:21:50 GMT <bhuvana_> hi all

2017-12-01 07:28:49 GMT <bhuvana_> I am unable to get bpm-package children from java class using workflow java class listener

2017-12-01 07:30:35 GMT <bhuvana_> https://pastebin.com/W9nWu48c

2017-12-01 07:30:36 GMT <alfbot> Title: NodeService nodeService=new NodeServiceImpl(); System.out.println("HI Del - Pastebin.com (at pastebin.com)

2017-12-01 07:31:29 GMT <bhuvana_> this is my code at pastebin

2017-12-01 07:31:54 GMT <bhuvana_> i am getting nullpointer exception for nodeService

2017-12-01 07:35:08 GMT <bhuvana_> Hi alfbot

2017-12-01 07:35:32 GMT <bhuvana_> how can i get the nodeservice object in my current class

2017-12-01 07:58:34 GMT <yreg> bhuvana_, you should use spring to wire node service instead of instantiating it like that

2017-12-01 08:34:57 GMT <bhuvana_> without injecting i need nodeservice

2017-12-01 08:35:08 GMT <bhuvana_> is there any way

2017-12-01 08:52:12 GMT <yreg> nope, AFAIK

2017-12-01 09:20:37 GMT <yreg> Guys, what would happen if an LDAP synchronized group get's renamed on LDAP, does the alfresco matching group get renamed as well, or is it an entirely new group (hence old ACL will be no longer effective)?

2017-12-01 09:22:09 GMT <angelborroy> I don’t know but probably it will be a new Gropu

2017-12-01 09:24:22 GMT <angelborroy> yreg I would said it’s eliminated: https://github.com/Alfresco/community-edition-old/blob/master/projects/repository/source/java/org/alfresco/repo/security/sync/ChainingUserRegistrySynchronizer.java#L1058

2017-12-01 09:24:23 GMT <alfbot> Title: community-edition-old/ChainingUserRegistrySynchronizer.java at master · Alfresco/community-edition-old · GitHub (at github.com)

2017-12-01 09:26:00 GMT <Tichodroma> yreg: the group is deleted and a new group is create :(

2017-12-01 09:27:21 GMT <MorganP> Same that for the users

2017-12-01 09:27:31 GMT <MorganP> if you change the id, it's another user

2017-12-01 09:28:19 GMT <Tichodroma> we once patched this code so that a stable LDAP property like SAMAccountName is used to identify the user. So even he is renamed in LDAP, he will be kept in Alfresco.

2017-12-01 09:30:05 GMT <Tichodroma> sadly we were not able to patch the same for groups because in Alfresco a group does not have properties. So name == ID

2017-12-01 09:36:34 GMT <yreg> thanks guys, this brings me to my next question

2017-12-01 09:39:23 GMT <yreg> If the group tree from LDAP which is synchronized to alfresco gets some major changes : Groups renaming, new groups in the architecture to consolidate some groups / split them ... and knowing that the affectedgroups (by the rename) are not actually used directly for assigning permissions, would the changes to Alfresco Group structure result in Solr re-indexing parts of the ACL/NODE trees ?

2017-12-01 10:03:09 GMT *** angelborroy_ is now known as angelborroy

2017-12-01 10:15:33 GMT <yreg> fcorti, FYI, many links from the old Alfresco University site are now broken instead of redirecting to the new content

2017-12-01 10:15:49 GMT <yreg> you might want to relay this message internally to concerned parties

2017-12-01 10:15:56 GMT <fcorti> hi yreg... thank you for the heads up

2017-12-01 10:16:01 GMT <fcorti> yes, will do it for sure

2017-12-01 10:16:12 GMT <fcorti> do you have at least an example?

2017-12-01 10:16:35 GMT <yreg> https://www.alfresco.com/alfresco-university

2017-12-01 10:16:36 GMT <alfbot> Title: Alfresco University | Alfresco (at www.alfresco.com)

2017-12-01 10:16:52 GMT <yreg> links to all certifications do not seem to work

2017-12-01 10:17:01 GMT <yreg> same for localized pages

2017-12-01 10:17:05 GMT <yreg> http://university.alfresco.com/ACE

2017-12-01 10:17:30 GMT <yreg> same for exam blueprints

2017-12-01 10:17:34 GMT <yreg> https://university.alfresco.com/static/documents/Alfresco%20Certified%20Engineer%20Exam%20Blueprint_v4_3%20%281%29.pdf

2017-12-01 10:17:50 GMT <fcorti> Ah...

2017-12-01 10:17:53 GMT <fcorti> yes, definitely

2017-12-01 10:18:07 GMT <fcorti> will tell them

2017-12-01 10:18:11 GMT <fcorti> Thanks again

2017-12-01 10:18:22 GMT <yreg> :)

2017-12-01 10:20:51 GMT <fcorti> Done!

2017-12-01 10:53:50 GMT <yreg> I am going to rephrase my question : When I assign an ACL on node Node1 with a permission for group GROUP_1.1, I understand that every ACE from the ACL will have its own document in SOLR, and those documents will be associated with a special (multivalued) field in the Node1 document in solr. My Question is does the ACE document in solr only include the Authority in question or some parents/children as well ?

2017-12-01 11:01:03 GMT <douglascrp> guys, quick question about javascript console

2017-12-01 11:01:10 GMT <douglascrp> I have this project https://github.com/share-extras/js-console

2017-12-01 11:01:11 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)

2017-12-01 11:01:23 GMT <douglascrp> but the artifacts ids are different from what I have in a project

2017-12-01 11:02:01 GMT <douglascrp> this one is <groupId>de.fmaul</groupId><artifactId>javascript-console</artifactId>

2017-12-01 11:02:51 GMT <douglascrp> but in my project, the dependency is <groupId>org.sharextras</groupId><artifactId>javascript-console-repo</artifactId>

2017-12-01 11:03:00 GMT <douglascrp> the problem is... I can not find that project

2017-12-01 11:03:06 GMT <douglascrp> not sure if it was available and got removed

2017-12-01 11:03:10 GMT <yreg> douglascrp, your project relies on a really old version

2017-12-01 11:03:20 GMT <douglascrp> ah, that is what I thought

2017-12-01 11:03:37 GMT <yreg> I bet that florian renamed the package for putting the thing on maven central two years ago

2017-12-01 11:03:41 GMT <douglascrp> because this laptop has a new ssd, and I do not have the projects in my local maven repository

2017-12-01 11:03:47 GMT <yreg> during BeeCon edition 1

2017-12-01 11:04:07 GMT <douglascrp> yreg, tks for confirming my assumption

2017-12-01 11:04:10 GMT <yreg> AKA BeeCon2016

2017-12-01 11:04:17 GMT <yreg> urw

2017-12-01 11:04:23 GMT <yreg> AFaust, any idea ?

2017-12-01 11:05:40 GMT <AFaust> de.fmaul was used to put it in Maven Central, correct. You need to have a namespace that you own to publish artifacts

2017-12-01 11:06:03 GMT <yreg> AFaust, I was referring to my Solr Question :P

2017-12-01 11:06:20 GMT <AFaust> Oh, sorry. Just saw your mention of me and went through the last questions...

2017-12-01 11:07:20 GMT <AFaust> Your understanding of ACLs in SOLR is still based on SOLR 1, where ACL and actual nodes had distinct index documents.

2017-12-01 11:07:34 GMT <AFaust> It is not the case in SOLR 4

2017-12-01 11:08:59 GMT <AFaust> The index documentin SOLR 4 contains the list of READERS and DENIED based on the node ACL (i.e. only those authorities that have specific permissions assigned)

2017-12-01 11:09:50 GMT <AFaust> During query, Alfresco sends all authorities of the current user to SOLR and builds a filter query with those against the READERS / DENIED fields (though, it uses some more abstract fields to add several layers of caching)

2017-12-01 11:14:04 GMT <AFaust> Checks will actually be run against the AUTHORITY / DENIED or AUTHSET / DENYSET fields (depending on how authorities are provided)

2017-12-01 11:14:21 GMT <apus> hi, if i have an older alfresco version 5.1, would it be a good idea to upgrade to the latest 5.2 GA release now or wait for 6.0 GA or whatever follows?

2017-12-01 11:14:41 GMT <AFaust> AUTHORITY includes both READERS and OWNER in its checks...

2017-12-01 12:07:46 GMT <yreg> AFaust, so only directly attributed authorities are actually attached to the node document in solr (actually the document as if I understand this right, there should be no documents other than node documents)

2017-12-01 12:08:22 GMT <AFaust> Right - and almost right. There are also TXN documents...

2017-12-01 12:10:28 GMT <yreg> I am a bit confused, let mech check the solr summary page to try to match these infos together with what's in there

2017-12-01 12:16:51 GMT <yreg> Alright thanks a ton !, everything just makes sense now

2017-12-01 12:47:59 GMT *** angelborroy_ is now known as angelborroy

2017-12-01 12:57:32 GMT <yreg> ~flushlog

2017-12-01 12:57:32 GMT <alfbot> yreg: Woooosh, your log has been flushed...

2017-12-01 13:18:12 GMT <yreg> AFaust, I am having second thoughts about what you provided as information

2017-12-01 13:18:42 GMT * AFaust puts on a helmet and awaits a dressing down...

2017-12-01 13:19:00 GMT <yreg> I just accessed a solr from a dev machine, pointed to the Schema Browser for core alfresco and loaded term infor for special field DOC_TYPE

2017-12-01 13:19:25 GMT <yreg> and guess what, there is almost as many ACL documents as there is nodes

2017-12-01 13:20:21 GMT <yreg> there is actually Tx, Node, UnindexedNode, Acl, AclTx, State and ErrorNode

2017-12-01 13:24:56 GMT <yreg> I wonder if there is a way to check visualize unstored fields

2017-12-01 13:52:20 GMT <AFaust> yreg: I don't know about your particular ACL management scheme for that system. Yes, ACL change sets etc. are indexed separately, but the ACLs for a particular node are stored on the node document. E.g. in my customer system (5.2.1 / SOLR4) I have ~780.000 node documents but only ~40.000 ACL nodes etc. - As far as I am aware, the ACL-related documents are only used to track the already processed ACLs and support any cascading updates without requiring

2017-12-01 13:52:20 GMT <AFaust> nodes to be touched on the DB side (which would normally cause them to be re-indexed)

2017-12-01 13:53:26 GMT <AFaust> "touched" => associated with a new txn ID, apart from the ACL change set ID

2017-12-01 13:55:16 GMT <AFaust> But the SOLR internals can always be somewhat confusing, so if I am wrong in that regards, I would not be too embarrassed (compared to any of the trivial Repo-tier stuff)

2017-12-01 14:26:26 GMT <yreg> I might have put it in a wrong format, but to be clear I just want to make sure I give my client the right advice... especially given the fact they have more ACL/ACEs than they have nodes + they have few dozen thousands authorities almost used everywhere

2017-12-01 14:26:55 GMT <yreg> I am not questioning your knowledge, nor I am in place to do so :P

2017-12-01 14:30:25 GMT <AFaust> One thing I am not sure of with regards to Alfresco is the question "Are ACLs deleted from the system when the last node using them is deleted?" i.e. are ACLs just an ever growing pile of data...

2017-12-01 14:31:11 GMT <AFaust> Too bad that today is quite a busy day at the customer with support cases, or I would investigate your question more thoroughly...

2017-12-01 14:35:01 GMT <AFaust> ~later tell angelborroy: In our discussion with the ASS team we talked about how SOLR4 was doing cross-locale searches / matches. Strangely, I am having support calls on an Enterprise 5.2.1 customer with SOLR4 where users cannot be found due to locale differences...

2017-12-01 14:35:01 GMT <alfbot> AFaust: The operation succeeded.

2017-12-01 14:36:00 GMT <yreg> AFaust, that's a shame!

2017-12-01 14:36:04 GMT <AFaust> ~later tell angelborroy: I am a bit confused about that at the moment. I'll check if - by any chance - some of the SOLR 6 stuff has been merged into SOLR 4

2017-12-01 14:36:04 GMT <alfbot> AFaust: The operation succeeded.

2017-12-01 14:36:54 GMT <yreg> IT's never a good idea to try to optimize stuff upfront, the cross locale restriction thing should be an opt in basis IMHO

2017-12-01 14:37:06 GMT <yreg> especially since it is considered as a breaking change

2017-12-01 14:38:01 GMT <AFaust> Based on the discussions Angel and I had with them, you may expect the default to switch back to something more reasonable in a future version. And we also suggested a slew of additional configuration options to be able to fine-tune it.

2017-12-01 14:38:26 GMT <AFaust> I.e. one of my suggestions was the ability to configure that certain properties will always be indexed without any specific locale (think any technical identifiers)

2017-12-01 14:39:00 GMT <yreg> I caught up on that a while back but still it didn't seem (at the time) it is handled the intuitive way

2017-12-01 14:39:11 GMT <AFaust> At least I had the feeling that we were able to make a pretty decent case for the "SOLR 6 as it is now is broken for us" standpoint

2017-12-01 14:39:40 GMT <alfbot> angelborroy: Sent 4 minutes ago: <AFaust> In our discussion with the ASS team we talked about how SOLR4 was doing cross-locale searches / matches. Strangely, I am having support calls on an Enterprise 5.2.1 customer with SOLR4 where users cannot be found due to locale differences...

2017-12-01 14:39:41 GMT <alfbot> angelborroy: Sent 3 minutes ago: <AFaust> I am a bit confused about that at the moment. I'll check if - by any chance - some of the SOLR 6 stuff has been merged into SOLR 4

2017-12-01 14:40:08 GMT <yreg> I think they are over doing the performance optemization stuff as a preparation for Insight Engine & APS indexing tasks and wfInstances

2017-12-01 14:40:31 GMT <yreg> You did make a really strong case there

2017-12-01 14:40:47 GMT <angelborroy> AFaust Yep I’ve received the same input from a client with SOLR4

2017-12-01 14:40:54 GMT <AFaust> Ah - good to know

2017-12-01 14:41:00 GMT <angelborroy> AFaust I’m going to investigate the thing next Monday

2017-12-01 14:41:59 GMT <AFaust> I am doing this right now, because sh*t is hitting the fan due to this and a couple other issues after migration to 5.2.1 (of course, the test was done mostly by the German project team, which did not realise these kinds of issues with their limited, German test data)

2017-12-01 14:42:28 GMT <AFaust> ....and I am the only one here at the customer on a Friday.

2017-12-01 14:50:22 GMT <yreg> Hi kgastaldo !

2017-12-01 14:50:34 GMT <yreg> What good news do you bring in today ?

2017-12-01 14:51:01 GMT <yreg> (usually you only show up on IRC when you have to announce something <grin>)

2017-12-01 14:51:18 GMT <yreg> s/have/want/

2017-12-01 14:52:33 GMT <kgastaldo> Hello hello!

2017-12-01 14:52:42 GMT <kgastaldo> No new news really - DevCon still free. 100 registered so far.

2017-12-01 14:52:58 GMT <kgastaldo> Oh! But fingers crossed we have the schedule could go up today

2017-12-01 14:53:12 GMT <kgastaldo> we could have*

2017-12-01 14:54:05 GMT <kgastaldo> We still have a few confirmations trickling in, but I think the bulk of the full/extended sessions have confirmed.

2017-12-01 15:17:11 GMT <AFaust> ~later tell angelborroy: Found the cause of the issue. There is a shared.properties that is shipped with SOLR 4, which lists alfresco.identifier.property settings. The problem is: the default behaviour (d:text, d:content and d:mltext do cross-locale searches) is not initialised if the shared.properties has at least one property in it...

2017-12-01 15:17:11 GMT <alfbot> AFaust: The operation succeeded.

2017-12-01 15:18:29 GMT <AFaust> In 5.1 SOLR 4 only shipped with a shared.properties.sample, and at some point that got switched to an active file by default

2017-12-01 15:19:09 GMT <AFaust> ~later tell angelborroy: In 5.1 SOLR 4 only shipped with a shared.properties.sample, and at some point that got switched to an active file by default

2017-12-01 15:19:09 GMT <alfbot> AFaust: The operation succeeded.

2017-12-01 15:19:36 GMT <AFaust> ~later tell angelborroy: As far as I can see, Community 5.2 also shipped only with a shared.properties.sample...

2017-12-01 15:19:36 GMT <alfbot> AFaust: The operation succeeded.

2017-12-01 15:23:31 GMT <AFaust> ~later tell angelborroy: Confirmed - latest SOLR 4 Community (5.2.g) only ships shared.properties.sample

2017-12-01 15:23:31 GMT <alfbot> AFaust: The operation succeeded.

2017-12-01 15:51:20 GMT <alfbot> angelborroy: Sent 34 minutes ago: <AFaust> Found the cause of the issue. There is a shared.properties that is shipped with SOLR 4, which lists alfresco.identifier.property settings. The problem is: the default behaviour (d:text, d:content and d:mltext do cross-locale searches) is not initialised if the shared.properties has at least one property in it...

2017-12-01 15:51:21 GMT <alfbot> angelborroy: Sent 32 minutes ago: <AFaust> In 5.1 SOLR 4 only shipped with a shared.properties.sample, and at some point that got switched to an active file by default

2017-12-01 15:51:22 GMT <alfbot> angelborroy: Sent 31 minutes ago: <AFaust> As far as I can see, Community 5.2 also shipped only with a shared.properties.sample...

2017-12-01 15:51:23 GMT <alfbot> angelborroy: Sent 27 minutes ago: <AFaust> Confirmed - latest SOLR 4 Community (5.2.g) only ships shared.properties.sample

2017-12-01 15:51:59 GMT <angelborroy> AFaust Wow, thanks for the information

2017-12-01 15:52:08 GMT <angelborroy> I’ll tell you next week what I see in 5.1

2017-12-01 15:56:15 GMT <kgastaldo> Looks like schedule won't be up today (styling) - giving a day to fix things Monday. Tuesday should be good!

2017-12-01 17:04:30 GMT <cDavid> Hi, is there a way to preserve the uuid of a node during the bulk-filesystem-import?

2017-12-01 17:18:01 GMT <yreg> cDavid, Not sure about that

2017-12-01 17:18:24 GMT <yreg> but what you can do is to store the extra UUID in a separate metadata

2017-12-01 17:18:54 GMT <yreg> and setup a redirect webscript with that as parameter, doing a TMQ and redirecting to the right document URL !

2017-12-01 17:48:46 GMT <douglascrp> has anyone faced the following error before?

2017-12-01 17:48:47 GMT <douglascrp> Caused by: net.sf.jooreports.openoffice.connection.OpenOfficeException: conversion failed; com.sun.star.lang.IllegalArgumentException: Unsupported URL <file:///opt/alfresco/tomcat/temp/Alfresco/DEMISS%C3%95ES%20JUNHO.XLSX-OpenOfficeContentTransformer-OpenOfficeContentTransformer-1512150490279/DEMISS%C3%95ES%20JUNHO.XLSX>: "type detection failed"

2017-12-01 17:49:00 GMT <douglascrp> in this case, the detected mime/type is worng

2017-12-01 17:49:02 GMT <douglascrp> wrong

2017-12-01 17:49:21 GMT <douglascrp> this is a xlsx file, but when the error happens, it is set as xls

2017-12-01 17:49:52 GMT <douglascrp> if I change remove the special character Õ from the name, the error stops, but even with that, the mimetype is wrong

2017-12-01 17:54:18 GMT <douglascrp> AFaust is this related with your problem? http://douglascrp.blogspot.com.br/2017/11/how-to-make-search-on-alfresco-52f-with.html

2017-12-01 17:54:19 GMT <alfbot> Title: IT Tips: How to make search on Alfresco 5.2.f with Solr4 to be locale "unsensitive" (at douglascrp.blogspot.com.br)

2017-12-01 17:56:57 GMT <AFaust> douglascrp: No, it is not.

2017-12-01 17:57:10 GMT <AFaust> Community 5.2 is not affected by the issue I tweeted about.

2017-12-01 17:57:17 GMT <douglascrp> AFaust, ok

2017-12-01 17:57:23 GMT <AFaust> At least not in the same way

End of Daily Log

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