Forum OpenACS Development: Re: FYI: Errors upgrading ]po[ from OpenACS 5.9.0 to 5.9.1

]po[ uses acs_object_context_index in the context of "cost center permissions". Cost centers form a tree (the departments and sub-departments of a company...), and any level on the cost center tree can have privileges associated with it. These privileges affect a user's ability to perform CRUD operations on financial documents related to the cost center. Privileges are inherited "down" the cost center hierarchy. So it's sufficient for a system administrator to have an "Admin" privilege on the top CC in order to be able to perform any action (read/write privileges are sub-privileges of "admin") on any financial document type on any level of sub-CC.

To my knowledge this is correct and documented use of the OpenACS permission system.

]po[ has about 20 files that reference acs_object_context_index.

The right thing is to use

So I understand that OpenACS 5.10 breaks this mechanism? I wouldn't be a big thing, but we obviously wouldn't be happy about extra work related to it.

I've read mixed reviews about the performance of recursive queries in PostgreSQL, but I haven't tried yet. There doesn't seem to be any reason to change, right?

I very much value all the work that you and your team put into OpenACS and the community, so we would definitely accept this change and would work around it. However, it would great if you could check compatibility with ]po[ the next time you want to perform an incompatible change.

Cheers
Frank

I believe that what determines the success of a (web) application is:
1. its functions
2. its user interface

]project-open[ success depends heavily on its super duper richness in terms of functions. It actually is so rich that the majority of users will be more than happy to use just its core/common functions. So porting/updating efforts could (and should) concentrate on these core functions and could somehow leave alone, at least in terms of priorities, not so common, exoteric functions, used by a limited set of users.

But, apart from functions, the user interface also matters, and it matters a lot. And it is not just a question of actual user interaction, how the users actually use the system. Unfortunately it is also a matter of fashion. And here I'm afraid both OpenACS and ]project-open[ fall short. They are still kind of stuck to Web 1.0 style. But Web 2.0 has come, and it has gone too... Now it's time of Web 3.0, see for instance https://www.geeksforgeeks.org/web-1-0-web-2-0-and-web-3-0-with-their-difference/
or
https://nicepage.com/doc/article/20348/web-design-3-0-when-your-web-design-really-matters
Please stay with me, I know that the majority of this is only "fashion"; but it is "fashion" that matters a lot.

Now offering OpenACS or ]project-open[ on top of Docker is not going to rejuvenate the products, neither porting them to the newest versions of their base software components, libraries - it just makes sure they are going to work in the near future for their current users.

But if we want to make sure OpenACS and ]project-open[ will be still used in a future to come, and by new adopters, we need to work heavily on their user interfaces.