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-09-14 09:11:20 GMT <angelborroy> AFaust I’ve detected some strange behaviour I hadn’t notice before

2017-09-14 09:11:45 GMT <angelborroy> You can set any metatda to any type

2017-09-14 09:11:56 GMT <angelborroy> even if the metadata does not belongs to the type

2017-09-14 09:12:17 GMT <angelborroy> is this new or is a “classical” issue?

2017-09-14 09:23:30 GMT <AFaust> That is "classical"

2017-09-14 09:23:57 GMT <angelborroy> ok, thanks, just to save my effort to raise an issue

2017-09-14 09:24:01 GMT <angelborroy> AFaust thanks!

2017-09-14 09:24:10 GMT <AFaust> Alfresco does not validate for properties defined by the type of the node. This is necessary to support the "transient" properties feature, e.g. those not defined in any model

2017-09-14 09:24:37 GMT <AFaust> Though you could say that it should IF the property is actually defined via a model.

2017-09-14 09:24:57 GMT <angelborroy> ok, this is the “residual” flag

2017-09-14 09:25:00 GMT <AFaust> But chances are high that Alfresco would close such an issue as "has always been that way and changing it might break existing solutions"

2017-09-14 09:25:19 GMT <angelborroy> I guessed that, yes

2017-09-14 09:25:30 GMT <AFaust> Like they did with one of my issues about incorrect behaviour of removeAspect

2017-09-14 09:25:30 GMT <AFaust> https://issues.alfresco.com/jira/browse/ALF-21806

2017-09-14 09:26:01 GMT <angelborroy> In Spain we name this “contumacy”

2017-09-14 09:26:19 GMT <angelborroy> but they are thinking about “coherence"

2017-09-14 09:26:25 GMT <angelborroy> this both are really false friends

2017-09-14 09:27:14 GMT <AFaust> I am wondering at what point I'd consider implementing an addon that provides a "BetterDBNodeServiceImpl" with fixes for issues like these

2017-09-14 09:27:24 GMT <angelborroy> wow

2017-09-14 09:27:35 GMT <angelborroy> this should be really “hard”

2017-09-14 09:27:47 GMT <angelborroy> For me is in the limit of a complete fork

2017-09-14 09:28:03 GMT <angelborroy> But now it’s easy to fork, as modules are smaller

2017-09-14 09:28:07 GMT <AFaust> Let the customer / end user decide if they want to have a correct product behaviour or compatibility with absolutely idiotic addons that rely on errors

2017-09-14 09:28:18 GMT <angelborroy> hehe

2017-09-14 09:30:51 GMT <AFaust> At least that would also give me the chance to add some caching e.g. to node associations and re-implement the parent cache as a proper cache

2017-09-14 09:32:21 GMT <angelborroy> and also re-thing about that evil “getChildAssociations” method

2017-09-14 09:32:37 GMT <angelborroy> probably is the main cause for many performance problems

2017-09-14 09:33:58 GMT <AFaust> Which variant of it are you specifically thinking about - the one with child node types or the one with the regex based matching?

2017-09-14 09:34:38 GMT <angelborroy> The first one, but probably also the second one is relevant

2017-09-14 09:35:47 GMT <AFaust> The first one should actually be not that bad...

2017-09-14 09:36:36 GMT <AFaust> What it could use though is some sprucing up with regards to how parameters are treated, e.g. if you say "get children of type X" you usually also want to have children of sub-type of X

2017-09-14 09:37:38 GMT <angelborroy> That’s an enhancement, but I was thinking about performance

2017-09-14 09:38:05 GMT <angelborroy> I’ve seen many Alfresco servers frozen by a long getChildren query at database

2017-09-14 09:39:39 GMT <AFaust> But in what kind of scenarios? How many child nodes did they have for a specific level?

2017-09-14 09:40:06 GMT <angelborroy> classic action: empty trash bin after many years of unnattended running

2017-09-14 09:40:06 GMT <AFaust> And what was the distribution of node types as children?

2017-09-14 09:40:43 GMT <AFaust> Ok - but that is not a problem of the getChildren query, that is a problem of the entire trash can handling which is idiotic for keeping all archived nodes at the root of the store

