Student information system candidate

Hey, for SIS, I suggest we try GibbonEdu, instead of openSIS and RosarioSIS. Both are good in many ways, but for openSIS, the community version has too much restriction and RosarioSIS has issues with design components. The web D team told me that the div classes are not organized to handle CSS properly. We probably need to do a lot of JS work, if we stick to it.

Though I prefer RosarioSIS for its compatibility with PostgreSQL, it seems like Gibbon is our best bet. Given that it stems from HK and Aussie backgrounded team, it even natively supports British GCSE grading system. If we really target for British accreditation sometime in year 2026, I believe it fits to many of our needs without extra dev work. Plz see below docs, extensions, and Gibbon’s community for more information.

(They also use Discourse for forum and ERPNext for docs.)

One thing I like about Gibbon is that it supports Data Admin that I can send any query for custom view. Not sure how robust its API, but if it fits, we can display student performances on SIAI webpage. Together with headless Drupal, a X-Y bubble chart(like XY Chart with Date-Based Axis - amCharts) should be enough to show why we emphasize math / stat foundation courses for later computational extension courses like ML, DL, and RL.

Not just because of GCSE, but due to the fact that Gibbon runs with several tech platforms that we all agree to adapt is a kind of signal that they also spend time and effort to carefully choose what and how they run.

As suggested the other day, for the choice of an open source for a company’s essential operation, it is always important to test each solution by following three criteria:

  • Customizability
  • Extendability
  • Support availability

For CMS, for example, we all agree to move away from WordPress, largely because of its spectacular failure in terms of extendability. @KeithLee has built wonderful optimization with WordPress and some customizations that he implemented are beyond my imagination. But even if we go full headless, it still won’t be easy to add what we want.

The same goes with the choice of SIS. I actually want to go for enterprise level paid solution, but it’s not like we are going to have over 4 digit number students in every year. Open source with some internally driven customization is unavoidable for our case.

In that regard, OpenSIS does not provide any support for the community version, and customization and extension are largely limited. I remember @KeithLee complained about PHP8.3 incompatibility. Didn’t you have to install it on PHP8.0? Was that PHP7.4? For grading system mod, @catherinemaguire had to spend hours if not days. It still needs more work, because of dependencies between DB tables, but we don’t even have documents where and how to fix that. All these have to be trial and error to large extend.

RosarioSIS is much better when it comes to dev stacks, but I personally did not like Flarum-based forum that the business is operated on. One way it tells me that the team is heavily invested in PHP, so PHP version compatibility won’t likely be an issue, I get that. But, the team probably does not know how CSS can be implemented for different div classes. These are kind of ‘No Go’ signs, from a dev perspective. Though I am no dev myself, this is now common practice among all of us in code sharing. I can understand why @KeithLee was a bit adamant about this solution, probably due to PostgreSQL compatibility, but except tech stack advantage, I do not see any more merit. The dev guy probably has not closely worked with web designers in his career.

For Gibbon, on the other hand, I can totally see that the system is carefully designed. This is something we call enterprise level services, based on my experience with other $$$ services. The fact that GCSE along with other credit system is available as grading scale options already tells me how much business consideration has been invested to the system, on top of tech stack issues. It also provides native support for Google/Microsoft Auth, which wasn’t the case for the other two. When we rejected Flarum and eventually decided to run Discourse despite some extra hardware costs, we also paid similar trial-and-error cost. Platforms that natively support desired features usually cover other necessary functions. Overall, the way they operate, the tech platforms they choose, and how the codebase is designed tell a lot about the quality of the solution. I would stop arguing about corporate solution, if we go for Gibbon.

Our next discussion for the choice of open source will likely be internal ERP, as Gibbon’s staff functionality is limited to school faculty only. (We might still be able to use its faculty application function.) I suggest we base on the same rule for the choice of ERP solution.

@ethanmcgowan though I agree with you on almost all points, I just want to add a comment about ‘enterprise level solution’

For Gibbon, on the other hand, I can totally see that the system is carefully designed. This is something we call enterprise level services, based on my experience with other $$$ services.

If it were to claim that, I think they should have more DB options. Mere MySQL support tells me it still is an open source solution, and this is probably why @KeithLee rejected Gibbon at first. Just invest two weeks in next summer, when we are more free. It is not a grand system, and shouldn’t be that difficult.

One more vote on Gibbon here.

