Closed Bug 6708 Opened 21 years ago Closed 20 years ago

ProfCreator doesn't retain user-defined profile directory when launched a 2nd time.

Categories

(Core Graveyard :: Profile: BackEnd, defect, P3, minor)

x86
Windows NT

Tracking

(Not tracked)

VERIFIED INVALID

People

(Reporter: bmartin, Assigned: racham)

Details

Latest Profile Manager/Creator (delivered 5/17/99)

Assume at least one profile has been created and user defined the profile
directory path as C:\NSCP_PROFILES\

1. launch Apprunner -ProfileManager in DOS box to run Profile Manager
2. Select New button to create a new profile (profile creator will appear)
3. Select NEXT button and view the Directory path text field.

Results:

The directory path field should retain the user-defined profile path,
C:\NSCP_PROFILES\, in the text field.
This bug is about a discrepancy between 4.x and what we have now.  In 4.x, there
was a long list of rules about how to fill in the default directory to pre-fill
that text field in the wizard.  We haven't implemented those rules yet.  We need
to bring over the 4.x rules either by porting the code or rewriting it.
there will be a much higher incident rate of Multiple Profile directories if
Profile Manager doesn't remember the user-defined path to profiles.
Status: NEW → ASSIGNED
Target Milestone: M7
Target Milestone: M7 → M8
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
The default value that should show up at all the times (in the process of
profile creation) is the default profile location. At present we advise users to
not to enter anything as the profile will be stored in the default location for
them. This is the desired behavior. Marking fixed.
Status: RESOLVED → REOPENED
Bhuvan, we need to emulate the full 4.x behavior in most cases.  This entails
more than blatting in a hard-coded value and calling it done.  We need to lift
the code from 4.5 that does this directory name resolution and fit it into the
new profile manager.
Resolution: FIXED → ---
Clearing FIXED resolution since this has been re=opened
Target Milestone: M8 → M9
Moving TFV to M9 as the fix needs JS reflection which is a DOM style
implementation at present. Will implement this feature along with xpidl
implememntation in M9.
Target Milestone: M9 → M10
Need to implement a separate logic to derive the popular profiles folder (that
parallels 4.x implementation). Moving the TFV to M10.
Target Milestone: M10 → M11
P3s aren't going to make it in M10.  Bulk moving to M11.
Blocks: 12696
Target Milestone: M11 → M14
This can be post-beta1
No longer blocks: 12696
Status: REOPENED → ASSIGNED
With the new UI, by default users are directed to create profile directories
in the default location. Alternatively, users can click on Change Folder to
select the folder of thier choice.

But if the user has a preference to have a particular folder (other then
default) as favorite folder for profiles, he need to select that folder every
time.

We need to discuss on how required is this feature for the users.
Target Milestone: M14 → M15
Component: Profile Manager → Profile Manager BackEnd
Moving all Profile Manager bugs to new Profile Manager Backend component.
Profile Manager component to be deleted.
This doesn't seem like a "major" severity bug.  The number of users impacted is
very small.
Severity: major → minor
This isn't the case anymore given the current UI (with buttons to choose a 
folder of user's choice or to choose default folder). Marking this invalid. If 
the UI chnage comes along, we should reopen and fix as needed.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago20 years ago
Resolution: --- → INVALID
verified
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.