Page 13 of 16

Re: Lesson Schedules Discountinued 2017

Posted: Sun Jan 15, 2017 8:09 pm
by russellhltn
The biggest problem in trying to open source it is that in it's current state, it's using the LDS Account login to locate "your" unit. I don't see the church allowing that to continue if it's made open source. Without LDS Account access, it becomes a issue for members to locate their ward, and to secure edit access for the leaders.

Re: Lesson Schedules Discountinued 2017

Posted: Mon Jan 16, 2017 3:19 am
by marianomarini
russellhltn wrote:The biggest problem in trying to open source it is that in it's current state, it's using the LDS Account login to locate "your" unit. I don't see the church allowing that to continue if it's made open source. Without LDS Account access, it becomes a issue for members to locate their ward, and to secure edit access for the leaders.
Thanks, this answer my wonder. :D
Any way, as my think is to have a "local site", this prevent the need to "identify" the user through LDSAccess.
If you go to "RioneDiVicenza" you will find che lesson's schedule of my unit (if this will be the site).

Re: Lesson Schedules Discountinued 2017

Posted: Mon Jan 16, 2017 7:50 am
by eblood66
marianomarini wrote:
russellhltn wrote:The biggest problem in trying to open source it is that in it's current state, it's using the LDS Account login to locate "your" unit. I don't see the church allowing that to continue if it's made open source. Without LDS Account access, it becomes a issue for members to locate their ward, and to secure edit access for the leaders.
Thanks, this answer my wonder. :D
Any way, as my think is to have a "local site", this prevent the need to "identify" the user through LDSAccess.
If you go to "RioneDiVicenza" you will find che lesson's schedule of my unit (if this will be the site).
Unless their architecture has changed the authentication is actually handled by a proxy the isn't part of the actual tool website. Once the proxy has authenticated the user it sets additional http headers in the http request giving information about the authenticated user (name, ward and stake, and callings they hold). Then the tool website configures itself accordingly. So the tool website doesn't itself have any authentication related code.

Getting it to work for a single ward would require something to hard-code the unit (instead of pulling from the header). More of a problem would be adding some sort of authentication to access admin functions. That would require more changes.

Re: Lesson Schedules Discountinued 2017

Posted: Mon Jan 16, 2017 10:53 am
by russellhltn
eblood66 wrote:Unless their architecture has changed the authentication is actually handled by a proxy the isn't part of the actual tool website. Once the proxy has authenticated the user it sets additional http headers in the http request giving information about the authenticated user (name, ward and stake, and callings they hold). Then the tool website configures itself accordingly. So the tool website doesn't itself have any authentication related code.
Yes, but once the api access is found in the open code, how does the church enforce keeping it out of other people's code?

And, wo don't know what it's written in. It could be written in a language/development stack that's not practical for open development.

Re: Lesson Schedules Discountinued 2017

Posted: Mon Jan 16, 2017 1:14 pm
by eblood66
russellhltn wrote:And, wo don't know what it's written in. It could be written in a language/development stack that's not practical for open development.
I can say with some confidence (but not complete confidence) that the stack is Java/Oracle/Hibernate/Spring deployed on WebSphere or Tomcat. Basically either LDS Stack 2.x or 3.x as documented here: http://tech.lds.org/wiki/Stack_Version_Comparison

Back when the community was at least somewhat involved with tools other than mobile apps, I was the main developer on a tool to maintain test membership data and we used LDS Stack 2.x. The source for the Directory and Calendar were also available and I was fairly familiar with them and they also used LDS Stack. So I'm pretty sure lesson schedules did too. And based on when the lesson schedules was released and given it hasn't been updated I'm guessing it's LDS Stack 2.x and it's using JSF for the view technology. That would explain the problem with upgrading to the current LDS technology stack (as described at the bottom of that wiki page).

All the technologies are open source except Oracle and WebShere. But Tomcat can be used instead of WebSphere and Oracle Express (which is free) is probably sufficient for a single unit version of the lesson schedules.

But since the stack is old it might take some work to get it to work with the newest version of Hibernate/Spring and any other libraries used. And not updating could leave vulnerabilities. The church might not want to release something that could be insecure without additional work even with a disclaimer.
russellhltn wrote: Yes, but once the api access is found in the open code, how does the church enforce keeping it out of other people's code?
That is a possible problem but based on how the Directory and Calendar were written back then there was probably an API specifically for lessons schedule which has or will be shut down. If so, then that isn't a problem. However, if it used both a lesson schedule API and a more general membership API then it might expose the membership API that is still in use. Really it's not that hard to reverse these apis (at least partially) just by examining the web traffic but it could still be a reason why the church might be hesitant to release the source.

Re: Lesson Schedules Discountinued 2017

Posted: Tue Jan 17, 2017 4:30 am
by marianomarini
Forget my tech naivety.
Lesson's schedule is a web page with link to church web resources. If you look to the code of "Lesson's schedule page" you will see exactly this.
Maybe the actual pages are dynamically created from link to a "year lessons" database.
If this is case, Church can provide an ODS (or XLS) file with the data (the links at each lesson) and we can integrate it to our database web site. This way we don't need to write each link by hand.

