http://bugs.webwork.maa.org/show_bug.cgi?id=3454
Mike Gage <gage at math.rochester.edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aubreyja at gmail.com
--- Comment #4 from Mike Gage <gage at math.rochester.edu> 2015-09-21 13:57:20 ---
First the items where I think there is complete agreement:
The versions of the union macros in the macros/CollegeOfIdaho should be removed
in favor of the ones in macros/Union. Just make sure this doesn’t damage
CollegeOfIdaho problems.
Should many of these union macros be transferred to webwork/pg/macros? That
would be ok with me. They are pretty widely used and I believe that it’s only
the history of development that and inertia that has kept them in separated.
--------------------------------------------------------------------------------------------------
allowing ../
I take it back about not being able to reach files one directory up.
while ($PGfile =~ s![^/]*/../!!) {}
will allow ../included-text.pg to remain unchanged but will change
Library/../included-text.pg to Library/included-text.pg and
../../included-text.pg to ../included-text.pg
This means that you can go up one directory but not two. Very clever -- I
didn’t
catch that when I first read the code. We might be able to use this in some
other places where
we are trying to improve security by preventing instructors’ access to files
outside
their course directories or specifically allowed directories.
-------------------------------------------------------------------------------
operational differences between includePGproblem and includePGfile:
includePGproblem() was added long after includePGfile(). One of its
significant differences was that it was meant to allow the inclusion of entire
PG problems which contain DOCUMENT and ENDDOCUMENT statements as opposed to
file snippets which did not. To date it’s main use -- in fact as far as I can
tell it’s only use -- has been to redirect problem references in the OPL from
stale questions that have been removed to active questions which are being
maintained. The other two difference between includePGfile and includePGproblem
is the way that the path to the target file is determined and whether or not a
new PG_alias object is created.
A future use of includePGproblem might be as part of includeRandomProblem()
(it’s not clear to me how the DOCUMENT/ENDDOCUMENT issue is handled in the
current version of this macro) and as part of a scaffolded problem that uses
other existing .pg problems. This second use overlaps with the some of the
features of JITAR so that should be considered as well.
-----------------------------------------------------------------------------------
The larger purpose of all this discussion:
Bringing up the history is relevant because I’m trying to review some of the
features (macros and other wise) that have been added over time and in some
cases rewrite them as if we had planned and coordinated all the features in
advance. :-) It’s a delicate problem which is why I’m devoting so much time
to this bug report and why I appreciate the responses. I think it will be
useful however for those authors who have not lived through the developmental
history of the PG language and find some aspects of it quite confusing. (I’m
also bemused by some aspects of WeBWorK despite realizing the historical
reasons for its idiosyncrasies.)
------------------------------------------------------------------------------
RESOURCES and PGalias:
#RESOURCES and parts of PGalias are addressing the same problem of how to keep
track of auxiliary files.
#RESOURCES, I believe, is a low tech alert for humans maintaining the OPL that
other files are involved.
PGalias is about half completed and is a more ambitious attempt first to keep
track of all the external resource files being used (possibly including macro
.pl files) and then to use that knowledge to automatically handle auxiliary
files when moving a .pg master file from one location to another, or when
exporting that .pg problem file so that it can be downloaded for safe keeping
or to be shared with a colleague etc. Currently PGalias keeps track of .png
and .html files but not much more and I intend to add other file types this
semester. I’ll include other .pg giles which may be a partial answer to the
path problem in this thread.
With luck I’ll also start building tools for allowing export and movement of
.pg files with all their accompanying auxiliary files -- there are going to be
more qusstions of this type. The temporary editor mode already made some steps
in this direction.
https://github.com/openwebwork/webwork2/blame/master/lib/WeBWorK/ContentGenerator/Instructor/PGProblemEditor3.pm#L1227
and a see a note there suggesting that we abstract that routine to Utils::
copyAuxiliaryFiles.
I believe that the way that PGalias is currently used in includePGproblem()
constitutes a bug -- or at least a missing feature. When one returns from the
included question the original PGalias object should not just be reinstated but
should be updated from the object that was passed to the target problem (and
presumably modified there). I don't know whether all of the information should
be translated back or just some of it.
I welcome additional suggestions for how best to do this.
-----------------------------------------------------------
LibraryBrowser and -text.pg files:
I believe the library tags inserted in the -text.pg files prevent them from
appearing in the OPL database and also prevent them from being displayed so
they are not listed during a search using subject/chapter etc. I thought I
might be able to reach them using the OPL directory button to search the
directory tree directly but they don’t seem to be displayed via that method
either.
Before changing FileManager perhaps we should see whether augmenting the
PGalias capabilities for copying auxiliary files is enough.
There may be other reasons for augmenting or limiting FileManager’s reach.
Release/2.11 blacklists course.conf and simple.conf access to ordinary
instructors (permissionLevel=10) but allows it for admins (permissionLevel=20)
because, with some thought, one can gain unrestricted access to the host
computer given access to those files. This is not a good idea -- particularly
for those running a hosting site for a large number of instructors and their
courses.
------------------------------------------------------------------------------
Defining flile paths:
The last issue is the one of defining the path.
(1) The use case for redirection (where includePGproblem is used at the moment)
is substantially different from the other cases. The path to the target file
has no relation to the path of the current .pg file other than that they both
use the same toplevel template directory. One can’t just call includePGfile()
with a file name such as ../../../Library/path-to-new-file since one can go up
at most one level. Besides that kind of addressing is awkward and error prone.
So perhaps for this we should not try to combine the two macros. Perhaps
keeping the changing the name for includePGproblem to something indicating
redirection might be useful to avoid confusion for authors -- I find myself
having to look up how these macros are called each time I use them. And keep
the address mechanism as it is -- namely the full path relative to the template
directory
(2) The argument that including .pg problems or snippets should behave much
like including .png and .html auxiliary files makes sense to me -- and it will
be much easier to create the same behavior if I add .pg to the file types that
alias() and PGalias() handle so I’ll do that. John Jones has already added .pdf
and I think I’ll add .svg as well. After that’s done we can revisit this
issue.
(3) I think you are right that the command line interface is not defining
fileName and templateDirectory appropriately. I’ll look in to that and see if
I can make changes there that will fix the problem that arises when I try to
automatically check the OPL for questions which cause warnings.
(4) Between 2 and 3 I think we can keep the current version of using paths to
the target file which are relative to the directory containing the current .pg
file. This will work for most use cases but not for the redirection case
where I think we need a separate macro. I’ll let you know what I find out as I
continue to improve the renderProblem client.
---------------------------------------------------------------------------------------------
What I see as action items after all this discussion:
1. Clean up macros/CollegeOfIdaho -- John Jones and Robin Cruz can you take
care of this at some point?
2. Move some/all of the unionMacros which are widely used into pg/macros? Is
this a good idea? Davide do you have suggestions for which ones should be
moved?
3. Improve PGalias and the renderProblem client to better handle auxiliary
files. I’ll undertake these tasks since I’ve been working on them anyway.
4. Think of an alternate name for includePGproblem() when it is used for
redirection. I’d kind of like to see this change made to reduce confusion in
the future but I could be talked out of it.
More comments?
--
Configure bugmail: http://bugs.webwork.maa.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.