This issue may have a bearing on whether we use Umbraco for a given company or use something else.
The company has both an intranet and web site(s) running on an old bespoke system which is scheduled to be replaced.
Having tested Umbraco extensively and built mock-up sites, I am very impressed with its flexibility, and I strongly suspect it would work for the web estate.
However,the intranet is first to be replaced and, as per an earlier post, the issue is here that that are a number of document types that comprise the intranet, and any one of the employees (and there are thousands) can create, publish and edit their own documents, but can't edit documents created by other users.
Also, they will have logged in to Windows and don't wan't to log in to again to edit documents in the intanet CMS.
The questions are
Can users be automatically logged into Umbraco back-office by intergrating with Active Directory?
If so, can this handle thousands of such users?
Is there any way of preventing users from editing each others' documents (as far as I can see, if we allow users to create, update and publish, they can edit documents created by other users as long as the documents are under their starting node). I suppose we could make a staring node for each user and all their documents go under that - but then this would make the node structure massive, unmanageable, and, I suspect, slow.
Admins should be able to edit anything.
Reading the above back it looks very much to me that Umbraco just isn't suitable for an intranet (and to be fair, it's not promoted as such), but its user access system is it's big failing. and I think it might make it a non-starter....
about Active Directory I answered your question in your 2nd thread here: Umbraco - members creating back-end content.
Regarding your concerns about Tree structure and blocking content, you can restrict permissions for each user to allow or dissalow specific actions for specific node (with / without children nodes).
Of course, it depends from requirements and desired solution. If you want to have shared three, but block some actions for specific users - this is the way. If you don't want to allow other users to even see structure of trees managed by other users - it will be better to create different parent nodes for them and restrict access only to those one.
The same options are visible when you right click on node and choose "Permissions".
Related
Context/Background: I have an iOS app with a Firebase backend. Each user on the app has a couple of public stories or journals. I am working on the v2 of the app and one of the main features of v2 is to give users the ability to publish their stories as static webpages by a click of a button. The goal is to have a journal for a user with a username "johnhouse", for example, be available at www.the-app-domain.com/johnhouse.
Question: How do can I create web pages on the fly from an iOS app? Im not sure where to start. Which online services should I look at?
I thought of spinning up a server and hosting www.the-app-domain.com on it, getting the app to ssh into the server and creating a directory called "johnhouse" (from the example above) inside the website's root directory and then pasting an index.html file inside it, But this doesn't only sound like a bad idea, it also sounds complicated as hell If I were to generate the html files on the app, how would I get them to the server? how would I get them into the right location?
There are a great many ways you might implement this behavior but I'll suggest one.
Consider what this product might look like if the app had no knowledge of how these static pages were published. All the app needs to be able to do is allow users to set which of their stories are published or not and to inform those users of the url at which their published stories will be available.
There may be real advantages to removing the app from your page-creation process.
If you find that you need to make change to the formatting of your pages you can do so without requiring an app update and you can choose if you want to rebuild every page or just have changes apply to new pages. This might be important if you discover that your pages don't render well on some devices or are not indexed the way you would like by search engines.
If you need to change where your pages are hosted you can do so (and provide redirects from the old location) without needing everyone to update to a new app version.
If you need to add moderation or curation of the content you publish you can do so more easily than if clients (your app) have direct control of your site content. This may be important when someone starts publishing SEO spam links to your site, or registers the username admin or login, or publishes a story containing malicious javascript, or publishes content which gets you a copyright infringement notice.
You don't need to give clients direct access to your web server which could allow them to edit each other's content or overwrite your site with their own malicious content.
Since you're already using Firebase take a look at how you might run your own web server as another client of this backend. One which looks for "published" stories (however you identify those in your data model) and generates appropriate pages for them. Depending on the tools you elect to use these could be dynamically generated pages (client side js or a web app) or static pages build by some backend process periodically or whenever stories change and added to a web server. Without any idea what server side tools would be most appropriate for you it's hard to know what specifically to suggest here.
I have an application which is centered around data per 'team'. A user belongs to a team and if they log in they only see that team's data.
However, I now have super users who essentially belong to more than one team. These users should be able to log in to the system and then immediately choose which team they are interested in. From then on they will essentially view/create data against that selected team. They should also have the option to go and change what team they are viewing at any time.
I've established that the user would like to be able to have multiple tabs open and be viewing a different team in each tab.
I'm struggling to work out the best way to accomplish this with .NET MVC while keeping it as stateless and testable as possible.
I've been reading up on the different ways to persist data - session state and cookies seem to get a bad rep in MVC. TempData, ViewBag seem to focus on just persisting data for one request.
I wouldn't have thought that this is an uncommon requirement in an application - are there known patterns for dealing with this in MVC which I have missed?
So far I'm trying to create a partial view which I can show on each page to let the user see what team they are viewing the site as, and change it from there.
Any advice is appreciated!
If you want to let your superuser view multiple teams data then you'll want to pass the team information in on the request, on the query string or as something that looks like a restful url:
/blueteam/members
In fact it would be extra work to track this in a stateful manner as you'd have track user, team, and ui element when a superuser can view multiple team data at once.
I'd say passing the information in on every request is a pretty standard approach to your situation.
The tricky part of the stateless approach is decorating all your internal application links with the team information without too much extra work. Relative links can be your friends here. So a link to the bug page for a team might be to simply "bugs", picking up the team name higher in the uri path. If you are creating something that looks like a one page application it's easy enough to store the team info on the client.
If you don't want team members to see data for other team members, you can set up guard functions that check for team membership for certain classes of users before rendering a view.
so I developed a small Neo4j database with the aim of providing users with path-related information (shortest path from A to B and properties of individual sections of the path). My programming skills are very basic, but I want to make the database very user-friendly.
Basically, I would like to have a screen where users can choose start location and end location from dropdown lists, click a button, and the results (shortest path, distance of the path, properties of the path segments) will appear. For example, if this database had been made in MS Access, I would have made a form, where users could choose the locations, then click a control button which would have executed a query and produced results on a nice report.
Please note that all the nodes, relationships and queries are already in place. All I am looking for are some tips regarding the most user-friendly way of making the information accessible to the users.
Currently, all I can do is make the users install neo4j, run neo4j every time they need it, open the browser, run the cypher script and then edit the cypher script (write down strings as locations) and then execute the query. This makes it rather impractical for users and also I am worried that some user might corrupt the data,
I'd suggest making a web application using a web framework like Rails, especially if you're new to programming. You can use the neo4j gem for that to connect to your database and create models to access the data in a friendly way:
https://github.com/neo4jrb/neo4j
I'm one of the maintainers of that gem, so feel free to contact us if you have any questions:
neo4jrb#googlegroups.com
http://twitter.com/neo4jrb
Also, you might be interested in look at my newest project called meta model:
https://github.com/neo4jrb/meta_model
It's a Rails app that lets you define via the web app UI your database model (or at least part of it) and then browse/edit the objects via the web app. It's still very much preliminary, but I'd like to be able to things like what you're talking about (letting users examing data and the relationships between them in a user friendly way)
I general you would write an tiny (web/desktop/forms-)application that contains the form, takes the form values and issues the cypher requests with the form values as parameters.
The results can then be rendered as a table or chart or whatever.
You could even run this from Excel or Access with a Macro (using the Neo4j http endpoint).
Depending on your programming skills (which programming language can you write in) it can be anything. There is also a Neo4j .Net client (see http://neo4j.com/developer/dotnet).
And it's author Tatham Oddie showed a while ago how to do that with Excel
What is the best way to store a task for multiple users in TFS 2010 ? I can only assign one for one task.
(for example: when I plan a demo to all developers)
(this is a scrum Msf Agile project, where the task is part of a user story)
I'm sorry to tell you that you can't assign multiple users to a single work item out of the box; At the same time, I do not recommended trying as this, as it does not fit the model in TFS. The conventional / recommended way to handle this type of scenario is to create multiple tasks; one for each developer in this case. You can easily accomplish this by copying a set of tasks using MS Excel. Another option (given the example you used) is to create a "Meeting" work item that has multiple drop-downs - one for each person that would attend meetings like for a demo or a technical review.
Yet another option is to create a custom control to format and store a list of users. This would likely be relatively complex to maintain, as you have to distribute it to each user's machine (it will need to be installed locally), and last I checked you would need 2 versions; one for the Team Explorer user interface and another for the Web Access tool that most people use to create work items from a web page on their TFS server. Future updates to TFS could possibly break your custom control. It is rarely worth the effort. Another downside is the you would likely be limited by how you can use MS Excel to work with the data you store in the field that the custom control works with. If you want to look into this further you can find some examples in the following CodePlex project: http://witcustomcontrols.codeplex.com/
You might consider your true goals in tracking such things as meetings and other items you want to assign multiple people to. Tasks are the heart of tracking progress of user stories in the MSF Agile Template. Tracking meeting attendance does not typically relate directly to a User Story, for example; so it won't typically assist you to determine how much close you are to being "done" with a User Story. If you want to take advantage of the existing reports, then you should organize your tasks so that they roll up as child work items to User Story (or Bug) work items.
Short story: you can't. Work items in the Process Template of Microsoft are designed to target nobody or only one User.
Now you can customize the Process Template to change this.
Take this post for instance, the customization works for group. But I don't recommend you to do so because TFS is basically not designed for that and you may end up disappointed.
My site lets people create database entries (which most rails apps do), and I realized that there's a huge drop-off from landing on the site to actually signing up to try it. Basically the service lets users build their own document by combining different components. I'm thinking about adding an interface where visitors who are not yet registered can try out the features (building stuff) and ask them to sign up at the last stage, when they're about to publish their document.
First thing that comes to mind is use HTML5 local storage, but then another idea came to mind: maybe I could create a temporary user whenever a visitor tries out the features, and then later remove them from the database if they don't sign in. I'm not sure if this is safe, but this seems like it might be easier than dealing with all the local storage issues.
What would be the best practice for this type of situation?
HTML5 storage would be an option, tho most likely a lot of client side coding.
Other options would be to have a duplicate table of these 'demo' documents which you can clear every now and again for users that did not sign up. You could also just store the document in the user session, as you don't need it permanently stored, and then store it in the database once they have signed up.