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-03-13 08:41:16 GMT <yregaieg> Morning everyone !

2017-03-13 08:41:56 GMT <yregaieg> Guys, I was wondering what would be the content of the last day of BeeCon ?

2017-03-13 08:42:30 GMT <angelborroy> sessions

2017-03-13 08:42:32 GMT <angelborroy> what else?

2017-03-13 08:42:54 GMT <yregaieg> I was wondering if it will be full of sessions

2017-03-13 08:43:08 GMT <angelborroy> why not?

2017-03-13 08:43:09 GMT <yregaieg> or just closing sessions + some touristic program

2017-03-13 08:43:20 GMT <angelborroy> is a morning session

2017-03-13 08:43:26 GMT <angelborroy> will close at 1 pm

2017-03-13 08:43:38 GMT <angelborroy> and I’ll searching a tourist activiti for the evening

2017-03-13 08:43:45 GMT <yregaieg> That's exactly what I though

2017-03-13 08:43:54 GMT <yregaieg> thanks for confirming that angel

2017-03-13 08:47:44 GMT <yregaieg> ~seen bmejias

2017-03-13 08:47:44 GMT <alfbot> yregaieg: bmejias was last seen in #alfresco 2 weeks, 4 days, 18 hours, 32 minutes, and 19 seconds ago: <bmejias> any idea about how can I track the problem?

2017-03-13 08:54:43 GMT <bhagyas> ~later tell resplin Will there be new CLAs introduced alongside the improved contribution process?

2017-03-13 08:54:43 GMT <alfbot> bhagyas: The operation succeeded.

2017-03-13 09:03:09 GMT <yregaieg> bhagyas: CLA ? or SLA ?

2017-03-13 09:57:38 GMT <angelborroy> yregaieg BeeCon train discounts coming this week

2017-03-13 09:59:37 GMT <yregaieg> angelborroy: Thanks for the heads up, will check with our adm if they did not make the reservations yet

2017-03-13 09:59:57 GMT <yregaieg> any idea if we should expect hotel deals as well ?

2017-03-13 10:00:57 GMT <angelborroy> I’m trying

2017-03-13 10:01:10 GMT <angelborroy> but I have no “real” date for you by now

2017-03-13 10:01:13 GMT <yregaieg> Just confirmed, we will book flights today and wait for the discount for trains, thanks again angelborroy

2017-03-13 10:02:40 GMT <yregaieg> Thanks again angelborroy

2017-03-13 10:05:36 GMT <mrks_js> cool! thanks angelborroy

2017-03-13 11:03:54 GMT <koula> hi all. in an ActionExecuter how could get the user's session with java ?

2017-03-13 11:04:25 GMT <angelborroy> AuthenticationUtil

2017-03-13 11:05:08 GMT <angelborroy> koula http://dev.alfresco.com/resource/AlfrescoOne/5.1/PublicAPI/org/alfresco/repo/security/authentication/AuthenticationUtil.html

2017-03-13 11:05:09 GMT <alfbot> Title: AuthenticationUtil (Alfresco 5.1.2 Public Java API) (at dev.alfresco.com)

2017-03-13 11:07:21 GMT <koula> i would like to set some variables when a users executes an action

2017-03-13 11:08:05 GMT <koula> so the next time the user will not have to enter them again, as long as the session is alive.

2017-03-13 11:11:06 GMT <angelborroy> koula user session is not persistent

2017-03-13 11:11:17 GMT <angelborroy> koula you should use UserPreferences for that

2017-03-13 11:11:44 GMT <angelborroy> http://docs.alfresco.com/5.0/pra/1/concepts/pra-people-get-preferences.html

2017-03-13 11:11:45 GMT <alfbot> Title: Get a person's preferences | Alfresco Documentation (at docs.alfresco.com)

2017-03-13 11:18:01 GMT <koula> it is the user's credentials to another service, that is convinient to run it from alfresco. so i wouldnot want to save them in the preferences. i just want to help the user so as not to add his credentials every time he executes this action, while he is connected to alfresco.

2017-03-13 11:18:30 GMT <angelborroy> koula you need to persist that information

2017-03-13 11:18:45 GMT <koula> what does this mean ?

2017-03-13 11:18:52 GMT <angelborroy> koula maybe Share http session should be the right place

