I'm using Settings.bundle for few configuration settings for my app.
Now I'm searching for a solution to hide all, or even better, some configuration parts for the casual users. Only a 'admin' should see and edit these fields.
Is it possible to check for a password before showing the settings-properties?
If not, what could be a suitable solution? (new view controller with secret gesture or button?)
Thx in advance!
You won't be able to do anything special in the settings bundle. It's static, whatever you compile is what all users will see. If you want special behavior, there are two ways to do it:
Put it in the app itself and only allow the user access if they have the right credentials. A secret gesture could work too, but is a little dangerous because users may accidentally find out about it.
Use a different target/scheme or compile-time conditionals (using #if) to build two different versions of the app, one that does include the special configuration and one that doesn't. Personally, I would go for this option, but it may be a little harder initially.
Related
I'm starting to create a lot more features for users in my app. I've run into some app structure issues.
lets say I have User Fooman
Fooman wants to edit his account, delete some objects(wall posts), update his friends list etc.
Fooman is logged in to do all of these. But footman isn't the one using the device at the moment. It's fooman son (foobaby). Foobaby decides to just be a son and delete things erroneously. I have an option for users to delete their account client side. I present them an alert view to confirm that's the choice they meant to select. After they confirm that, another view populates with a 'Destroy' (or delete button) that will delete the User, plus all relations/pointers/data connected to it. Before that button is enabled a password validation check is required so it's not done by a foobaby. However, with Parse, this has proved to be problematic client side. I don't use cloud functions because, well, simply put, at this point in time my app is one platform and doesn't really need to use it.
Is there any workaround anyone has come up with that's quick/efficient, API friendly for validating a textField.text with the [PFUser currentUser].password whilst maintaining security of course.
I code in Objective-C :)
Note: I have tried numerous things but nothing seems to work outside of trying to log them in against the user input (UITextField), which doesn't feel like the right way to do it in my opinion.
I think it's an unusual requirement. The idea of a logged-in user is that the app trusts the user. A persisted logged-in user on the device means that the app trusts whomever is holding the device. So FooBaby is trusted, because FooDad let him hold the phone.
Some apps put up a barrier to establish thoughtfulness, like the Parse data browser requiring that you type the name of a class before you drop it. But this establishes thoughtfulness, not trust. (For a child, I guess it also establishes minimal competence, in case FooBaby knows how to press buttons, but not how to spell).
Otherwise, I can't think of how to do it besides requiring a login, which you mentioned you find unappealing (though you didn't say why). Excluding that, I don't think there's a way to do it without spoiling security with something like keeping an in-the-clear copy of the password.
In interface builder, there is a option that lets the user clear a TextField when they hit the (x) key. Since I think this option is extremely useful, I want to implement it in as many TextFields as possible.
However, the default implementation of the option is "never appears", and I want to keep as many default values as possible (because I think Apple considers the default interface behavior very well).
So my question is: when should I change the value? And if so, to what should I change it (always, when editing, or unless edition)? Here are some occasions I need to know:
On a table view
when the user enters his account details (email, password, name, etc.).
If you come up with other cases I should consider, please let me know!
Sorry, but I couldn't find any documents about this part of the UI in apple's documentation (which is very good and precise when it deals with standards).
This question is not about how to enable the key. Instead, it is when to enable it. I know it is my app and I can do whatever I want but I know how non-standardized apps feel like. So I want mine to be as standardized as possible so that the user doesn't experience any weird or usual behaviors.
This ABSOLUTELY depends on the you app design. Apple gives you these four options and it's up to you, which behavior fits your needs best, Apple does not care at all.
I personally only use it "while editing". In the past, I only used them for login or sign up forms.
I have got a passcode all up and running (4 digit login) and i need to get the option working so that the end user can assign their passcode in the settings.bundle.
At the moment, which I know is not ideal, I have a simple PSTextFieldSpecifier where the user can type in 4 numbers and login with those.
For reasons of security and having no control of what is typed into that field it will not do.
Where do I need to look to set up the screen for the passcode to be set up?
Cheers jeff
The settings bundle should be used only in a limited set of use-cases (as users often don't change individual app settings for months at a time, or not at all), and as such, limited control is given to developers as to the settings bundle and it's default controls. You'll need to use some kind of in-app settings, which are very easy to implement, and allow easier and faster access to something as variable as a username-password association. CocoaControls hosts a wide variety of simple frameworks and templates for in-app settings. I recommend you start your search there.
I am new to JIRA.
Can somebody explain to me the meaning of the different schemes in JIRA; like issue security scheme, notification scheme and so on?
Helpful online resources are also highly appreciated.
A notification scheme maps email notifications to various events. For example: "When a defect is assigned, send an email to the assignee."
A Field Configuration Scheme maps Field Configurations to issue types.
A Screen Scheme allows you to choose which Screen will be shown to a JIRA user when they perform a particular issue operation.
An Issue Type Screen Scheme associates a Screen Scheme with issue types,
An Issue Security Scheme determines who can and cannot see issues.
A Field Layout Scheme allows you to configure which fields are visible and/or required fields for a given issue type on a per project basis.
For more details, check the Jira documentation.
I really appreciate the detailed explanations available at "The Grey Blog":
http://thegreyblog.blogspot.com/2010/11/atlassian-jira-configuration-tutorial.html
Most parts of JIRA configuration can be set up differently for different projects. Some things, like custom fields, can be also set up differently for any pair of (project, issue type).
The schemes are the means to configure these per-project/per-type configuration pieces, with probably reuse of one configuration among different projects.
For example, issue security feature allows you to set up options for Security Level field and limit issue visibility to certain users based on the value of that field. Issue Security Scheme contains definitions of those options and how they limit issue visibility.
So you first configure Issue Security Scheme (may be more than one) to define that piece of configuration, and then you can assign each project one of the available Issue Security Schemes (or neither one), thus applying those pieces of config to the issues in that projects.
Jira enables flexibility to customize issue types, fields, workflows, screens, permissions, security and notifications through schemes. You can create, assign and reuse these schemes to your projects based on your needs. These schemes are assigned to project's related schemes like plug and play.
Notification scheme -- You can configure notifications like email for the issues you create or issues assigned to you and any change in status
Field Configuration scheme -- Scheme used to configure fields.. You can set based on project. You can add more fields and add to particular scheme. You can even set restrictions (lets say if it is mandatory field or not)
Permissions scheme -- Used to set permissions for the project. You can name like Admin or general user and give what they can do
Screen scheme -- Used to add fields for a particular screen.
While others answered most of the points, I would like to throw some light on Issue Security Scheme.
This is the most versatile scheme where you can restrict accessing certain issues by the security level user has.
With combination of the permission groups and issue security features, you can do almost anything in Jira from a workflow point of view.
Well schemes are sort of mapping entities.
They contain the units, like workflows,screens,issue types.
Schemes will define how a project decides which unit to use for which issue/operation.
This is of course a high level explanation.
Best bet is to start experimenting with 1 scheme, let's say screen scheme. Once you get the hang of the scheme entity, every other scheme will become understandable.
I'm required to provide functions for both users and administrators to edit account and profile details in a web application. An example of a URL for the public side of these profiles is:
http://example.com/user/joe
I'm still torn between two ways to design these URLs. I've thought of either this:
http://example.com/user/joe/edit
Or something non-specific and separate to the profiles:
http://example.com/account
The benefit of the first one is that it allows administrators to do their job through the same functions. This avoids building a whole different backend specifically for administrators. I suppose the negative here is that I'd have to be careful with authorization and make sure nobody can edit what they are not supposed to edit.
The second is a more standard way of doing things, it'd turn out to be simpler and easier to secure, though it means a separate interface for administrative users.
What is SO's opinions on this? Are there any more pros/cons for either way? Which method would you recommend to use?
I would have a different view for the administrator with such a security sensitive area. It makes things much more explicit having a separate view. It is likely even an administrator would only be able to edit certain user information and thus have a different view to the user editing themselves.
It makes the authorization much clearer even if the two views shared a common edit form
If you are using an MVC approach, then my suggestion would be:
http://example.com/user/edit/1234
or
http://example.com/user/edit/joe
Where user is the controller, edit the controller method and 1234 or joe the user id or username respectively.
But as Gumbo commented, administrators should not be allowed to edit user information. They should have some mecanism to disable the account in case of a profile has offensive content or false info. Forcing the user to update it to get the account active again.
The way we do it is the admin and the user share the same view. Items which are admin-only are protected from editing or viewing by the user.
The reason for the single view is:
It reduces the number of 'moving parts' - when a new field is added to the user screen, it only needs to be added once,
It is easier to move items to/from the user's purview. If all of a sudden, management decides to allow a user to manage their "FizzBar" then we only need make the change in one place, and
It is easier to segregate the roles and the functions at the controller level.
I think that you should go with the second approach. It's more secure and flexible, and shouldn't be harder to code than profile editing the profile inline.