We might have to do some mod work on transcript for PDF, but at least I don’t have to modify grading scale like I did for OpenSIS. The UI components are indeed more ‘cooperative’ than RosarioSIS. As long as it saves our total investmet in time, I am OK for this new tool.

I also agree with @ethanmcgowan 's point on open source choices. I am weighing between ERPNext and Tryton for now, just to share. ERPNext is a lot more than simple document tool, as it turns out. I will give you a better summary when time comes.

Both ERPNext and Tryton are based on Python. As we have seen with ERPNext, Postgre is compatible for both, but with Python, if we are going to use full blown ERP, I suggest you double check with server compatibility to see if it won’t affect parallely running PHP stack solutions. Otherwise @KeithLee will have sleepless nights for weeks.

In fact, if we were to pull it out from cloud, I suggest to dockerize it and run it in the same server as Discourse. With the Nginx proxy at front, two docker instances are not any more than two internal ports for listening. Given the quizzes for Discourse membership, this server will hardly likely be busy. ERP is only for us, so shouldn’t fight for much resources.

@catherinemaguire when you test it, plz also check Rocket.Chat availability. With Rocket.Chat app and push gateway, I think we can safely retire MS Teams and rely on joint operation of ERP, Moodle, and Discourse with a single chat app’s push. It will be nearly identical to our early days with Slack or Whatsapp, but now will be fully integrated. With API calls, it is only matter of time to integrate Drupal and ERP. We can make writers come to ERP, not Drupal website even.

@davidoneill If we are really able to centralize everything to the single ERP, Gibbon’s Data Admin might not be necessary. ERP should handle all. But that integration should take so much time and effort. The fact that both of ERP choices are based on Python might help us in customization, but I doubt we will have time for that, at least for the next a couple of months.

Now that we all agree with Gibbon, I will share more details to design. Like we outsource design, at some point, we should seriously think of outsourcing tedious dev jobs.

Speaking of ERPNext, I vaguely remember its Education module, so I just paid coffee time to look thorugh its docs.

I feel like I found a gem in my basement. We might not have to run Gibbon. I will dig into it tmrw. @catherinemaguire @davidoneill Whether we use Edu module on ERPNext or Gibbon, I agree to pull it down to our own server.

guys, I have wasted a day without any success in installing ERPNext. Though I learned a lot about this solution. Guess it will be a tough battle btwn Gibbon and ERPNext’s education module. In general, we need ERPNext no matter what SIS we choose, so I will try one more day, but you guys gotta do further testing once it is running on the local server.

The ERPNext is up and running, but not entirely sure if it is right to run that platform as our base for all services. As @davidoneill suggested earlier, I also looked into the possibility that ERPNext might be the ultimate solution to integrate all our working platforms, but I now go through thought experiments on multi-site version Discourse as an alternative.

Before we go any further, it seems that ERPNext is way less well maintained than Discourse, when it comes to handling main Docker image and controlling additional plugins/apps. With Discourse, all we need is just a 10-min downtime to add more plugins. It’s cumbersome, but I do not have to worry about anything at all. On the contrary, for ERPNext, simple docker compose does not complete website configuration. I have to go into the docker and gotta do a lot of further configurations before I actually can see the website. There will be time that we have to update docker images, which requires me to run docker composer again. Over the past few days, I saw that it’s likely that the newly composed docker loses all custom configurations. I might have to re-do everything, depending on what I do with the re-composition.

It’s not like I have to do a lot of custom configurations, and in all intenses and purposes, I just have to update the custom docker image based on what I have now, so it won’t be a big deal in the end, but I am just saying that the system matureness is quite noticeable between ERPNext and Discourse.

Though as I hoped to integrate all GIAI operations with SIAI’s school ERP, I don’t think ERPNext provides full integration out of the box. We likely have to run two ERPs for GIAI w/ daughter companies and SIAI’s students. For the later function, the earlier introduced Gibbon Edu might be an easy solution to implement. The design is not in cutting edge condition, but it has all we need, or as @ethanmcgowan said, more than what we need. You guys can take a look, and let me know.

I also have docker-launched Rocket Chat’s community version, the free & self-hosting variant w/o custom options. It does not seem to have out of the box solution to be integrated to ERPNext. Discourse provides two options, one with multiple chat integration by Discourse team’s plugin and the other with community plugin for Rocket.Chat SSO.

