[OPEN-ILS-DEV] ***SPAM*** Re: questions about testing modifications to database and client

[Ben Shum]

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