2017-03-13 11:19:06 GMT <angelborroy> koula how about including a web filter?

2017-03-13 11:19:34 GMT <angelborroy> https://github.com/keensoft/alfresco-agreement-filter/blob/master/agreement-filter-share/src/main/java/es/keensoft/share/filter/AgreementFilter.java

2017-03-13 11:19:35 GMT <alfbot> Title: alfresco-agreement-filter/AgreementFilter.java at master · keensoft/alfresco-agreement-filter · GitHub (at github.com)

2017-03-13 11:27:22 GMT <koula> the doclib action is connected with a form. on the first submit the user should add the credentilas, and on the rest the form should not contain those fields.

2017-03-13 11:27:41 GMT <koula> what to choose: filter or share session?

2017-03-13 11:27:55 GMT <angelborroy> use the share session IN the web filter

2017-03-13 11:28:57 GMT <koula> ok. i will try for that.

2017-03-13 11:29:02 GMT <koula> thank you again.

2017-03-13 11:29:09 GMT <angelborroy> you’re welcome

2017-03-13 11:36:10 GMT <angelborroy> ~later tell resplin how can I contact with someone from partnership program from Alfresco? Waiting my local representant for a week now…

2017-03-13 11:36:10 GMT <alfbot> angelborroy: The operation succeeded.

2017-03-13 14:32:09 GMT <AFaust> ~later tell resplin: Just make sure that REPO-426 does support more than just the "dumb ol' Alfresco categories". For years Alfresco has almost criminally neglected and even restricted the potential of categories by only coding for the completely unusable cm:generalclassifiable categories...

2017-03-13 14:32:09 GMT <alfbot> AFaust: The operation succeeded.

2017-03-13 14:37:23 GMT <douglascrp> morning

2017-03-13 14:39:07 GMT <Loftux> AFaust: Neglect a contribution long enough and it can be closed as won't fix since it is to old, or "working on something new" that may or may not come in the future.

2017-03-13 14:55:55 GMT <AFaust> For that one it is actually the second time it is closed.

2017-03-13 14:56:18 GMT <AFaust> First time was January last year

2017-03-13 15:32:44 GMT <LMattioli> Hello everybody. Does anybody has news about ACE-649 (SAML 2.0 support in the "software formerly knows as Alfresco One")?

2017-03-13 15:33:38 GMT <yregaieg> LMattioli: AFAIK, there is an early access for that for EE customers

2017-03-13 15:34:06 GMT <yregaieg> you can ask resplin about to get in that program

2017-03-13 15:40:59 GMT <LMattioli> Yregaieg: Thanks!

2017-03-13 16:10:19 GMT *** CyberDems is now known as fragtion

2017-03-13 16:16:28 GMT <alfbot> resplin: Sent 7 hours and 21 minutes ago: <bhagyas> Will there be new CLAs introduced alongside the improved contribution process?

2017-03-13 16:16:29 GMT <alfbot> resplin: Sent 4 hours and 40 minutes ago: <angelborroy> how can I contact with someone from partnership program from Alfresco? Waiting my local representant for a week now…

2017-03-13 16:16:30 GMT <alfbot> resplin: Sent 1 hour and 44 minutes ago: <AFaust> Just make sure that REPO-426 does support more than just the dumb ol' Alfresco categories . For years Alfresco has almost criminally neglected and even restricted the potential of categories by only coding for the completely unusable cm:generalclassifiable categories...

2017-03-13 16:17:58 GMT <AFaust> Who - alfbot strips away double quotes...

2017-03-13 16:18:07 GMT <AFaust> Meant to write "Whoa"

2017-03-13 16:31:24 GMT <resplin> AFaust: I added an explicit criteria that custom categories should be treated the same as out-of-the-box categories.

2017-03-13 16:32:01 GMT <AFaust> With "custom" meaning that all the metadata / modelling concepts are to be applied to them as to any other node?

2017-03-13 16:32:28 GMT <resplin> AFaust: I've long been frustrated with us not dealing well with custom categories, and I hope to drive more consistency into that (as well as other areas where in the past we only partially implemented stuff).

2017-03-13 16:33:05 GMT <resplin> I don't understand your last question. Categories are attributes that get applied to a node.

