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.
2018-06-15 07:51:51 GMT <alfresco-discord> <bhagyas> Good Friday everyone!
2018-06-15 08:29:28 GMT <alfresco-discord> <twen> What it's already Friday ? 😮 #shocked
2018-06-15 09:29:45 GMT <alfresco-discord> <ERusso> Hi, is AbstractScheduledLockedJob suitable for jobs that use multithreading? I've tried having my job extending it but it still gets executed in both nodes of the cluster, on the second node it retries a few times and then it manages to acquire a lock
2018-06-15 09:45:12 GMT <alfresco-discord> <AFaust> @ERusso The AbstractScheduledLockedJob is only usable if your job executes in less then 30 seconds as the lock is only obtained once and never refreshed during the job execution
2018-06-15 09:47:15 GMT <alfresco-discord> <AFaust> Interestingly, no default job in Alfresco is using that class as the base class, so I would be very skeptical of a class that effectively has no demonstrator / reference use
2018-06-15 09:48:01 GMT <alfresco-discord> <ERusso> oh so do you think it's best to just use JobLockService directly?
2018-06-15 09:48:13 GMT <alfresco-discord> <AFaust> Yes, and I generally do this...
2018-06-15 09:48:25 GMT <alfresco-discord> <ERusso> ok thanks Axel
2018-06-15 09:48:58 GMT <alfresco-discord> <AFaust> I have consolidated most of my Job utility logic (like locking) in https://github.com/Acosix/alfresco-utility/blob/master/repository/src/main/java/de/acosix/alfresco/utility/repo/job/JobUtilities.java#L177
2018-06-15 09:48:59 GMT <alfbot> Title:alfresco-utility/JobUtilities.java at master · Acosix/alfresco-utility · GitHub (at github.com)
2018-06-15 09:50:15 GMT <alfresco-discord> <ERusso> oh great, I'll have a look
2018-06-15 09:50:49 GMT <alfresco-discord> <mbui> Is there a feature OOTB where a non-developer can export all the users with some basic information, such as deleted, authorization state, username etc? :thunking:
2018-06-15 09:51:42 GMT <alfresco-discord> <AFaust> No out-of-the-box feature that I know of
2018-06-15 09:52:38 GMT <alfresco-discord> <AFaust> When I wrote an addon to report active/inactive users (with authorisation state) I did not find anything to base that off...
2018-06-15 09:54:03 GMT <alfresco-discord> <AFaust> For reference, the addon/feature was this one: https://github.com/Acosix/alfresco-audit#web-scripts-to-query-active--inactive-users
2018-06-15 09:54:04 GMT <alfbot> Title:GitHub - Acosix/alfresco-audit: Addon to add audit-related utilities and/or common definitions (at github.com)
2018-06-15 09:55:19 GMT <alfresco-discord> <AFaust> You won't be able to extract the "deleted" information at all, unless you audited and queried the deletion (i.e. via alfresco-access audit)
2018-06-15 09:59:20 GMT <alfresco-discord> <bhagyas> Heyyy @agouveia 😄
2018-06-15 09:59:27 GMT <alfresco-discord> <bhagyas> Good to see you here 😃
2018-06-15 10:00:00 GMT <alfresco-discord> <agouveia> thanks!
2018-06-15 10:03:04 GMT <alfresco-discord> <mbui> @AFaust I'm looking into this export user webscript and they have used nodeService.hasAspect(personInfo.getNodeRef(), ContentModel.ASPECT_PERSON_DISABLED) to determine the deleted state :thonking:
2018-06-15 10:04:13 GMT <alfresco-discord> <AFaust> That is not the "deleted" state - that is just for a user disabled in AD where the disabled state has been synchronized
2018-06-15 10:05:30 GMT <alfresco-discord> <mbui> I see, right.. because deleted users can't be retrieved from the workspace? Is that information stored elsewhere or?
2018-06-15 10:06:00 GMT <alfresco-discord> <AFaust> No, it is stored nowhere. A "deleted" user simply does not have any node existing anymore...
2018-06-15 10:06:34 GMT <alfresco-discord> <AFaust> Only if you set up auditing would you potentially have it as stored data
2018-06-15 10:07:20 GMT <alfresco-discord> <mbui> Because I noticed that deleted users with authorization "Authorized" is still shown in share (as deleted), however "Never authorized" is not shown when searching for it. But in reality they are both stored "nowhere" ?
2018-06-15 10:08:01 GMT <alfresco-discord> <AFaust> Well - the "authorised" state is stored in a separate, Enterprise-only table, and never deleted.
2018-06-15 10:08:33 GMT <alfresco-discord> <AFaust> That is why Enterprise can show you that user a bit differently, because via that table they know the user has logged in at least once (i.e. "has existed")
2018-06-15 10:09:21 GMT <alfresco-discord> <AFaust> And they never deleted the authorised state to prevent you from using that to implement some kind of "license hopping" where you create-delete-recreate users to circumvent the number of licenses you are restricted to
2018-06-15 10:09:56 GMT <alfresco-discord> <AFaust> (before they had that table, they were only counting cm:person nodes, so it was technically possible to have floating licenses)
2018-06-15 10:11:23 GMT <alfresco-discord> <AFaust> On the other hand, if the user never logged in (yet was created / existed), you won't be able to see that as well in Enterprise. So it is quite a spotty record...
2018-06-15 10:12:44 GMT <alfresco-discord> <AFaust> In some use cases where such a user is only used in runAs contexts, you might still end up with the user being used as creator / modifier of some nodes without ever having logged in, yet Enterprise would not know the user ever existed as license assignment only occurs upon authentication...
2018-06-15 10:32:52 GMT <alfresco-discord> <mbui> Thanks for clearing that :seemsgood:
2018-06-15 11:13:15 GMT <HansDeBal> when you have a standalone index server, is it recommended to have a ACS platform installation on the same server to avoid network-latency when tracking? Or is that overkill?
2018-06-15 11:14:49 GMT <alfresco-discord> <Mark> Platform installation, yes. This is what alfresco recommends for throughput optimization
2018-06-15 11:15:22 GMT <HansDeBal> great, thx!
2018-06-15 11:17:32 GMT <alfresco-discord> <Mark> Also, imagine you have a large new portion of content to be indexed. A single separate platform node for indexing will prevent your actual nodes to be flooded. Doesn't need to be on the same machine for that benefit though.
2018-06-15 11:21:43 GMT <HansDeBal> yes indeed, an ingestion node :)
2018-06-15 11:48:13 GMT <alfresco-discord> <bhagyas> Who knew that SiteService was inheriting from Spring Surf? raise your hands
2018-06-15 11:48:29 GMT <alfresco-discord> <bhagyas> ✋🏼
2018-06-15 11:48:31 GMT <angelborroy> me
2018-06-15 11:48:52 GMT <angelborroy> I tried to make something with it some time ago
2018-06-15 11:49:01 GMT <angelborroy> Obviously I did the same thing in another way
2018-06-15 11:49:05 GMT <alfresco-discord> <bhagyas> xD
2018-06-15 11:50:22 GMT <alfresco-discord> <bhagyas> btw, wasn't there a java util for parsing QName values to Java Types
2018-06-15 11:50:53 GMT <alfresco-discord> <bhagyas> Trying to remember
2018-06-15 12:18:01 GMT <alfresco-discord> <AFaust> You mean like QName.resolveToQName(resolver, value) ?
2018-06-15 12:18:44 GMT <alfresco-discord> <bhagyas> nah, something that converts serialised values to java equivalents
2018-06-15 12:19:04 GMT <alfresco-discord> <bhagyas> (without manual casting and setting default values)
2018-06-15 12:20:05 GMT <alfresco-discord> <AFaust> Not sure what you mean... can't be so simple as "standard Java deserialisation" because you'd need to cast in that case
2018-06-15 12:21:05 GMT <alfresco-discord> <AFaust> there is also DataTypeConverter.INSTANCE.convert(QName.class, value)... though this has a minor kinks...
2018-06-15 12:24:18 GMT <alfresco-discord> <AFaust> @kgastaldo I was surprised you referred that one poster in the community platform to Sales despite the low number of users... Since when is Sales not rejecting such small deal requests that they don't really care about?
2018-06-15 12:33:19 GMT <alfresco-discord> <bhagyas> that seems to be it., afair
2018-06-15 12:39:16 GMT <alfresco-discord> <AFaust> As for that kink: The default converter can't handle the empty string which might get submitted from UI text fields. IMHO empty string should be treated just as null, which is what I did in my small override (https://github.com/Acosix/alfresco-utility/blob/master/repository/src/main/java/de/acosix/alfresco/utility/repo/datatype/ImprovedTypeConverterInitialiser.java#L120)
2018-06-15 12:39:17 GMT <alfbot> Title:alfresco-utility/ImprovedTypeConverterInitialiser.java at master · Acosix/alfresco-utility · GitHub (at github.com)
2018-06-15 17:55:10 GMT <alfresco-discord> <mbui> Considering a customer that is currently using a highly customized Share and looking into migrating to an ADF client: Are there currently any known drawbacks or short comings of using ADF, i.e. any feature/functionality that Share has out-of-the-box that ADF doesn't support currently? (both on component and JS-API level)
2018-06-15 18:21:16 GMT <alfresco-discord> <douglascrp> mbui there are lots of things that are not present right now
2018-06-15 18:21:33 GMT <alfresco-discord> <douglascrp> I would say it is not ready as a share replacement
2018-06-15 18:36:15 GMT <alfresco-discord> <DenysVuika> Content Application example in ADF can be a good start anyway (https://alfresco.github.io/alfresco-content-app/). At least can give people examples on how to craft and ADF app fast.
2018-06-15 18:36:16 GMT <alfbot> Title:Alfresco Content App (at alfresco.github.io)
The other logs are at http://esplins.org/hash_alfresco