On Fri, 2008-08-22 at 15:13 +0100, Tim Chown wrote:
but I assume this has been done in part to test the ipdevinfo beta code? Both pages seems to serve a similar function, one the old way, one (I assume) the new way under development? (The ipdevinfo page doesn't have the Cricket links in place yet)
Your assumption is correct. The link in question was only recently added, and thus pointed to the new /ipdevinfo/ instead of the old /browse/. Hopefully, ipdevinfo will be ready enough for NAV 3.5 in September to point all other old /browse/ links to ipdevinfo too.
The problem is that Authenticated Users hit this permissions issue, but if we try to add |ipdevinfo| into the web_access permissions, it doesn't seem to resolve the permissions problem.
The fact that ipdevinfo have not been added to the privileges table is, however, a bug. The following SQL query seems to fix the problem at our development installation of NAV:
UPDATE accountgroupprivilege SET target = '^/(preferences|status|navAdmin|report|browse|stats| cricket|machinetracker|ipinfo|l2trace|logger|alertprofiles| ipdevinfo)/?' WHERE target = '^/(preferences|status|navAdmin|report|browse|stats| cricket|machinetracker|ipinfo|l2trace|logger|alertprofiles)/?';
Is that link to the newer stuff intended? If so, how should we correct the permissions problem?
Let's just correct the permissions problem. I'm about to update the SQL scripts, so we won't forget this for NAV 3.5.0. Please do file a bug report on this. A bug report would help us remember to include the permissions fix if a 3.4.3 release comes before 3.5.0.