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
Related
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.
We are using HP ALM 12.53.193 for issue tracking.
For a progress report of our development activity, I am trying to find out what tickets I worked on within the past month. Primarily, this includes tickets for which my user name was added to the Editors field, or that were marked as Fixed or Closed by me in the given timespan.
I am seeing some promising hints in this forum post that uses SQL to query the AUDIT_LOG table. Likewise, this [sqa.se] post suggests an SQL script for an Excel report.
Unfortunately, when I click New Business View Excel Report in ALM, I am asked to upload an Excel file for some reason, so I am not sure how to proceed from there to entering my SQL.
I have also tried creating a report with the New Project Report command (i.e. I am also ok with a non-scripted solution, if that is the way to go in ALM). However, it seems I can only show the filtered contents of single tables (e.g. Defect) there (the "Cross Filter" feature does not let me choose another entity (e.g. the Audit Log) for cross-filtering my defects with).
How can I retrieve that data from ALM?
I am not entirely sure SO is the right site for this question, although I consider HP ALM a "software tool(...) commonly used by programmers". Please migrate if it is deemed a better fit for another site.
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.
I am working on a VSTO-Excel-Addin (VB.NET) that we are about to sell to different companies.
The addin will (hopefully) be used by a couple of users of each customer. We are using ClickOnce for a web-based deployment.
The addin provides some default-settings - that is no problem with the app.config. User-specific Settings are also working fine with ClickOnce.
However what makes quite some headache is how to store settings per customer. Database-connectionstrings for example cannot be stored on the application-level but it would also be painfull for all users to change the Connection-string manually. What I would imagine is another layer (per Company) where this sort of Setting can be stored.
One alternative would be to create one VSTO-Project per customer but this would bring a lot of disadvantages since we are updating the addin quite regularly.
I would be happy about any ideas!
Regards,
Julian
I would show Excel's built in connection properties dialog and let each client configure this themselves.
You really shouldn't be distributing connection strings for all your clients as part of a shared package. It'll be a maintenance nightmare.
http://office.microsoft.com/en-nz/excel-help/connection-properties-HA010175443.aspx
What about storing the settings as custom properties in Book.xltx and copy it to
C:\Users\username\AppData\Roaming\Microsoft\Excel\XLSTART
This is how you can programatically read and create Custom Properties in Excel.
When a new workbook is created then all the properties from Book.xltx will be available for New Workbook as well. But this solution may not work if the existing workbooks are opened so yo might have to explicitly add these properties when any existing workbooks are opened using the above solution.
Ok, I think I understand the problem. :)
How about storing all the settings in an offsite database that you maintain and using a webservice to allow the settings to be read and set and giving each client a unique license number that would allow them to access this webservice.
That way the individual users would only need a license number to set it up.