Some thoughts below based on what I know so far with my very limited
poking around...
On 11/15/2011 7:01 PM, Scott Prater wrote:
I'm working on the patron statistical category enhancements. I made
the changes to the database, adding a few columns and a new table, and
I updated the install scripts to add them to the database with a fresh
install.
Question 1:
Do I need to run any script(s) to update a cache of database objects
if I make changes to the database, in order for those changes to be
picked up in the controller and view objects?
I don't recall having to do so in the past when I toyed with adding
additional database fields to the fieldmapper in fm_IDL.xml. I may have
restarted opensrf services though.
Question 2:
So far, I've modified stat_cat_editor.js (the controller, I presume)
and stat_cat_editor.xhtml (the view), as well as my
locale/en-US/lang.DTD file to include some new label entities. Am I
missing any other pieces here, in order to connect the interface to
the database?
Sounds like a good start to me so far, but I haven't inspected that
layer of code too closely before.
Question 3:
Is there any developer documentation on the permissions architecture
for Evergreen? I can infer some things from the code; are
permissions set at the table level, or at the column level?
Not too sure what table vs. column level means, but Evergreen
permissions are quite interesting. They can be assigned on a per-user
basis or a per-group basis; and also granted on a per-user basis by
other users too. In the database, most everything is contained with
tables part of the "permission" schema. The permissions themselves are
listed in the "perm_list" table; the IDs are specific and the first 1000
are "reserved" for core Evergreen functionality as far as I'm told. All
of our custom permissions start at 1001+. Permission groups (user
groups) are defined in the "grp_tree" table. Then in "grp_perm_map",
each permission group can be assigned all the various permissions. The
"depth" value on that table refers to which level in the org unit
hierarchy (library structure) that permission applies. The "grantable"
boolean there describes whether it allows users of that group to grant
the permission to users of other groups. That's where the
"usr_perm_map" starts to come into play I think - on this table you can
assign specific permissions to specific users similar to how groups are
done. So if you're creating *new* permissions, then presumably, these
would need to be written into the perm_list table and then associated
with the staff accounts (perhaps the local administrator one) via the
grp_perm_map entries.
Question 4:
Is there a way to refresh the page in the xulrunner client, after I
make a change to it on the server?
I believe this is where logging out and completely closing the client,
then starting it back up brings in fresh changes whenever we've done
changes to the different page interfaces of the staff client. Also,
sometimes we've found that using the "Clear Cache" is necessary too.
That's under Admin --> For developers... --> Clear Cache (but that's
been less necessary recently).
I'd love to hear about the tools and/or workflow other developers use
to make and test changes to the interface and the database.
thanks,
-- Scott
--
Benjamin Shum
Open Source Software Coordinator
Bibliomation, Inc.
32 Crest Road
Middlebury, CT 06762
203-577-4070, ext. 113