2017-03-13 16:33:14 GMT <resplin> What do you mean "as to any other node"?

2017-03-13 16:33:21 GMT <AFaust> Yes - that is only half of what categories are.

2017-03-13 16:33:28 GMT <resplin> Please educate me.

2017-03-13 16:34:10 GMT <AFaust> Categories are themselves nodes. And as nodes I except to be able to use custom special types, aspects and properties to make my categories e.g. easily searchable (if I have a complex tree) or act as "master data" containers

2017-03-13 16:34:19 GMT <resplin> ~later tell angelborroy Please email your local representative and CC me. I can then escalate the email.

2017-03-13 16:34:19 GMT <alfbot> resplin: The operation succeeded.

2017-03-13 16:34:43 GMT <resplin> AFaust: Interesting. I had not previously considered doing that to a category.

2017-03-13 16:35:04 GMT <AFaust> The "dumb ol' Alfresco category" concept is basically just a tree of names, nothing more, which does not befit a metadata-focused use case

2017-03-13 16:35:19 GMT <resplin> Why would you add metadata to a category?

2017-03-13 16:35:33 GMT <AFaust> That was the main motivation for the contribution that you closed in reference to REPO-426

2017-03-13 16:36:22 GMT <resplin> Oh yes. I missed that in my re-reading today, but we did discuss it last week.

2017-03-13 16:36:50 GMT <resplin> The short answer is that our work on the APIs isn't going to change that the internal modeling of categories. It will make it easier to add and remove a custom category.

2017-03-13 16:37:17 GMT <AFaust> Why? One use case I had in real life was related to assigning documents to data entities from ERP. Those data entities (debitor, project and task) were synchronised as categories with some metadata. The simple ID was used for the name, but there were e.g. address information for the debitor, names of responsible users for projects and tasks, start/due/end dates etc.

2017-03-13 16:37:39 GMT <AFaust> That metadata was then used to drive an auto-complete widget in a form to simplify assigning a category to a document

2017-03-13 16:37:52 GMT <resplin> That makes sense.

2017-03-13 16:38:06 GMT <AFaust> You don't have to know the ID - just search by customer / name / description / project manager (whatever)

2017-03-13 16:38:35 GMT <AFaust> Also, behaviours copied metadata from the categories on to the documents to make them searchable by the associated data too

2017-03-13 16:38:47 GMT <resplin> When I have previously worked on something like that, I pull the additional metadata from an external service based on the category as a lookup key. Your suggestion is much easier.

2017-03-13 16:38:55 GMT <AFaust> (ideally, Alfresco would support some way for transparent metadata inheritance instead of having to physically copy)

2017-03-13 16:39:37 GMT <resplin> The short answer is that our work on the APIs isn't going to change that. That's an interesting additional use case. I don't think we will be able to accommodate it in the next release but we should consider it in the future.

2017-03-13 16:39:38 GMT <AFaust> The most important benefit - you are not tied directly to the availability of the other system, and don't continously contribute load to itr

2017-03-13 16:39:57 GMT <resplin> Agreed.

2017-03-13 16:42:14 GMT <AFaust> Ok - so I won't be using that part of the ReST API then when it's done and continue using my own custom web scripts...

2017-03-13 16:43:02 GMT <resplin> Hopefully it meets some use cases, but it won't initially meet all of your requirements or replace custom web scripts.

2017-03-13 16:43:55 GMT <AFaust> "all of your requirements" - I would be glad if I will find requirements where I can actually use it at all....

2017-03-13 16:44:14 GMT <AFaust> Not because it may not implement some specific feature X or Y

2017-03-13 16:44:31 GMT <AFaust> But because it simply will be too low-level for most of the operations.

2017-03-13 16:44:39 GMT <resplin> We need to start somewhere.

2017-03-13 16:45:02 GMT <AFaust> And since each invocation is its own transaction, it will be pain to write atomic business operations / actions with it.

2017-03-13 16:45:13 GMT <AFaust> pain = technically impossible / burden on the client

2017-03-13 16:45:35 GMT <resplin> That's why we are also doing REPO-424: Batch Operations REST API

2017-03-13 16:46:20 GMT <AFaust> That is not sufficient (from the quick read of the title and first few lines)

2017-03-13 16:46:22 GMT <resplin> But that depends on REPO-7: Embed a Queue in the platform.

