Imported from previous forum
I hope this error is related to the main one which does not allow member group admins to see and manage their users. I do not see the full content on http://www.fixtradingcommunity.org/pg/structure/tech-specs/fix-version/50-service-pack-2. Even worse, the PDF versions of the specification should be available to all logged in users. This is not the case and the message "(only visible to FIX Trading Community Member Firms and Affiliated Users)" is identical for PDF and MS Word. This has to be changed asap if this means that nobody has access to the specs currently, not even to the PDF versions.
Documents have permissions set at the individual level, so a simple change. They are currently configured that way based on the folder permissions from the previous site, but it seems there was some weird "override" logic based on file type in the old site? If we know the files affected is simply amtetr of changing their ACL settings. Should they be fully "Public" or "logged-in users". If its as simple as everything in that list it can be changed in minutes....
That particular set should now be sorted. Are there other areas where the same thing is likely to have caused an impact, so we can quickly change any affected sections.
If you (or Lisa) can point us in the right direction we can sort his very quicky... in fact Lisa has site admin access so she is able to effect the change directly whenever she sees it. Might be easier/simpler than reporting it even...
It looks like the 5.0 SP2 is still visible to those not logged onto the site. http://www.fixtradingcommunity.org/pg/structure/tech-specs/fix-version/50-service-pack-2
Ken are you guys working on changing those docs to "logged in users" or should I?
Im working on it
Done
>> folder permissions from the previous site, but it seems there was some weird "override" logic based on file type in the old site
Ken, as I recall, on the old site all files and links posted within a Document Category take on the authority settings of that Document Category. The only 'override logic' that I can think of would involve URL links, as the file, itself, is only uploaded/exists on the site 'once', however, we did have the ability for an admin to post the URL to that document within a different Document Category. For instance, the Word .doc file might be uploaded to one working group's document category (with a list of 15 members who can see it), however, we might want to make that same document available to a different work group's members (eg with a list of 25 people). The second WG's members could access the original doucment eventhough they were not in the 15 members with explicitly granted authority to the file itself.
We have the same capability, but with a nuance that should potentially improve things a bit going forward- Permissions are applied at the level of the document and /or bookmark itself, rather than the folder, so the same file can exist in multiple folders without ever being xposed outside the strictes of the applicabel constraints.
The model is much more fine-grained, and can be applied right down to single artefact/single user, as well as for "bundles" of artefacts etc.
Both the files and bookmarks (and everything else for that matter) carry individual permissions (and meta-permissions). The migration has assigned the permissions of the parent folder of each document to the document itself, which negates the need for duplicates of a document to exist in seperate "public" and " private" folder locations. The folders themselves dont have permissions, they are a veneer over the underlying artefacts that allow them to be organised, and a singel file can be displayed in multiple locations, as well as allowing diferent instances of the same file to be given different permissions. Sinnce the permsissions are completely "atomic", any desired combinations can be achieved with a little experience.
Migration of multiple instances from old folders with different permissions does have the implication that we sometimes have duplicate instances of the same document from folder called "public" and "private", for example, which would now be redundant, since a single file can exist in a single location and be visible only to the intended audience. That doesnt stop you putting them in "public" and "private" folders, but this is simply organisation. An excercise to remove any duplicates can be conducted at some point.
If the documnet itself is given an "meta" access permission that includes the superset of groups etc that need to see it, the bookmarks that point to it can be seperatley permissioned, and the links will respect the strictest of all the available access controls, even to the point that a private document can be placed in a public location, and it will only be visible to the people who are supposed to see it. What you see is what you are entitled to see, but nothing more.
We should explore this more thoroughly once things have settled down a bit, as we think it can simplify matters a bit relative to historic practice, whilst meaning that historic practice can still be used in the interim or if they are preferred.
I discussed this in detail with Lisa, and the information from her conflicts, in that she says that in the old site, the document would only be accessible to the people explicitly included within the document folder permissions for the folder in which the document was posted, and only individuals in the original docuemnt groups permission list would be able to see it elsewhere- in Scott's example, the other 10 people would not be able to access the file.
This was rather reassuring, in that otherwise the impication would be that the old sites permission scheme relied on "security by obscurity", and anyone in possission of the url could access it, rather than any direct control on the documents themselves. Lisa assures me that this was not the case.
On this basis, the new sites security scheme provides an identical result, in that the document can only be accessed (even if linked) by people explicitly within the permission scheme associated with that file. ACLs for document libraries can be composed from "meta-acls", created by site admins from the "ACL Groups" option on the Admin menu.
This allows an admin to create a permissions scheme that represents the superset of any of the selected groups, and can span any combination of Committees, Sub-Committees, Working Groups, Document Libraries etc.
When this meta-acl is aplied to the document, it can be viewed by any member who is included within the superset of the designated groups. Bookmarks to the file, or urls pointing to it from anywhere, would apply the permissions however accessed, so that the file is always accessible by anyone within the list, and never accessible by anyone who isnt, irrespective of where it is posted.
So the process woudl be as follows:-
Lets say a document posted within the GTC is to be made accessible to members of the GSC.
The permissions for the document within the GTC (where it is located), are amended to reflect a meta-acl comprising the member of the GTC + the members of the GSC.
The document is still located within the GTC, but a Bookmark, hyperlink, etc could be posted within the GSC, and would be accessible to members of the GSC, but to no-one else who was not a member of either.
Should the URL be e-mailed, the link would only be accessible to people within the relevant permission scheme, and only if logged-in, otherwsie they would receive a generic screem warning them that they need to be logged in and part of the permsission schem in orde rto view the associated content.
Ken, if you're referring to what I said (in conjunction with Lisa's explanation), I believe that has been misunderstood. What I was saying is that all access to documents and URLs were controlled via the Document Category. A document itself could be uploaded into the Document Category of Group A which could restrict authority to Group A's members. An admin could add a URL (pointing to the Group A's document) to a Document Category of Group B which would provide access to Group B's members. (without uploading two 'versions' of the same document) That is different from "anyone in possission of the url could access it".