You can take a look and tell me what you prefer the best. I personally like the idea that we can set up a completely different chat database (and it is internal!), and since Rocket.Chat uses MongoDB, it’s likely way faster than chats from Moodle and Discourse, both of which rely on PostgreSQL. ERPNext is based on MariaDB, so it’s performance for chatting support will likely be the worst.

Performance might not be a significant factor as we are unlikely going to extensively rely on chat as much. When it comes to functional support, Teams is far better. Teams’ chat is a standalone forum for each room. Other chats are just chat with some extensions.

In the end, we might be better off to stick to MS Teams, or rely on Discourse for Kanban and chat. From sheer tech stack point of view, Discourse + Rocket.chat could be the best solution by following reasons:

  1. Discourse has (not native but still functioning) app
  2. Discourse is running on an easily controllable Docker instance
  3. Discourse provides easy integration with Moodle and Rocket.chat (+ not perfect, some MS Teams)
  4. Discourse is programmed on Ruby on Rails, probably the fastest possible forum platform by tech stack point
  5. Rocket Chat uses MongoDB, and it can be connected to Moodle by a plugin
  • we need ERP just for book keeping, not as a granular solution.

I might want to stick to ERPNext as the range of API solutions provided by that is surprisingly versatile. But somebody has to pay money/time for dev work for that. And, remember none of us are hardcore dev.

Be honest, I think it is just better to have our own ERP with Frappe’s chat app. After all, that’s all we need to run our platform. The only battle that we have to overcome is the chat integration, assuming that inter-ERPNext communication between GIAI and SIAI’s student portal will be easily supported.

I am just wondering why you want to keep the chat function integrated. Many educators remove private chat options to reinforce student activities in open forums. After all, this is exactly what we do now. We minimize internal chats and stick to open discussions for whatever the purposes that we have discussed for the last few months.

What I suggest instead is just to keep our chat within MS Teams. It is much simpler, and it also helps us to avoid dis-connection during server downtime. Even for Kanban boards, I am not sure if we can be better off with ERPNext. I am not saying MS Teams is better, but it is an integrated solution. We do not have to worry about push notifications, for example.

Think of cases where we need chat functions the most. Here in Discourse, we actually have to encourage more forum discussions. In Moodle, for SIAI students, the situation isn’t that diffrent. You might be prejudiced to Asian students’ preference to private communications, but without chat, I am sure they will committ more to the forum. If not, it is only their loss.

In short, there is only one place we need extensive support for chat, which is our workspace. With that in mind, let’s think of the best choice of company and school ERPs one more time.

@KeithLee I feel you. Must have been crazy difficult with the setup. Usually that’s the hardest part.

For the school ERP, I again want to push forward Frappe/ERPNext’s education module. I do agree with @KeithLee that we do not want to exploit too much of our time for dev work, but we are a team of geeks that we need so many persoanlizations. Why do we decide to move away from Teams from the beginning?

We all need math equations with LaTeX support, but neither MS Teams nor any MS Office Suites support that, which I remember was an initial motivation. After that, the discussion soon has become overwhelmingly stacked with all our complains on zero customizability of MS Office.

Given that, I am well aware that Discourse, Moodle, and Rocket Chat support LaTex out of box or with a plugin. Does ERPNext provide that? With a few more lines of code, the answer is yes. - Math in markdown - Frappe Framework / Website - Frappe Forum

The kind of customizability and extendability that we can see from these open source platforms outweigh the trouble that we go through today. Just by the fact that we can create an announcement in student portal with math equations, if we go with ERPNext, I am already deep into this customizable solution.

No solution is 100% perfect. We have seen already with the most used office suite in the world, MS Office 365. Had it supported math by LaTeX, the school operation with Teams would have been far more easy. Remember our battle between Moodle and Canvas LMS? We eventually choose Moodle despite the worse performance, largely because of extensive customizability.

I am not going to say open sources are always the best, but with free minds like us, we are better off to have full monitoring in almost every choice we make. In that regard, I again vote for ERPNext’s education module for student portal. For chat, I agree with @catherinemaguire that we probably do not need it on Discourse, but for Moodle and ERP, we’d better spend some time to build the right solution. Then, it becomes our tool, not somebody elses.

