Background- my organisation have a global directory. The Active Directory only stores the employee numbers and employee name. No information about the role title is stored in Active Directory. (I have already built an LDAP query to retrieve all the information from AD, retrieving the role title is my issue).
On our intranet, there is global directory, which shows the role title. Now this is obvious to me that the role title is stored in some other database.(not AD)
I am wanting to write a script (not sure what to use), to pump a list of employee numbers in the search box and retrieve the role title.
Is this possible? I've never scripted anything to retrieve information from results coming from a website/intranet etc. Any guidance will be appreciated, LDAP queries unfortunately was not the right approach for me as the organisation does not store role title in AD. (I have thousands of employees to find and I don't think it's practical to search individually)
Gemmo
I take it you only have access to the front end of this system. It is not ideal, but the only way would be to use web scraping. That is, parse the HTML from the web page.
This method is time consuming to put together and very prone to breaking since it is entirely dependent on how the data is presented on the page. If anything changes, your web scraping can break.
But if you will only need to do it once, it might be worth it. A tool like this one could help you do it. (that is just the first one I found online. There are others, just search.)
But since we can't access this site, we can't really help any more than this.
Web scraping really is the absolute last resort. Any other way to get the data is better than this. Maybe you could even ask the administrators of that system to give you a one-time report of just the data you need to see. As long as they're willing, there's no reason they couldn't give you an Excel spreadsheet with the data.
Related
GOAL:
-To allow the manager to only view the all projects in qlikview, and not edit anything.
-Team members can only see data from projects they are in
CONDITIONS:
-Joe(Team member) can only see data from his projects only.
-Bob(Manager) can see data from all projects in the team, however he cannot edit or make changes to them.
In this scenario, there is only 1 manager, an admin, and many team members.
So I guess the process would be:
Check who the user is (Not sure what to use here. Username/password? Ideally it would be the company email, but don't know if this is possible)
Once it knows who the user is, checks if said person can access the document
If they do have access, it decides what can be accessed. (if manager, can only view all projects, if team member, can only view certain projects)
Display the dashboard.
Right now, the QVW file gets data from a database using OLEDB connection.
Sorry I've only been introduced to Qlikview about a week ago and I've been tasked to get this done so any help would be great.
Thanks.
You can find a lot about QV section access around.
Think your scenario is possible to be achieved using section access. Please read https://community.qlik.com/docs/DOC-1853 for more detailed explanation of section access methods.
Warning: Always have copy of the document without section access!
Just to be sure you are not locked out of the document because if this happens there is no way to open the document
This is going to be vague, hopefully not annoyingly so. I know very little about SharePoint, but I'm asking for someone who's more knowledgable but is under lots of crippling pressure. Unfortunately I'm going to be held responsible for the project (it's due before Christmas!!), so I need to see what I can figure out on my own to help out. Please allow my desperation and helplessness to excuse any problems with this question.
We've created an InfoPath form that generates xml files that will be uploaded to SharePoint. The data from these files will be aggregated and used to generate reports. The biggest issue is that the users will be spread out over three locations, and the info generated from each location needs to be firewalled from the others. But we need the xml files from all three locations to go to the same place in order to make the aggregation feasible with minimal manual work.
I've read something about SharePoint groups (http://technet.microsoft.com/en-us/library/cc262778%28v=office.14%29.aspx) and figured that might be the way of doing it, so long as 1) the xml documents could all go to the same library/repository and 2) that shared repository would only show each group their own documents. For at least two users we also need a master view that shows all of the documents regardless of the group that created them.
That's the main question. Ultimately we'll also need a similar way of storing the generated reports (tables and charts) to the creators of the xml files AND a set of users at each location who won't be able to view or create those xml files. But first things first, I guess.
Is this possible and feasible? Any hints/links that could get us started down this path?
I think in your case the best option is to create a folder for each group, and set permissions on them to allow just the specific group of users to access that folder. The same with a separate library for reports. Then, you'd just setup a list view that flattens the folder hierarchy to view all items at once.
You could also set per-document permission programmatically in an event receiver, however, there's a pretty low limit (search for ACL) on the number of unique access control lists per library (it's 50.000 actually). So depending on the number of XMLs you are going to manage you may reach this limit.
I'm trying to determine the best way to utilize SharePoint 2013 to manage a very large project with a number of hierarchical elements. I've thought about using cascading/embedded group permissions (doesn't appear to be possible), audience targeting (I'm concerned about user's ability to understand and correctly enter the appropriate target audience), using some kind of session variable fed from a SharePoint list to determine how to characterize entries but then I need a way to auto filter them in lists (seems awfully complex and not sure this will even work). So I'm wondering if I'm missing a better way to do this. This being the following:
I have various staff levels: people at the bottom who are located at a site, a person at the site that is the manager, a hub that links various sites, areas that oversee hubs and include an area manager. I'd like these various people to be able to see only whats relevant to them so for a simple example: a list with a calendar view. An area lead should be able to see all entries made by his site leads, while a site/hub manager should only be able to see entries made by people under their respective site/hub. This would work perfect if I could assign groups to groups and then filter the list instead of by [me] by [(some permission filter option)]
There has got to be a simple way to do this, anyone have any ideas? I think I'm missing some capability of SharePoint 2013 to do something like this and thus am making it harder than it should be.
So I am looking at creating a very small app for the town I live in, I would like to offer people the ability to log into a website and create a business listing that would have things like (name, address, phone, opening hrs, logo -image).
I have limited knowledge in sql and creating Databases but am able to with abit of reading and time.. However I would like to know the best approach for storing images.
I am planning on just uploading the image to the webspace and then having a URL link stored in the DB... But not really sure if this is the best option?
So my question first of all, is this the best way to go about it? secondly how could I achieve this?
You've got everything right.
Yes, go for the plain table in the database, contains all the required fields.
Upon inserting another company data, get the autoincremented id, extract logo's filename extension and move uploaded file into a file called "$id.$ext" and you're all set.
How to achieve it - just try some online manuals.
There are plenty on working with database, while handling files is better to learn from the man page http://php.net/manual/en/features.file-upload.post-method.php
I am looking to understand how enterprise search solutions tackle the issue of user-permissions.
My question is on displaying the search results for users. The naive approach would display the search results to the user, and then if the user clicks a document he is not authorized to see, he will fail to open it. However, it is even forbidden to display a document's title or excerpt if the user does not have permission to read it. So do the various enterprise earch engines:
index each document together with its ACL?
index all documents with no permission info, but check each link in every search result to see whether the querying user has permission to view this link?
Option #2 makes more sense to me, but also seems much slower than option #1.
Option #1 suffers from the need to constantly update the changes in permissions on the indexed documents.
I am looking to understand what is the common approach in the existing solutions in the market today. Is there a third option?
I'm surprised to see that this 5 year old question hasn't got any answers, as I think it's quite a common and important problem in enterprise search.
As outlined in the question there are two common approaches to deal with document-level security:
early-binding-security: indexing ACL's along with the content, and
late-binding-security: handling security at query-time, by filtering out protected results
Handling security on content side only is never recommended as at that point in time confidential information might already have been revealed (e.g. title or preview of a document in the search result).
The advantage of implementing security with a late-binding approach is, that it's very flexible, because there is no need to re-index content upon changed ACLs. The biggest drawback however is, that by doing so, confidential information might be leaked via facet values, and it's not possible to retrieve and display correct facet counts. It also more difficult to properly populate the result list and handle pagination. Last but not least, this approach can significantly slow down the performance.
The advantage of implementing security with an early-binding approach is, that it addresses all of the above disadvantages for the price of re-indexing the content as soon as ACLs change. However, leaks are still possible, e.g. when a group membership or ACL just got changed and isn't reflected yet in the search index. To address this gap the two approaches early-binding and late-binding are often combined.
Last but not least there might be a third option, depending on the Enterprise Search Platform you are using: Attivio's Active Security is based on query time joins, which allows to index security information independent from the document itself, but at query time merges the two documents to ensure that only authorised content makes it into the search results.