2017-03-13 16:46:32 GMT <resplin> It is necessary, but not sufficient.

2017-03-13 16:46:45 GMT <resplin> Making progress in that direction.

2017-03-13 16:46:54 GMT <AFaust> Basically I would need a transactionally safe / consistent chain of arbitrary ReST operations

2017-03-13 16:47:29 GMT <resplin> Yes, that is the eventual goal we hope to satisfy

2017-03-13 16:49:37 GMT <resplin> Anyway, I captured the request as REPO-2197.

2017-03-13 16:50:11 GMT <resplin> It'll probably be significant time before we can seriously consider it and expand on that story.

2017-03-13 16:50:44 GMT <resplin> ~later tell bhagyas: Do you have a concern with our current contribution agreement?

2017-03-13 16:50:44 GMT <alfbot> resplin: The operation succeeded.

2017-03-13 16:51:33 GMT <resplin> Thanks for the idea Axel. Your feedback on the product does influence how we do our work, even if we can't always meet your many requirements.

2017-03-13 16:52:52 GMT <resplin> ~later tell yreg: I got a better understanding today on why the history is hard to preserve when migrating from SVN to Git. We need to preserve all our Enterprise branches, and it makes things very messy.

2017-03-13 16:52:52 GMT <alfbot> resplin: The operation succeeded.

2017-03-13 16:53:09 GMT <resplin> ~later tell yreg: That's why my previous work hasn't been as useful as I expected.

2017-03-13 16:53:09 GMT <alfbot> resplin: The operation succeeded.

2017-03-13 16:55:07 GMT <AFaust> resplin: Did you seriously / honestly ask bhagyas that question?

2017-03-13 16:55:08 GMT <resplin> ~later tell yreg: REPO-2196 and REPO-2195

2017-03-13 16:55:08 GMT <alfbot> resplin: The operation succeeded.

2017-03-13 16:55:15 GMT <resplin> AFaust: Yes.

2017-03-13 16:55:28 GMT <resplin> Do you have a concern with the existing contribution agreement?

2017-03-13 16:55:37 GMT <resplin> The process has all sorts of problems, I agree.

2017-03-13 16:55:54 GMT <resplin> But the agreement is pretty short and straightforward. Less than a page. Doesn't ask for anything unreasonable.

2017-03-13 16:56:22 GMT <AFaust> It has been too long since I read the agreement. And Alfresco was pretty inconsistent in terms of requesting it vs. using what was already on file vs. not mentioning anything about it.

2017-03-13 16:56:39 GMT <resplin> Our inconsistency is a key problem. Agreed.

2017-03-13 16:56:40 GMT <AFaust> Then again, almost none of my "actual" contributions made it in, so it didn't matter anyway

2017-03-13 16:57:04 GMT <AFaust> I don't consider patches for bugs a contribution...

2017-03-13 16:57:20 GMT <resplin> But the actual agreement just says "you clearly own what you are contributing", "you let Alfresco do what they want", "you continue to be able to do what you want".

2017-03-13 16:58:19 GMT <AFaust> To this day I am bemused that a previous colleague of mine made it into the Share credits scrawl with a single two-line patch, and I can't find my name everytime I test the scrawl in a new release...

2017-03-13 16:58:37 GMT <resplin> Yeah, I've specifically pointed that out as well.

2017-03-13 16:58:47 GMT <AFaust> My remark was just in terms of "are you really poking the bear?"

2017-03-13 16:59:11 GMT <resplin> When I made a big deal about it recently, the engineering team felt like the right solution was to move to GitHub where the actual contribution history is public.

2017-03-13 16:59:36 GMT <resplin> I figured I'd let them get through that gate before I consider again whether we need an actual Thanks or Credits file.

2017-03-13 17:00:02 GMT <resplin> Your comment about "poking the bear" makes a lot of sense, and I agree. I considered not answering his question.

2017-03-13 17:00:34 GMT <AFaust> Well - it sort of is public. Depending on how PRs are merged / processed to be merged you can still effectively tune out the names of anyone you wish not to appear in the history. And we all know history in Git can be rewritten...

