Malte Sussdorff

In case anybody is interested, we have developed in the last three years a single page app, primarily for translation and even management but can be easily utilized for other scenarios and project-open configurations. It is written in typescript with the WebixUI Framework and does require project-open 5.1 along with some of our packages as we make heavy use of our documentation based approach to APIs. As part of this effort we also updated project-open 5.1 to run on top of OpenACS 5.10, as released...

Multiple scenarios: You have Business to Consumer projects. So the company name would be the First Name+ Last Name of the Individual. Guess there are Markus Koch in the world than just one. Independent Businesses (legally), but all residing under the same (brand) name. You could attach the country to it, but some businesses are actually picky about the legal entities having the same name. And yes, you could in theory do this with offices, but then the VAT Number would be different per office Actual...

Quick question. The company_name in im_companies has a unique constraint in the database files I have access to. Any particular reason, apart from the reason stated back in 2010 that all ]project-open[ objects have unique constraints enabled on name (like ticket, probably also project etc.)? I understand company_path, but company_name? At least in Germany it is legal to have the same name as a different legal entity if that entity is in a different city. I’d love to change that but wondered if that...

In the latest 5.0.3. version I grabbed from sourceforge I get the following notice: Deprecated proc im_cost_center_read_p used: naviserver_1 | : called from im_cost_permissions 91246 1133571 view read write admin So it seems that im_cost_center_read_p is called from im_cost_permissions .. Is im_cost_permissions also deprecated? Or did you miss to change im_cost_center_read_p to im_cc_read_p there? Not sure if I should open a ticket and if yes if I should open this here or somewhere else.

Yes... acs_object_context_index is deprecated and removed. Then the intranet-search-pg changes without tsearch to use in PG11. That's as far as I got so far :-)

As OpenACS breaks a few ]project-open[ habits (e.g. usage of acs_privilege_descendant_map instead of acs_object_context_index) I need to make a few changes to existing files in ]project-open[. in intranet-search-pg (for PG10 support) I did this by overwriting existing files, as the TTL of that packages files was long enough. But now I face changes necessary in intranet-core and intranet-cost, with a much higher likelyhood of changes in the next releases. Therefore I am wondering if there is a way...

In case you want to upgrade to PG10, here are changes I did to intranet-search-pg based off OpenACS 5.10 diff -r intranet-search-pg/sql/postgresql/intranet-search-pg-create.sql /Users/malte/code/projop/projop-5.0.3.0.0/packages/intranet-search-pg/sql/postgresql/intranet-search-pg-create.sql 351c351 < fti = to_tsvector(norm_text(v_text)) --- > fti = to_tsvector('default', norm_text(v_text)) 371c371 < to_tsvector(norm_text(v_text)) --- > to_tsvector('default', norm_text(v_text)) diff -r intranet-search-pg/tcl/intranet-search-pg-procs.tcl...

Keep in mind the goal.. make it easy for developers. So... if I have a dynfield subtype which explicitely excludes attributes (see attribute type map) and/or uses extension tables (where you could return over 50 attributes, even though you only need 5. But those for 500 rows), it is REALLY hard to judge what comes back. And some values are mandatory for certain dynfield object (sub-)types, while not for others. So your simulation is great and does work. Yet when I publish an API, I would not fallback...