Some CMIS methods return a username, for instance:
Request: Document -> cmis:lastModifiedBy
Result: nraoul42
Is there any way to get the "pretty name" of the user, using only CMIS?
For instance Nicolas Raoul instead of nraoul42.
I think 100% of the ECM products store username with both a machine-oriented and a human-oriented form, so that is a feature that CMIS might have implemented.
Not all ECM products can provide human-readable names. In some scenarios the ECM system only deals with user ids while the rest of the user data is managed in a LDAP system or something similar.
Some ECM systems provide human-readable user names as CMIS extensions, though. But there is no standardized way to retrieve human-readable user names.
Related
I am setting up a website as a volunteer for a scout charity. As part of the web functionality we will be storing email addresses and names in a database with password hashes and some other info such as creation date and site roles.
Is this something that would be covered by GDPR? I have tried to do some reading online but can't seem to find something definitive that covers this use case.
Yes Norman it is personal data and hence processing it (which includes storing it) comes under GDPR ambit, You may want to mention it in your privacy notice stating the high level purpose it is used for and just to ease the users let the users know, the data is not being passed to other third parties.
IAPP is good authoritative and credible site for all such queries. You may want to read this series.
https://iapp.org/news/a/business-impacts-of-the-general-data-protection-regulation-part-three/
Is this possible for my request? I would like to create a un-changaeable or definite (locations and signature) for each user on Lotus Domino..if possible on server-side, I do believe the only was creating a template for each user. Is there a possible way a template but dynamically changes on user logon so that his/her signature will vary also.
Thanks guys..
I would suggest looking at a 3rd party tool, for exampel Crossware Mail Signature.
If I understand it correctly when talking to them (we are looking for a server-based signature system as well), you can set it up so that the signatures are different for diferent users or department, as well as for internal vs external email.
I have a Spotify app and want to persist basic settings per user between sessions. I see the User object has a username field, so it would be easy to do this using my own backend. My question is, is this allowed, without requiring the user to log in, agree to some TOS, etc? Every app I see that persists any data requires me to log in with Facebook.
Usernames are typically obfuscated out in the Spotify API, so they're not the best thing to use. However, the anonymous ID for the user is the same for a given user/app ID combo across multiple machines, so you could use that instead. This sort of thing is what we designed the anonymous ID for, so you're good to go on the ToS front.
I can't find anything that restricts you from load/storing data from your own servers and I've seen 'you'd have to use your own server' suggested in a number of questions.
Not sure why other apps would involve FB - probably to get more info from the user or promote their product.
You should use the User's URI instead of their username though. I would expect it be more stable than the username and less likely to be little Bobby Tables.
I'd like to get some advice on how to structure the user data for my CouchDB application.
Here's what we're building: We are creating a suite of applications (mostly leveraging the video api of html5) that train people on different skills. We're going to start with a few simple video lectures coupled with interactive activities. We'd like to save individual user's progress, and in the near future we'd like to create some mini-courses that users take in small and large groups. Multiple users would participate in the same activity either live (like google docs), or over some long duration (like a wiki).
My concern is with private user data. Ultimately it would be the simplest, for us and the user, for them to sign up with their email address and a password. But, in CouchDB's _user database read access to the data is essentially public, and I'd rather not make all my user's email addresses public. How to make those email addresses private is my biggest concern. In addition it would be nice if we could have all user data be private unless the user chooses to make it public.
I have thought of a few options, and read through this article and many others on the wiki: http://wiki.apache.org/couchdb/PerDocumentAuthorization
I'm really not leaning toward anything yet, and would love some advice.
In the soon-to-be-released CouchDB-1.2.0, documents in the _users database can only be read by the respective authenticated user and administrators.
I have some user-specific data that I need to store in SharePoint and make accessible to the user through custom webparts. Let's say a list of favorite URLs. What would be the most straightforward way to store this information?
Some builtin propertybag for SPUser or similar that I'm not aware of.
SPList, associated through User column.
Custom database table, associated through SPUser ID.
Otherwise?
Sounds like a RTFM to me, but I'm probably asking google the wrong questions.
[Update]
We eventually stored this information in a simple list, in a fixed location, with a Person field to filter on. Perhaps the simplest solution indeed, but technically I think the marked answer below is nicer.
If you want to make them reusable across the site collection for each user you can add Fields to the User Information List. You can add a feature receiver to your web parts solution that can create this column or check to see if this column exists in the User information list to be sure that the Column exists.
The User Information list is a Standard SharePoint list that SharePoint uses to store user information.
To access the User Information List you can go to the Root web of the Site Collection and use the SiteUserInfoList property
E.G.
SPList userInformationlist = SPContext.Current.Site.RootWeb.SiteUserInfoList;
//Or
SPWeb web = SPContext.Current.Site.RootWeb;
SPList userInformationlist = web.SiteUserInfoList;
To access a users List Item you can use the Users Id to get the ListItem back from the User Information List
E.G.
SPListItem currentUserItem = userInformationlist.GetItemById(web.CurrentUser.ID);
If you are using MOSS you can store this information in the User Profiles and make it available across Site Collections this does not need My Sites to be enabled. You would need to use the User Profile classes to access this.
I would go for the properties on the user profiles. You do not want to store the information on the root web as it is not information regarding the root web.
Your example with the favorite urls, each user has a "quick links" collection on their profile. An ideal place for storing urls for each user. :)
Build a webpart that reads/writes a custom database and you'll have the flexibility to use the webpart across SiteCollections, WebApps, or even seperate Farms.
This was implemented where I work and it has been a big success. We needed a way to provide our end users a large selection of important, commonly used links. End users have the ability to display the links that are useful for their particular job function and have a webpart that can be put anywhere to reference those links that are important to them. You also have the ability for an “admin” to go to the custom database and update any URL’s that might change without the end user ever being impacted or ending up with a broken link.
This is a very good question.
Although I have no perfect answer, here are some things you can consider:
Store data in a browser cookie if this is feasible.
Store in the Site collection's rootweb in the Properties, keyed by the user's login ID. You may want to elevate when reading / writing the properties just in case the user has access to a subweb, but not the rootweb.