I have changed my old search for AIESEC text to search for .LRN and I have come up with a few open questions or points for discussion.
I am posting them here to get feedback which I will add to the search for .LRN text.
- What does last_modified in acs_objects mean exactly per object?
E. g. for the initial answer in a forum thread: is it the date of the last
answer or the date of this particular message's last edit?
- Add a way to inexpensively retrieve the community_id to which an
object belongs. Currently it is package-specific to figure out to which
community a random object belongs. Note that augmenting ad_conn is not
enough, this problem has to be addressed at the data model level.
- It is recommended that a central table called acs_objects_description
or site_wide_index be added which holds an object's name and a few other
columns which will be of use for the site-wide-package. This table will be
filled by all the packages which feed the search package, usually with
triggers.
- Every package which is "search"able needs a get_url and -
depending on whether there is a central field for an object name - a
get_name procedure on the TCL level. I suggest putting those procedures
into a TCL namespace e. g. search::calendar for a calendar object,
search::cal_item for a calendar item object, search::forum for a forum
object, search::forum_message for a forum message. Currently, the approach
is to use the acs-service-contracts which I find unnecessarily
complicated for this purpose.
- Every package-specific permission type that allows a user to "read"
something must inherit from the site-wide "read" permission type.
- There must not be permissioning islands: a user that has "read" on an
object will be able to see the item in the search results regardless of
private_p or published_p etc. flags.
- Items which a user cannot "read" will never be shown in the search
result regardless of really_public_p etc. flags.
My impression is that finding the "community_id" for a given object_id is the most tricky issue.
I would like this discussion to lead to a tippable decision on how to retrieve the community_id for a given object_id and how to retrieve name and URL for a given object_id and to resolving whether permissioning has no islands and what last_modified means.
Future data model changes may possibly break search: the community needs to
find a way to propagate package changes quickly to the search module. I am not
quite sure yet where to put the helper procs: it may be good to make them
part of the respective package, so that it is clear, that a data model change
may incur a change to the helper proc as well. On the other hand this is
probably a nightmare for the maintainer of the search
package.