Re: Lesson Schedules Discountinued 2017

Posted: Tue Jan 17, 2017 6:55 am
by aebrown
aebrown wrote:
dtolputt wrote:I don't read the Book of Mormon does that mean that the whole church is going to stop using the Book of Mormon ?
I'm having a hard time understanding your question. Of course the Church is going to continue using the Book of Mormon, regardless of what any individual decides to do.
Given this sarcastic, fanciful comment, it's a bit ironic that this morning the Book of Mormon has disappeared from the Gospel Library app.

Re: Lesson Schedules Discountinued 2017

Posted: Tue Jan 17, 2017 11:58 pm
by mevans
eblood66 wrote: I can say with some confidence (but not complete confidence) that the stack is Java/Oracle/Hibernate/Spring deployed on WebSphere or Tomcat. Basically either LDS Stack 2.x or 3.x as documented here: http://tech.lds.org/wiki/Stack_Version_Comparison

Back when the community was at least somewhat involved with tools other than mobile apps, I was the main developer on a tool to maintain test membership data and we used LDS Stack 2.x. The source for the Directory and Calendar were also available and I was fairly familiar with them and they also used LDS Stack. So I'm pretty sure lesson schedules did too. And based on when the lesson schedules was released and given it hasn't been updated I'm guessing it's LDS Stack 2.x and it's using JSF for the view technology. That would explain the problem with upgrading to the current LDS technology stack (as described at the bottom of that wiki page).

All the technologies are open source except Oracle and WebShere. But Tomcat can be used instead of WebSphere and Oracle Express (which is free) is probably sufficient for a single unit version of the lesson schedules.

But since the stack is old it might take some work to get it to work with the newest version of Hibernate/Spring and any other libraries used. And not updating could leave vulnerabilities.
Thanks for your explanation on a possible real technical issue. There are many things that seem odd about all of this (and discontinuing the Newsletter). I don't think the directory has been touched much in a few years, either, except for doing the new photo service. I wonder if they are going to discontinue it, too, because of "old technology"? Based on the number of times I have to write down my phone number, email, and street address for church members, it's pretty clear to me that most church members don't use the directory either (web or LDS Tools).

The 750/30,000 logic often times seems to me like they made a decision to get rid of things and then tried to find numbers to support their case. If you view one of the LDS Tech videos about LCR, you'll see that the LCR product manager realized there was an awareness problem with LCR and they weren't getting the adoption they had hoped for. He decided to start marketing it to church members through email messaging and the usage of the tool went up. They saw success in marketing that tool; why wouldn't they expect success marketing the other tools?

And then there's the cost issue. If 750 units were using it and it takes each of them an extra hour to accomplish the task in a different way, that's 750 hours church members waste on administrative tasks because we can't use IT solutions to save time. It's probably more than an extra hour if you add hyperlinks to all the lessons for all the classes (including Primary). Would upgrading the tool to newer technology take more than 750 man hours (development + testing)? That's a decent chunk of time. I work in software and I see a lot of complicated work projects get finished in less time than that and the Lesson Schedules tool doesn't feel that complicated. If you look at the numbers that way, there is a benefit to the cost. And then after you update the app, market it to the ward council members like LCR is marketed to the ward council members. You'd probably see a lot more use if people knew it existed. I'm trying to be conservative with the numbers here (only 1 extra hour per unit) and it sure seems like a compelling ROI to me unless you think a church member's time serving in a calling is worth nothing.

Re: Lesson Schedules Discountinued 2017

Posted: Wed Jan 18, 2017 3:14 am
by marianomarini
Reading this post it seems that "Lesson's Schedule" is an automatic tool useful without any work from local leaders.
This would be true if and only if the lessons fields are filled with LCR data about teachers and hopefully students (so student can see their class).
According with new philosophy in "teaching" in the Lord's way, there will be a needs to use two lessons for a certain topic, or face a new topic according with class member need (not all members live in America facing the same troubles).
About the time spent to useless "administrative" task, in my case I wasted my time spent, last year, to fill the Lesson's Schedule that Non One Member has looked at.
A serious debate about cost/benefit, thinking that is worth of, needs more precise data. The real question is not "How many units" (750/30,000) but "How many members" (?/15,000,000) are using it.

Re: Lesson Schedules Discountinued 2017

Posted: Wed Jan 18, 2017 3:22 am
by marianomarini
The real question is not "How many Units" (750/30,000) but "How many Members" (?/15,000,000) are using it.
Last year I wasted my time to setup "Lesson's Schedule" for my unit and NO ONE MEMBER have use it.
Let Intellectual Reserve, Inc. Leaders decide according with Church policy and available real data.
Our time will be much better spent to find a local easy and efficient way to such a tool, if our member need it.
Sorry for a second post but my connection fail and I've not seen that the post was already sent).