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-09-05 06:16:55 GMT <bee-bot> <Loftux> Hi, since objections were raised against filtering the ootb-bot on the alfresco discord channel, can we please restrict using this channel #alfresco-irc-bridge as a primary conversation channel? Either join the discussion on Alfresco discord, or use IRC directly. Why? It looks like the Alfresco discord is just made up of bots right now...
2018-09-05 06:18:12 GMT <bee-bot> <Loftux> I understand that this channel was set up to be a message archive and that is fine, but that is not how it is used right now.
2018-09-05 08:19:51 GMT <bee-bot> <yreg> @Loftux I understand that some people could find it ugly when bridged replies come through, and I have tried to reduce the amount of junk there. But still some people (such as Tichodroma on IRC, or yourself on alfresco-discord) still find it ugly, and do not want to see (what looks like) bots talking to each other
2018-09-05 08:21:20 GMT <bee-bot> <yreg> When this channel was first set up, it was indeed mainly for making a message archive, and then it was used for a little bit more than that (out of convenience)
2018-09-05 08:26:55 GMT <alfresco-discord> <Loftux> <@451675868688023553> Cool, then we have an understanding, lets keep discussion on Alfresco #general or use the IRC client. I don't mind an occasional message posted by the ootb-bot, but when it becomes the main poster it looks like it is a channel only used by bots.
2018-09-05 08:27:11 GMT <bee-bot> <yreg> In any case, since it is apparently too annoying/uncomfortable for you to see messages relayed via a bot (the same way folks hanging on IRC see your messages) I will go ahead and turn this channel into read only,
2018-09-05 08:39:17 GMT <Tichodroma> Just to give you an impression how the bot talk looks here in irssi: https://share.riseup.net/#NMkdKoRA8Ec7aoS_rzDxUQ
2018-09-05 08:59:14 GMT <yreg> Morning folks
2018-09-05 08:59:56 GMT <yreg> Is any of you guys aware of a new Alfresco hidden feature deleting silently all permissions associated with an authority as the authority gets deleted ?
2018-09-05 09:12:41 GMT <AFaust> Yes
2018-09-05 09:12:52 GMT <AFaust> Been there I believe since 5.2
2018-09-05 09:13:21 GMT <AFaust> That's one of the reasons they introduced those non Public API policies for permission service / authority service I believe
2018-09-05 09:15:01 GMT <AFaust> Actually no - they call the permissionService API to delete permissions directly in the AuthorityService - not via a policy
2018-09-05 09:32:45 GMT <yreg> AFaust, so if your sync subsystem messes up only once and deletes authorities (temporarily), then, after you fix the sync, you will need to go through all node permissions and make sure they have the right permissions otherwise re-add them :D
2018-09-05 09:32:52 GMT <yreg> That looks like a huge mess to me
2018-09-05 09:33:39 GMT <yreg> Tichodroma, I need to try that terminal IRC client at some time
2018-09-05 09:33:48 GMT <yreg> Looks very tempting
2018-09-05 09:34:43 GMT <yreg> does it support mouse cursor interaction ?
2018-09-05 09:35:11 GMT <Tichodroma> not that I am aware of
2018-09-05 09:36:01 GMT <Tichodroma> but today most console users use weechat, I guess
2018-09-05 09:57:51 GMT <yreg> AFaust, is there an issue logged for that, I mean is it an intended "feature" ?
2018-09-05 09:58:04 GMT <yreg> Because it looks to me more like a bug / regression
2018-09-05 10:05:01 GMT <AFaust> yreg: Some part of the code has been in place for even longer... I.e. PersonService.deletePerson did delete user permissions back to 2010
2018-09-05 10:06:22 GMT <AFaust> That change commit is tagged with https://issues.alfresco.com/jira/browse/ALF-4118
2018-09-05 10:08:23 GMT <AFaust> https://github.com/Alfresco/alfresco-repository/commit/3eea2d35e7d82446e426e5869a025bbe48f6bafd
2018-09-05 10:08:25 GMT <alfbot> Title:Fix ALF-4118 - PersonServiceImpl - prevent creation of duplicate people · Alfresco/alfresco-repository@3eea2d3 · GitHub (at github.com)
2018-09-05 10:09:05 GMT <AFaust> Oh - and apparently the call to deletePermissions was even contained before (only just now saw that in the GitHub diff - missed it in Eclipse diff view)
2018-09-05 10:13:46 GMT <AFaust> Hmm - and even the call in AuthorityServiceImpl has been there before... so, on second thought, there is no change at all.
2018-09-05 10:14:02 GMT <AFaust> Maybe I just noticed it for the first time when I looked at the new policies in 5.2
2018-09-05 10:59:10 GMT <yreg> Hmmm I am almost sure this was not present in 5.0 / 4.2
2018-09-05 10:59:40 GMT <yreg> Permissions used to be preserved, even when they relate to deleted authorities
2018-09-05 11:01:25 GMT <yreg> Arghh I don't have any 4.2 project at hand to test
2018-09-05 11:01:34 GMT <yreg> Will set that up in a moment
2018-09-05 11:36:02 GMT <yreg> hmmm 5.0 shows a consistent behaviour
2018-09-05 11:49:12 GMT <Tichodroma> Is there an aspect that identifies a node as a working copy?
2018-09-05 11:49:24 GMT <yreg> yes
2018-09-05 11:49:27 GMT <Tichodroma> :)
2018-09-05 11:49:47 GMT <Tichodroma> What is the name of this aspect?
2018-09-05 11:50:14 GMT <yreg> cm:workingcopy
2018-09-05 11:50:35 GMT <Tichodroma> what else :)
2018-09-05 11:50:36 GMT <Tichodroma> thanks
2018-09-05 11:53:17 GMT <yreg> AFaust, interestingly when I attempt to delete a user through share, I get a confirmation prompt with this note : Note: Deleting a user does not remove their permissions from the repository. These permissions will be reused if the user is recreated later. Consider disabling the user account instead.
2018-09-05 11:53:32 GMT <yreg> Nevertheless the permission gets deleted anyway
2018-09-05 11:53:43 GMT <yreg> (Talking about 5.0 CE)
2018-09-05 15:38:14 GMT <fwu2018> ppl, Im having a stange problem with the rest api
2018-09-05 15:38:22 GMT <fwu2018> maybe someone can help
2018-09-05 15:38:47 GMT <fwu2018> in my task implementation, Im getting the user that completes a task usign the task.getassignee
2018-09-05 15:38:59 GMT <fwu2018> this works if I complete a task in share
2018-09-05 15:39:30 GMT <fwu2018> if I use the rest API the tas.getassignee returns always null, even if I set the assignee as I think I should
2018-09-05 15:40:12 GMT <fwu2018> any ideas why this may happen? I dont mind to change something on the rest API or the activiti engine, but right now I dont have a clue about what may be wrong
2018-09-05 15:40:29 GMT <fwu2018> or where is the problem
2018-09-05 16:45:06 GMT <fwu2018> if Im understanding this, I need to claim the task first
2018-09-05 16:45:32 GMT <fwu2018> share must be doing this as soon as an user completes a task
2018-09-05 16:47:06 GMT <fwu2018> so, using the rest api, if I set the state of the task to complete without claimming it, the task will not have an assignee
2018-09-05 16:47:51 GMT <fwu2018> and this means 2 calls to complete a task as expected
The other logs are at http://esplins.org/hash_alfresco