@KeithLee you worry too much about the docker. Just commit the docker image, add a tag for versioning, and push it to our git, or keep it in the server. As long as we do not need to deploy that image to multiple servers, we likely do not need to push it to the git. I also prefer to keep our git just for DS codes. Chunky container images like that will only make the git crazy heavier. When time comes, we should split the git to two parts.

For the container update, you just need to create another Dockerfile, as you know. I guess the Frappe/ERPNext community is full of dev. Once they are in CI/CD, dev people hardly care about complicated installation steps. I understand it was painful to do custom installations meeting all our needs, but as long as we have a working system, it’s not something we have to worry about anymore, like dev don’t.

For the choice of school ERP, I also agree with @davidoneill. After all, this is exactly the kind of break that we expected, but I can see the benefits once we overcome. For chat, I can see @catherinemaguire ‘s point, but we still got to run anything that supports LaTeX. Teams is our last resort. Since Discourse and Moodle provide plugins for Rocket.Chat integration, as @catherinemaguire said, the only battle left for us is to integrate Rocket.Chat and ERPNext. There must be webhooks sending push noti, so Teams’ workspace part can be replicated with our own customization. I prbbly miss file sharing and F2F video call options from Teams.

I also agree with @KeithLee that MongoDB should perform way better than PostgreSQL and MariaDB. We are data scientists that we know what DB tech is the best fit for each function. With the solution like Rocket.Chat available, it is hard for me to compromise with basic solutions like Teams. You guys can sleep on it, but I go with @davidoneill that customizable options are always the better. Just sleep less for a few nights, then we don’t have to complain anymore.

Out of all that, isn’t Frappe/ERPNext based on Python? The language that we prefer way more than PHP? Just a thought.

OK. Fine. I just had too much trouble with a bunch of tedious installations, but I can see points raised by @ethanmcgowan @davidoneill. Just so you know that Rocket.Chat will not be integrated as closely as current Teams to our workspace and Frappe Chat for ERPNext. For that, I think we really should pay $$$ or days of sleepless nights for dev work.

Despite easy integration of Frappe Chat to ERPNext, I also prefer Rocket.Chat’s wide range of connectivity with Moodle and Discourse + customizable options. And, if we use Frappe Chat, the ERP database will soon be overwhelmingly large. Let MariaDB and MongoDB do what each does the best. Given that, let’s just pay some extra $$$ and/or :timer_clock: for Rocket.Chat and ERP integration. We can apply that to both student portal and our own ERP.

There are two Frappe/ERPNext options for chat.

When it comes to functionalities, Raven is more like Slack, but Frappe default chat looks much more limited.

Guess integrability with Moodle and Discourse isn’t an option with neither of them, I guess we don’t have to look them as options, but I am just sharing because this will be an easy solution for us.

Rocket Chat seems buggy and require a lot of customizations. Once we set up Drupal, I am done debugging. You guys gotta take over.

I can now see that Frappe/ERPNext can serve multi domains with a single database. Conditioning on $host, we can differentiate Favicon images and initial landing pages. We can assign customized login pages for SIAI students while keeping the same service. Assign different roles and permissions to students should be enough.

Likewisely, we can also serve application pages to SIAI and GIAI staff, all to different URLs.

Overall, I think Frappe/ERPNext is the one-size-fits-all solution for us. @KeithLee never has to worry about revenue allocation, @ethanmcgowan never has to spend extra hours for consolidated financials for all three legal entities in Ireland, Swiss, and in Korea. Extensions to the US, and collaborations with the EduTimes teams can also be organized up to the level that we have never seen, which will minimize @davidoneill 's communication costs.

Frappe Drive can surely replace Sharepoint that contents and design teams no longer have to rely on each team’s image folders.

Not sure what other functions we can find useful, but at least we don’t have to discuss which SIS and/or ERP we should choose. This is the ultimate solution for us.

So we may declare EOL for MS Teams dependency by Nov 2024? I think we can safely expect complete transition no later than Dec 2024.

As said, the only battle left for us is Rocket.Chat - ERPNext bridge, but for this, I suggest we stop at simple webhooks. It’s not like we get huge benefits even if we make it native to ERPNext.

With some code work, I think we can use Frappe Raven’s shell with Rocket.Chat’s mongo DB, which essentially be the best of both worlds.

For this, I will invest my Christmas break. If the merge works perfectly, Rocket.Chat frontend design may not need imminent attention.

Seems like we are all set for major operational handling. For more details of ERP, let’s create another thread.