2017-09-14 09:40:56 GMT <angelborroy> yep

2017-09-14 09:41:18 GMT <angelborroy> but is also the same with organisations that didn’t know about the 3,000 children restriction

2017-09-14 09:41:25 GMT <AFaust> The same with the version history roots and version nodes being kept as simple lists at one level each

2017-09-14 09:41:31 GMT <angelborroy> yep

2017-09-14 09:43:01 GMT <AFaust> The getChildren operation could use some pagination controls for sure and do incremental DB loading instead of one huge query (same problem as the DB FTS support)

2017-09-14 09:43:26 GMT <AFaust> But the problems with archive / version need to be handled by implementing better services for these components

2017-09-14 09:43:43 GMT <angelborroy> you see, a lot of work to be re-done!

2017-09-14 09:45:19 GMT <AFaust> BTW: Did you already try out how long it takes to process PRs against the new GitHub projects?

2017-09-14 09:45:59 GMT <AFaust> After 22 days with no feedback, my trivial test PR got merged 2 days ago (https://github.com/Alfresco/alfresco-data-model/pull/2)

2017-09-14 09:46:00 GMT <alfbot> Title: Fix for ALF-21849 by AFaust · Pull Request #2 · Alfresco/alfresco-data-model · GitHub (at github.com)

2017-09-14 09:46:20 GMT <AFaust> Wondering if I should try with a more elaborate one and how long that'd take...

2017-09-14 09:46:30 GMT <angelborroy> at least is a new way we hadn’t in the past

2017-09-14 09:47:22 GMT <bhuvana_> hi all

2017-09-14 09:47:28 GMT <bhuvana_> goodevening

2017-09-14 09:47:58 GMT <bhuvana_> I am trying ajax call in webscript

2017-09-14 09:48:13 GMT <AFaust> Maybe I'd use ALF-18681 / parts of ALF-11982 as the next test case

2017-09-14 09:48:35 GMT <bhuvana_> i am getting Uncaught ReferenceError: Alfresco is not defined

2017-09-14 09:48:52 GMT <bhuvana_> Alfresco.util.Ajax.jsonGet

2017-09-14 09:48:59 GMT <bhuvana_> at this line

2017-09-14 09:49:02 GMT <angelborroy> bhuvana_ you are using SERVER side JavaScript

2017-09-14 09:49:10 GMT <bhuvana_> can any one please help me

2017-09-14 09:49:12 GMT <angelborroy> so you cannot use client functions

2017-09-14 09:49:27 GMT <bhuvana_> client side

2017-09-14 09:49:41 GMT <angelborroy> if you are developing a webscript, then you are at server side

2017-09-14 09:50:07 GMT <bhuvana_> yes

2017-09-14 09:50:38 GMT <bhuvana_> I am using serverside js as I am deploying

2017-09-14 09:52:00 GMT <bhuvana_> actually i developed one webscript for getting count of documents site wise

2017-09-14 09:52:20 GMT <bhuvana_> I am calling this webscript in share custom page

2017-09-14 09:53:25 GMT <angelborroy> bhuvana_ which service are you invoking in that “jsonGet”?

2017-09-14 09:54:13 GMT <bhuvana_> this is my custom page html

2017-09-14 09:54:15 GMT <bhuvana_> https://pastebin.com/Psr1z1hz

2017-09-14 09:54:16 GMT <alfbot> Title: <html> <head> <title>Highcharts Tutorial</title> <script src = "h - Pastebin.com (at pastebin.com)

2017-09-14 09:54:42 GMT <angelborroy> so it’s not a web script

2017-09-14 09:54:56 GMT <angelborroy> it’s a custom web page

2017-09-14 09:55:06 GMT <angelborroy> which is not importing Alfresco Client JS

2017-09-14 09:55:13 GMT <bhuvana_> in that page i am calling webscript

2017-09-14 09:55:26 GMT <angelborroy> Alfresco.util.Ajax.jsonGet is available at "alfresco.js"

2017-09-14 09:55:43 GMT <angelborroy> But I recommend you to use another approach, as you are outside Alfresco framework

2017-09-14 09:55:49 GMT <bhuvana_> how to import that js means exact location

2017-09-14 09:56:07 GMT <angelborroy> check this one: http://api.jquery.com/jquery.ajax/

2017-09-14 09:56:08 GMT <alfbot> Title: jQuery.ajax() | jQuery API Documentation (at api.jquery.com)

2017-09-14 09:56:34 GMT <angelborroy> bhuvana_ you have jquery available in your web page

2017-09-14 09:57:22 GMT <angelborroy> bhuavana_ also you can check how to start with the ADF framework, which can be used to build Alfresco web pages

2017-09-14 09:57:40 GMT <bhuvana_> ok

2017-09-14 10:01:44 GMT <angelborroy> AFaust ALF-11982 reported 10-Dec-2011… OMG!

2017-09-14 10:02:18 GMT <AFaust> yeah... annoying that one

2017-09-14 11:55:52 GMT <MarkTielemans> ~since

2017-09-14 11:55:52 GMT <alfbot> MarkTielemans: <angelborroy> AFaust I’ve detected some strange behaviour I hadn’t notice before, <angelborroy> You can set any metatda to any type, <angelborroy> even if the metadata does not belongs to the type, <angelborroy> is this new or is a “classical” issue?, <AFaust> That is "classical", <angelborroy> ok, thanks, just to save my effort to raise an issue, <angelborroy> AFaust thanks!, <AFaust> Alfresco does not (14 more messages)

2017-09-14 12:16:28 GMT <douglascrp> hello

2017-09-14 12:17:04 GMT <douglascrp> AFaust, one more to us to follow https://github.com/Alfresco/share/pull/2

2017-09-14 12:17:06 GMT <alfbot> Title: MNT-17527 Add support for annotation layer by yregaieg · Pull Request #2 · Alfresco/share · GitHub (at github.com)

2017-09-14 12:18:49 GMT <AFaust> Already saw that in IRC this week

2017-09-14 12:50:25 GMT <douglascrp> I am working on a custom renderer for dates in Share

2017-09-14 12:51:03 GMT <douglascrp> but for some reason I don't know yet, the date information for custom properties is wrong, while for the ootb ones is right

2017-09-14 12:51:37 GMT <douglascrp> a sample

2017-09-14 12:51:38 GMT <douglascrp> "cm:created": {

2017-09-14 12:51:39 GMT <douglascrp> "iso8601": "2017-09-12T19:35:01.856Z",

2017-09-14 12:51:39 GMT <douglascrp> "value": "Tue Sep 12 21:35:01 CEST 2017"

2017-09-14 12:51:39 GMT <douglascrp> },

2017-09-14 12:51:49 GMT <douglascrp> both iso8601 and value represent the same "date"

2017-09-14 12:52:02 GMT <douglascrp> but for my custom property

2017-09-14 12:52:03 GMT <douglascrp> "dbs:dataDocumento": {

2017-09-14 12:52:04 GMT <douglascrp> "iso8601": "2017-09-11T22:00:00.000Z",

2017-09-14 12:52:04 GMT <douglascrp> "value": "Tue Sep 12 00:00:00 CEST 2017"

2017-09-14 12:52:04 GMT <douglascrp> },

2017-09-14 12:52:49 GMT <douglascrp> and what is weird, is that I have two custom date properties, one for the document's date, and the other one for the due date for the user to take an action

2017-09-14 12:53:17 GMT <douglascrp> both have different values for the iso8601, but for both of them, the value is the same

2017-09-14 12:53:45 GMT <douglascrp> so I see 2017/09/01 and 2017/09/01, when the right thing would be to have 2017/09/01 and 2017/09/30

2017-09-14 12:54:10 GMT <douglascrp> as my renderer relies on the iso8601 value to render the value, it is always wrong

2017-09-14 12:55:03 GMT <douglascrp> I can not understand why there share/service/components/documentlibrary/data/doclist/all/site/mysite/documentLibrary webscript is giving me these wrong values

2017-09-14 12:55:16 GMT <douglascrp> s/there/the

2017-09-14 12:58:30 GMT <AFaust> I don't really understand the problem. The values for dbs:dataDocumento you provided are correct

2017-09-14 13:00:30 GMT <AFaust> The problem you have is simply with client timezone vs. server timezone...

2017-09-14 13:00:56 GMT <douglascrp> AFaust, weird... wait, let me check something

2017-09-14 13:01:06 GMT <AFaust> How is your renderer using the ISO date? Is it simply parsing and displaying it?

2017-09-14 13:01:21 GMT <douglascrp> it is formating it as DD/MM/YYYY

2017-09-14 13:01:30 GMT <douglascrp> but I am sure I saw the value wrong in the json response

2017-09-14 13:01:44 GMT <douglascrp> for some reason, it seens the formating tool I used to get the value to post here "fixed" the values

2017-09-14 13:01:45 GMT <AFaust> Formatting is irrelevant - the question is: Are you adjusting for timezone differences...

2017-09-14 13:01:51 GMT <douglascrp> no, I am not

2017-09-14 13:02:24 GMT <AFaust> Ok - maybe you are not doing that yourself. What utility are you using to parse the ISO date in JavaScript?

2017-09-14 13:02:51 GMT <douglascrp> AFaust, https://pastebin.com/Q7a1YXUj

2017-09-14 13:02:52 GMT <alfbot> Title: function registerCustomRenderers(customRenderers, customProperties) { if (A - Pastebin.com (at pastebin.com)

2017-09-14 13:03:15 GMT <douglascrp> let me recheck that

2017-09-14 13:04:58 GMT <douglascrp> ah, I have a bug here

2017-09-14 13:05:32 GMT <douglascrp> it is always using the same property when it renders the value

2017-09-14 13:06:21 GMT <AFaust> Ok - the fromISO8601 is fine to use and it already adjusts for timezone (though there are some corner cases on dates when DST kicks in / runs out where there might be incorrect conversions)

2017-09-14 13:07:44 GMT <douglascrp> the problem is that the properties[customProperty] is always the same

2017-09-14 13:07:57 GMT <douglascrp> so this is why I am getting the same value for the two properties

2017-09-14 13:08:09 GMT <AFaust> Yeah, because you are using closures incorrectly

2017-09-14 13:08:25 GMT <douglascrp> I don't even know what closures are :|

2017-09-14 13:08:32 GMT <douglascrp> I had a piece of code that I tried to adapt

2017-09-14 13:08:33 GMT <AFaust> It will always use the last property in your list

2017-09-14 13:08:33 GMT <douglascrp> :D

2017-09-14 13:08:43 GMT <douglascrp> yes, that is exactly what is happening

2017-09-14 13:08:58 GMT <AFaust> Oh - if you are using JavaScript you should really know what closures are...

2017-09-14 13:09:16 GMT <douglascrp> AFaust, I don't know... sad but true

2017-09-14 13:10:34 GMT <AFaust> You are basically dealing with this scenario: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures#Emulating_private_methods_with_closures

2017-09-14 13:10:35 GMT <alfbot> Title: Closures - JavaScript | MDN (at developer.mozilla.org)

2017-09-14 13:10:36 GMT <douglascrp> ah, right... I was reading here

2017-09-14 13:10:39 GMT <douglascrp> :D

2017-09-14 13:10:47 GMT <douglascrp> now I understand what it means

2017-09-14 13:11:27 GMT <AFaust> Sorry, wrong link: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures#Creating_closures_in_loops_A_common_mistake

2017-09-14 13:11:28 GMT <alfbot> Title: Closures - JavaScript | MDN (at developer.mozilla.org)

2017-09-14 13:13:08 GMT <douglascrp> so, the solution is to save the value in the function scope, and use it instead

2017-09-14 13:14:39 GMT <douglascrp> apparently not :D

2017-09-14 13:14:41 GMT <douglascrp> ok, let me read

2017-09-14 13:14:43 GMT <douglascrp> time to learn

2017-09-14 13:49:08 GMT <AFaust> angelborroy: Wow - looks like we finally broke the limit of Jive to support comparing versions on the hack-a-thon project ideas page...

2017-09-14 13:49:21 GMT <angelborroy> really?

2017-09-14 13:49:23 GMT <angelborroy> let me check

2017-09-14 13:49:49 GMT <angelborroy> “The document body was too large to do a version comparison”

2017-09-14 13:49:50 GMT <angelborroy> hehe

2017-09-14 13:50:18 GMT <AFaust> So you added the partitioning project idea today?

2017-09-14 13:50:18 GMT <angelborroy> probably we can split in different pages

2017-09-14 13:50:27 GMT <angelborroy> today I’ve added 2 projects

2017-09-14 13:50:35 GMT <angelborroy> https://community.alfresco.com/docs/DOC-7046-projects-and-teams-global-virtual-hack-a-thon-2017#jive_content_id_DeliveringDocuments_a_Folder_Share_Action

2017-09-14 13:50:38 GMT <alfbot> Title: Projects and Teams Global Virtual Hack-a-thon 2017 | Alfresco Community (at community.alfresco.com)

2017-09-14 13:50:44 GMT <angelborroy> https://community.alfresco.com/docs/DOC-7046-projects-and-teams-global-virtual-hack-a-thon-2017#jive_content_id_Node_Properties_table_partitioning

2017-09-14 13:50:46 GMT <alfbot> Title: Projects and Teams Global Virtual Hack-a-thon 2017 | Alfresco Community (at community.alfresco.com)

2017-09-14 13:51:58 GMT <AFaust> Hmm - somehow I must find a way to educate people on how to properly edit pages in Jive to have proper formatting.... everytime someone adds a project there is not enough space between the previous idea and the headline

2017-09-14 13:52:12 GMT <angelborroy> it was me?

2017-09-14 13:52:28 GMT <angelborroy> yep

2017-09-14 13:52:29 GMT <angelborroy> sorry

2017-09-14 13:52:36 GMT <angelborroy> Let me fix that

2017-09-14 13:52:44 GMT <AFaust> Already did...

2017-09-14 13:53:04 GMT <AFaust> Well, I'll remove the example project section now - should no longer be necessary as we have enough examples

2017-09-14 13:55:09 GMT <AFaust> angelborroy: Regarding the partitioning: I hope you will also consider the need to re-consolidate the partitions into a single table before an Alfresco upgrade...

2017-09-14 13:55:59 GMT <angelborroy> it’s a shell script to split / merge partitions automatically

2017-09-14 13:56:00 GMT <AFaust> And you should also think about different requirements regarding partitioning patterns, e.g. how properties are distributed / organised in partitions

2017-09-14 13:56:07 GMT <angelborroy> but probably it should include also a “howto"

2017-09-14 13:57:37 GMT <AFaust> E.g. a "smart" partition making use of the data model (types of properties) and knowledge about the semantics of properties is usually preferable to a simple "split on Node ID" or "split on QName ID" approach

2017-09-14 13:58:35 GMT <angelborroy> sure, we can start with Node ID and later open it for other patterns

2017-09-14 14:00:28 GMT <AFaust> In one case I have partitioned properties in "all properties with NodeRef values", "all properties with date values", "all properties with list-of-value constraints", "all remaining text properties", "remaining properties"

2017-09-14 14:01:16 GMT <angelborroy> nice idea

2017-09-14 14:01:29 GMT <AFaust> oh, almost forgot: partitions for "name or title" and "frozen version stuff"

2017-09-14 14:01:39 GMT <angelborroy> wow

2017-09-14 14:01:50 GMT <angelborroy> probably you can include a wish list for our project

2017-09-14 14:02:05 GMT <angelborroy> We’ll decide what to implement and what to be left for the future

2017-09-14 14:02:48 GMT <AFaust> Well - ideally a tool could parse data models, look up QNames in the database and dynamically derive "most reasonable partitions" using some default patterns (global / property-based)

2017-09-14 14:03:25 GMT <angelborroy> I don’t think that Raúl (the guy owner of the idea) has the right skills for such a development

2017-09-14 14:03:38 GMT <AFaust> Challenge time!

2017-09-14 14:04:39 GMT <AFaust> Well, in that case there would potentially be work for a couple more hack-a-thons to be attended

2017-09-14 14:05:11 GMT <angelborroy> yep

2017-09-14 14:05:22 GMT <angelborroy> or we can find volunteers in the Community

2017-09-14 14:05:31 GMT <angelborroy> I’m going to include that in the page

2017-09-14 14:08:53 GMT <douglascrp> AFaust, my custom renderer is fixed now... tks for the links

2017-09-14 14:09:18 GMT <douglascrp> but now I have the timezone problem

2017-09-14 14:12:44 GMT <douglascrp> my custom properties are d:date, and they are being returned with 00:00 time

2017-09-14 14:13:29 GMT <douglascrp> when the fromISO8601 converts it, it is show with the wrong date

2017-09-14 14:15:39 GMT <AFaust> The problem is not that they are return as 00:00 time (they are actually stored that way) but that you are trying to deal with them as a datetime. The fromISO8601 function has a second parameter called "ignoreTime"

2017-09-14 14:16:05 GMT <AFaust> If you set that to true I believe it should work with parsing a date-only value

2017-09-14 14:19:01 GMT <douglascrp> ah, let me try it

2017-09-14 14:19:02 GMT <douglascrp> tks

2017-09-14 16:21:11 GMT <fwu> hi all

2017-09-14 16:54:28 GMT <douglascrp> AFaust, hey, one more information on the topic we were talking before

2017-09-14 16:54:46 GMT <douglascrp> there is something I believe is wrong on the way it is working when it comes to date properties

2017-09-14 16:54:50 GMT <douglascrp> which is my case

2017-09-14 16:55:20 GMT <douglascrp> I tried to use the fromISO8601 function with the ignoreTime, and it does what it is supposed to do

2017-09-14 16:55:33 GMT <douglascrp> but the problem is that the date coming from the webscript is already wrong

2017-09-14 16:56:03 GMT <douglascrp> "dbs:dataDocumento": {

2017-09-14 16:56:03 GMT <douglascrp> "iso8601": "2017-08-31T22:00:00.000Z",

2017-09-14 16:56:03 GMT <douglascrp> "value": "Fri Sep 01 00:00:00 CEST 2017"

2017-09-14 16:56:03 GMT <douglascrp> },

2017-09-14 16:56:27 GMT <douglascrp> for me, if this is a date (not datetime), I don't want it to be calculated and having the date changed

2017-09-14 16:56:47 GMT <douglascrp> in this case, the correct would be 2017-09-01, and not 2017-08-31

2017-09-14 16:57:15 GMT <douglascrp> and then checking the source code, I have found the AlfrescoJsonSerializer class

2017-09-14 16:57:40 GMT <douglascrp> and it does not take in consideration the property time, and it uses timezone, always, when it needs to serialize the date object

2017-09-14 16:57:50 GMT <douglascrp> am I wrong to believe this is the wrong behaviour?

2017-09-14 16:58:37 GMT <douglascrp> it uses the ISO8601DateFormat class from the spring-surf-core project

2017-09-14 16:59:28 GMT <douglascrp> AFaust, ^

2017-09-14 17:11:01 GMT <fwu> ppl, im trying some search in the browser like this: http://localhost:8081/share/proxy/alfresco-api/cmis/versions/1.1/browser?cmisaction=query&statement= select * etcccc

2017-09-14 17:11:38 GMT <fwu> but it always returns a bunch on the same info no matter what is the select instruction, and no documents are returned

2017-09-14 17:11:53 GMT <fwu> why this happens?

2017-09-14 17:14:05 GMT <fwu> this also give me a bunch of the same infor without any document info, but this time I receive a file instead of getting the output on the browser: http://localhost:8081/share/proxy/alfresco-api/cmis/versions/1.1/atom/query?q=select * from ectttttt

2017-09-14 17:16:47 GMT <fwu> strange that if I use this url it works as expected:

2017-09-14 17:16:52 GMT <douglascrp> fwu, have you tried your query using the node browser?

2017-09-14 17:16:52 GMT <fwu> http://localhost:8081/alfresco/api/-default-/public/cmis/versions/1.1/browser?cmisselector=query&succinct=true&q=SELECT%20*

2017-09-14 17:17:03 GMT <fwu> douglascrp, hello!

2017-09-14 17:17:26 GMT <fwu> actually it is working with the last url, but I need get it using the proxy url...

2017-09-14 17:17:39 GMT <fwu> to make an ajax call

2017-09-14 17:17:48 GMT <fwu> without the need to pass the user ticket

2017-09-14 17:18:02 GMT <fwu> I dont understand why with the proxy url it is not working...

2017-09-14 17:22:15 GMT <douglascrp> what is worst about my case is that even the value part of the date is not valid to be parsed in a date object

2017-09-14 17:26:29 GMT <fwu> I think I have it working now like this:

2017-09-14 17:26:45 GMT <fwu> http://localhost:8081/share/proxy/alfresco-api/-default-/public/alfresco/cmis/versions/1.1/browser?cmisselector=query&succinct=true&q=

2017-09-14 17:27:26 GMT <fwu> share/proxy and then a bunch of url sections...arghh

2017-09-14 17:32:06 GMT <AFaust> douglascrp: Sorry, I was occupied with a bit of early evening relaxation

2017-09-14 17:34:50 GMT <AFaust> The ISO8601 stuff is processing everything just fine. The date is correct. The problem is that the way that people expect dates / date times to be treated without understanding the concepts of timezones and transmission without corruption.

2017-09-14 17:35:17 GMT <douglascrp> AFaust, yes, but don't you think a "date" should ignore the time part?

2017-09-14 17:35:22 GMT <AFaust> No - never

2017-09-14 17:35:28 GMT <douglascrp> aahhh :D

2017-09-14 17:36:04 GMT <AFaust> Correction - it should never assume it is the same date everywhere in the world.

2017-09-14 17:36:38 GMT <AFaust> due to how timezones work, there can be up to 3 different dates active at the same time around the world

2017-09-14 17:36:41 GMT <douglascrp> yes, that is correct

2017-09-14 17:37:38 GMT <douglascrp> I have to find a way to format the date correctly using GMT-0300 (BRT) for this renderer to be ok

2017-09-14 17:37:58 GMT <AFaust> The proper thing that should be done in the persistence of a date is that the timezone it applies to should be saved alongside its value.

2017-09-14 17:38:00 GMT <douglascrp> do you know any other js utility to do so?

2017-09-14 17:38:15 GMT <AFaust> So that any logic can take care to properly display the date value independent of the locale timezone.

2017-09-14 17:38:26 GMT <douglascrp> right

2017-09-14 17:39:57 GMT <AFaust> One thing I did in a project way back was to adjust the date for the local time zone on the Share side (edit properties) before it was sent to Repository

2017-09-14 17:40:43 GMT <douglascrp> seems to be almost the same as how the ml properties are handled

2017-09-14 17:40:58 GMT <AFaust> But one question first: Is your server really located in CEST area? And what is the timezone of the client / user that set that propery value?

2017-09-14 17:41:16 GMT <douglascrp> AFaust, no, it is not

2017-09-14 17:41:21 GMT <douglascrp> but let me check how it is configured

2017-09-14 17:41:32 GMT <AFaust> Then why does it render the local date time as CEST?

2017-09-14 17:42:00 GMT <douglascrp> well, it is not "located" (I mean, physically )

2017-09-14 17:42:09 GMT <douglascrp> but let me check the configuration

2017-09-14 17:44:19 GMT <douglascrp> AFaust, the server is ok

2017-09-14 17:44:21 GMT <douglascrp> # timedatectl status | grep "Time zone"

2017-09-14 17:44:21 GMT <douglascrp> Time zone: America/Sao_Paulo (BRT, -0300)

2017-09-14 17:44:37 GMT <douglascrp> let me check the JDK parameters

2017-09-14 17:44:44 GMT <AFaust> Then did someone configure the JVM to use CEST?

2017-09-14 17:45:03 GMT <douglascrp> AFaust, come on

2017-09-14 17:45:04 GMT <douglascrp> Europe/Stockholm

2017-09-14 17:45:05 GMT <douglascrp> :D

2017-09-14 17:45:10 GMT <douglascrp> that explains everything

2017-09-14 17:45:15 GMT <douglascrp> how come?

2017-09-14 17:46:52 GMT <AFaust> If I remember correctly when setting the value from the UI, the UI only sends the date part. The server then converts it into a Date and formats it as UTC ISO8601 for persistence

2017-09-14 17:47:09 GMT <AFaust> Since the server is running in CEST, it parses the date into a 00:00 date value of CEST, which is +02:00

2017-09-14 17:47:17 GMT <douglascrp> correct

2017-09-14 17:47:24 GMT <douglascrp> I have just changed the JVM parametesr

2017-09-14 17:47:26 GMT <douglascrp> parameters

2017-09-14 17:47:31 GMT <douglascrp> let me see if that works now

2017-09-14 17:48:01 GMT <AFaust> And that's what I meant with "date handling should always include the timezone for which the date is meant" - so you don't have to rely on server timezone hacks...

2017-09-14 17:48:17 GMT <douglascrp> right

2017-09-14 17:48:30 GMT <douglascrp> so the best thing to do would be to always use datetime instead of date?

2017-09-14 17:48:55 GMT <douglascrp> I had a big problem when using date in another project, but that one was fixed in the latest versions

2017-09-14 17:49:08 GMT <AFaust> That is what I usually do. Still, in that case you are still not providing / storing the original timezone.

2017-09-14 17:49:10 GMT <douglascrp> because of the daylight saving

2017-09-14 17:49:42 GMT <douglascrp> alfresco simply failed when you set the date of an object for the exact date when the daylight saving starts or finishes

2017-09-14 17:50:15 GMT <AFaust> Alfresco tried to solve their "fully day event" issues in the Share calendar using d:datetime, but full day events would show up differently for users depending on their local timezone. Only in the original timezone would it show up properly, whereas in others it would be e.g. two events 22:00-00:00 and 00:00-22:00

2017-09-14 17:50:54 GMT <AFaust> That is what I meant earlier today with the fromISO8601 JS function to fail for a certain range around DST start/end

2017-09-14 17:51:11 GMT <douglascrp> https://issues.alfresco.com/jira/browse/MNT-15454?filter=-2

2017-09-14 17:51:13 GMT <alfbot> Title: Log in - Alfresco JIRA (at issues.alfresco.com)

2017-09-14 17:51:21 GMT <douglascrp> this is the one I was referring to

2017-09-14 17:51:52 GMT <AFaust> Ahh - so hard conversion errors, not just incorrect values...

2017-09-14 17:53:20 GMT <AFaust> Well, that also happens from time to time if some DST changes are wonky - problem is that it's not always a technical issue, but a political one, e.g. doing stuff on short notice so that updates to DST tables cannot be distributed in time

2017-09-14 17:54:18 GMT <AFaust> e.g. https://www.timeanddate.com/news/time/libya-cancels-dst-switch-2013.html

2017-09-14 17:54:19 GMT <alfbot> Title: Libya remains on Daylight Saving Time (at www.timeanddate.com)

2017-09-14 17:57:05 GMT <douglascrp> AFaust, yes, changing that did the trick

2017-09-14 17:57:09 GMT <douglascrp> but now I have a big problem

2017-09-14 17:57:23 GMT <douglascrp> as all the existing objects are saved as CEST

2017-09-14 17:58:07 GMT <douglascrp> so, if I publish it as it is, only the new objects will be right

2017-09-14 17:58:24 GMT <douglascrp> any idea on how to "touch" those nodes to have the date persisted correctly?

2017-09-14 17:58:53 GMT <douglascrp> AFaust, tks for your help BTW

2017-09-14 17:58:54 GMT <AFaust> No - the objects are saved as ISO8601 strings in UTC. The problems is that they were created/converted from CEST 00:00 local time

2017-09-14 18:00:41 GMT <AFaust> So one option you have is doing a batch update on existing objects, find those objects where CET/CEST ends up at 00:00 perfectly, and shift the value by the combined timezone offset of CET/CEST=>UTC and UTC=>BRT

2017-09-14 18:01:23 GMT <AFaust> A simple touch is insufficient - you really have to change the values...

2017-09-14 18:01:35 GMT <douglascrp> yes, that is what I meant by "touch"

2017-09-14 21:02:13 GMT <AFaust> Hmm - would be nice if Alfresco could update their outdated (and quite misleading) SOLR JVM memory calculation recommendation

2017-09-14 21:02:42 GMT <AFaust> The formula appears to still be based on the SOLR 1 index structure...

End of Daily Log

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