2017-03-13 17:01:10 GMT <resplin> bhagyas noticed that we have been listing a more detailed contribution process on the new GitHub repos (as I've been trying to address these problems). He asked if we would have a new contribution agreement as part of that process.

2017-03-13 17:01:26 GMT <resplin> And I am sincerely curious if people have concerns with our contribution agreement.

2017-03-13 17:01:41 GMT <resplin> I want to make sure it's reasonable.

2017-03-13 17:02:15 GMT <AFaust> I assumed he might have read our last discussion about upcoming improvements to contribution process and was curious for details...

2017-03-13 17:02:24 GMT <resplin> Regarding the git history, that is why I think a Credits file would be worthwhile. Something to evaluate again when the time is right.

2017-03-13 17:03:09 GMT <resplin> I think the engineer had a good point that the GitHub history is more important because it is more visible in a peron's reputation. They are taking seriously the desire that our processes don't accidentally remove credit from a submitter.

2017-03-13 17:04:44 GMT <AFaust> Still - there need to be some limits. E.g. for OOTBee Support Tools we reserve the right to squash commits during merge if it is poorly prepared...

2017-03-13 17:05:34 GMT <resplin> Yes, we will need to figure that out.

2017-03-13 17:07:06 GMT <resplin> This conversation makes me realize that I should put an comment in community.alfresco.com so people know that the next release might not happen until May.

2017-03-13 17:07:39 GMT <resplin> The Git migration work is having more of an impact than I expected, but the results are likely to be better than I expected.

2017-03-13 17:07:47 GMT <AFaust> Ideally, Engineering manages to change the current pattern of using a chain of god-knows-how-many branches that changes are merged up / down...

2017-03-13 17:08:20 GMT <AFaust> I think you put a comment in the last release notes already, but might want to do it a bit more publicly...

2017-03-13 17:08:38 GMT <resplin> That is one of their key frustrations.

2017-03-13 17:09:02 GMT <resplin> But it's hard to avoid when we support our customers on old versions for 3-5 years.

2017-03-13 17:09:35 GMT <AFaust> Maybe there should be a sticky document in community.alfresco.com about schedule of upcoming releases (of course that then forces you to keep it up to date and keep to timeline - the last is something historically speaking is a tall order for Alfresco)

2017-03-13 17:09:39 GMT <resplin> We think breaking the code base up into separate libraries will help. A lot of libraries can be upgraded in old versions and we only have to maintain one branch.

2017-03-13 17:10:05 GMT <AFaust> Sure, and working with an ancient SCM tool like SVN sure did not help...

2017-03-13 17:10:11 GMT <resplin> ++1

2017-03-13 17:10:26 GMT <resplin> Thats regarding the ancient tool.

2017-03-13 17:10:44 GMT <resplin> Though I agree that sticking to a schedule and keeping a public communication up to date is also a challenge for us.

2017-03-13 17:10:44 GMT <AFaust> (same as it does not help users / customers to have to work with ancient versions of libraries in Alfresco - got another complaint from a customer about that today)

2017-03-13 17:11:20 GMT <resplin> Every morning I sigh to myself and say "so much work to do, so many problems we will never solve"

2017-03-13 17:13:53 GMT <osaidi> why is Qname.getPrefixString() returning the localname which means that the qname's prefix is null

2017-03-13 17:14:07 GMT <osaidi> in what cases can the qname prefix be null?

2017-03-13 17:14:51 GMT <AFaust> osaidi: A QName always consists of a namespace and a local name. The prefix is an optional item.

2017-03-13 17:15:35 GMT <AFaust> All QName instances will usually have a null prefix unless they have been specifically constructed to include the optional item

2017-03-13 17:16:31 GMT <AFaust> i.e. if a QName is constructed via QName.createQName(String, String, NamespacePrefixResolver)

2017-03-13 17:18:14 GMT <osaidi> actually i'm getting it via nodeService.getType()

2017-03-13 17:18:27 GMT <osaidi> i'm not constructing it myself

2017-03-13 17:19:00 GMT <AFaust> So you cannot assume the prefix to be provided...

2017-03-13 17:19:28 GMT <osaidi> i see, thanks a lot

2017-03-13 17:20:33 GMT <AFaust> You can always use QName.toPrefixString(NamespaceResolver)

2017-03-13 17:21:35 GMT <osaidi> <AFaust> that's what i was looking for thank you

End of Daily Log

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